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

[Joe Touch]

Silvano Gai wrote:
> Joe,
> 
>> -----Original Message-----
>> From: Joe Touch [mailto:touch at ISI.EDU]
>> Sent: Thursday, October 19, 2006 8:58 AM
>> To: Silvano Gai
>> Cc: Erik Nordmark; rbridge at postel.org; Radia Perlman
>> Subject: Re: [rbridge] Range of appllicability (was Re: TTL only - was
> RE:
>> New fields in shim header?)
>>
>>
>>
>> Silvano Gai wrote:
>> ...
>>>> The reason I'm asking is because I see a big difference between
> asking
>>>> RBridges to provide some new degree of filtering/security, and
> making
>>>> sure it isn't any worse than a bridged network.
>>> Understood, but a new standard is also a good place to improve.
>> 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.
> 
> 
> we'd need three types:
>> 	- MUST set as 0 currently; MUST ignore on receipt
>> 		for optional extensions
>> 	- MUST set as 0 currently; MUST silently discard if not 0
>> 		for silently dropped required extensions
>> 	- 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/762af3ed/signature.bin