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

[Silvano Gai]

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