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

[Gray, Eric]

Past presentations can usually be seen by going to the IETF site,
picking "Meetings", "Past Meetings" and then whatever specific
meeting you want.  Presentations on general issues with VLANs and
p2mp trees started - I believe - in IETF 62. 

--> -----Original Message-----
--> From: Silvano Gai [mailto:sgai at nuovasystems.com] 
--> Sent: Thursday, October 19, 2006 7:47 PM
--> To: Gray, Eric; Joe Touch; Dino Farinacci (dino)
--> Cc: rbridge at postel.org; Radia Perlman
--> Subject: RE: [rbridge] Range of appllicability (was Re: TTL 
--> only - was RE: New fields in shim header?)
--> 
--> 
--> Eric,
--> 
--> Help me here, can you send a pointer to a presentation?
--> 
--> VLAN within a CRED can work for unicast, but not for multicast.
--> As multicast is currently defined in TRILL the root of the tree is
--> ALWAYS in the ingress RBridge, independently of how many 
--> VLANs you have.
--> 
--> > -----Original Message-----
--> > From: Gray, Eric [mailto:Eric.Gray at marconi.com]
--> > Sent: Thursday, October 19, 2006 3:13 PM
--> > To: Silvano Gai; Joe Touch; Dino Farinacci (dino)
--> > Cc: rbridge at postel.org; Radia Perlman
--> > Subject: RE: [rbridge] Range of appllicability (was Re: 
--> TTL only - was
--> RE:
--> > New fields in shim header?)
--> > 
--> > Silvano,
--> > 
--> > 	The VLAN space you mention is larger in the RBridges case.
--> > It is possible to use 802.1Q encapsulation in the RBridge tunnel
--> > encapsulation -
--> 
--> From this explanation I am not sure were you want to add 
--> the additional
--> 1Q tag.
--> 
--> -- Silvano
--> 
-->  in a fashion similar to (but not necessarily the
--> > same as) the way in which it may be used in the native Ethernet.
--> > 
--> > 	Consequently, if - in a deployment - network administrators
--> > want to optimize load balancing, they may do so by defining VLANs
--> > within the CRED.  Sets of CRED-VLANs would be configurable to use
--> > distinguishable paths.
--> > 
--> > 	As Radia has pointed out in several previous presentations,
--> > one of the "keys" used in a look-up for the "ingress RBridge tree"
--> > is the VLAN in the tunnel encapsulation - assuming one is present.
--> > 
--> > 	This could - among other things - serve the purpose of "tags"
--> > for use as you describe.  Since configuration would be needed in
--> > either case, this is both equivalent to adding any additional tags
--> > and more than is strictly required to solve the problems we've set
--> > out to solve.
--> > 
--> > 	Note that this use of VLAN tags in the tunnel encapsulation
--> > - while not entirely orthogonal to VLAN tag usage in native encaps
--> > - does not necessarily result in depletion of the native VLAN tag
--> > space.
--> > 
--> > 	Effectively, by potentially having VLAN tags in the tunnel
--> > encapsulation, and in the native Ethernet encapsulation as well,
--> > you have more than 4K potential "VLANs" - not less.
--> > 
--> > --
--> > Eric
--> > 
--> > 
--> > --> -----Original Message-----
--> > --> From: rbridge-bounces at postel.org
--> > --> [mailto:rbridge-bounces at postel.org] On Behalf Of Silvano Gai
--> > --> Sent: Thursday, October 19, 2006 5:44 PM
--> > --> To: Joe Touch; Dino Farinacci (dino)
--> > --> Cc: rbridge at postel.org; Radia Perlman
--> > --> Subject: Re: [rbridge] Range of appllicability (was Re: TTL
--> > --> only - was RE: New fields in shim header?)
--> > -->
--> > -->
--> > --> Joe,
--> > -->
--> > --> I have hard time understanding how you can use 
--> separate VLANs for
--> > --> unicast and broadcast, this will, for example, break IPv4,
--> > --> due to ARP.
--> > -->
--> > --> Using separate VLANs for Unicast and Multicast will break
--> > --> IPv6, due to
--> > --> ND.
--> > -->
--> > --> Today, all the applications assume that they can send
--> > --> Unicast, Multicast
--> > --> and Broadcast on the same VLAN (they basically ignore 
--> that a VLAN
--> > --> exists).
--> > -->
--> > --> Remember that many networks deploy "Private VLANs", since they
--> don't
--> > --> have enough of 4K VLANs, so proposing to reduce the 
--> 4K space to
--> 1/3
--> > --> seems highly unrealistic.
--> > -->
--> > --> Today TRILL specifies that multicast must be sent on 
--> the "ingress
--> > --> RBRidge tree" (for this reason, in the case of multicast,
--> > --> the ingress
--> > --> RBridge address is carried in the shim header). This
--> > --> provides shortest
--> > --> path, but not good load balancing. Multicast folks will
--> > --> prefer to have
--> > --> few shared trees routed in the core. In this way they 
--> get optimal
--> > --> forwarding, but also good load balancing. To support 
--> this it is
--> > --> necessary to carry in the frame an indication of the tree
--> > --> (FTAG) that
--> > --> needs to be used to forward the frame.
--> > -->
--> > --> I am sure that Dino can provide a better reply to this point.
--> > -->
--> > --> -- Silvano
--> > -->
--> > -->
--> > --> > -----Original Message-----
--> > --> > From: Joe Touch [mailto:touch at ISI.EDU]
--> > --> > Sent: Thursday, October 19, 2006 11:36 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:
--> > --> > > 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
--> > -->
--> > -->
--> > --> _______________________________________________
--> > --> rbridge mailing list
--> > --> rbridge at postel.org
--> > --> http://mailman.postel.org/mailman/listinfo/rbridge
--> > -->
-->