[rbridge] Range of appllicability (was Re: TTL only - was RE: New fields in shim header?)

[Joe Touch]

FWIW, regarding reserved bits:

Joe Touch wrote:
...
>>> The need for capabilities not in 802 now may be a good argument for
>>> reserved bits
>>>
>>> Note that in hardware they too are problematic; 
>> I am not advocating reserved bit, I agree with you that they are
>> problematic and difficult to use in the future.

They're problematic because we typically define them as Type I (see
below), but Type I is the least useful IMO compared to Type II and III.

The only issue is that type needs to be declared in advance, or
indicated in-band (the latter as IPv6 hop options do to some extent).

I'd rather give some bits each to Types I-III and another 8 to hopcount,
 and put both source/dest in the header than add FTAGs now, i.e.:

+--------+--------+
|11122233|hhhhhhhh|
+--------+--------+
|rbridge-source   |
+--------+--------+
|rbridge-destn    |
+--------+--------+

111 = Type I reserved bits
222 = Type II reserved bits
33  = Type III reserved bits
hhhhhhh = hopcount (7 bits)

That consumes 6 bytes.

The minimum header, IMO, ought to be 3 bytes:

+--------+--------+
|rbridge-destn    |
+--------+--------+
|hhhhhhhh|
+--------+

Frankly, I'd rather see a 3-byte shim.

JOe

---------------------------------------------------------------------------

>> we'd need three types:

Type I:
>>> 	- MUST set as 0 currently; MUST ignore on receipt
>>> 		for optional extensions

Type II:
>>> 	- MUST set as 0 currently; MUST silently discard if not 0
>>> 		for silently dropped required extensions

Type III:
>>> 	- MUST set as 0 currently; MUST report as error if not 0
>>> 		for non0-silent required extensions
>>>
>>> I'd rather see the FTAG area blocked out for those kinds of bits at
>> this
>>> time than locked into a tag that a new VLAN header might replace, e.g.
>>>
>> The FTAG has two values:
>>
>> 1) for unicast traffic today 802 networks support:
>>   a) per VLAN spanning tree
>>   b) a single common spanning tree
>>   c) shared spanning trees
>>
>> TRILL is the current equivalent of (b), (a) is pragmatically impossible,
>> since you don't want to run an instance of ISIS per VLAN. 
> 
> Actually, I thought that was the plan.
> 
>> If we want to
>> support the equivalent of (c), we need to have a tag in the packet.
>> Without a tag in the packet the implementations are full of corner
>> cases. 
> 
> Not if we do (b), right?
> 
>> 2) for multicast, if you want to have shared trees, you need a tag in
>> the packet. In particular with two or three tiers networks the best
>> solution is to have few shared trees rooted in the backbone. TRILL
>> currently does not support this.
> 
> It'd be useful to explain this further; I'm not exactly sure what you
> mean. We had talked before about separate VLANs for broadcast,
> multicast, and unicast groups.
> 
> Joe
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 250 bytes
Desc: OpenPGP digital signature
Url : http://mailman.postel.org/pipermail/rbridge/attachments/20061019/c7a6a36b/signature.bin