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

[Gray, Eric]

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 - 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
-->