[rbridge] Preview of changes for VLANs, etc.

[Eric Gray]

Radia,

	What gets us wrapped around the axle is attemtping to
specify things in such a way that we have to care about the
VLAN tag used in RBridge-to-RBridge forwarding.  The point
to using logical interfaces - or virtualization - is to hide
network complexity.  Trying to "unroll it" is not making it
simpler.

--
Eric Gray
Principal Engineer
Ericsson  

> -----Original Message-----
> From: Radia Perlman [mailto:Radia.Perlman at sun.com] 
> Sent: Tuesday, November 06, 2007 12:35 PM
> To: Russ White
> Cc: Eric Gray; Developing a hybrid router/bridge.
> Subject: Re: [rbridge] Preview of changes for VLANs, etc.
> 
> Certainly I'd love to get rid of the outer VLAN tag. Unfortunately, 
> bridges on the link can be configured in weird ways such that the
> only way to send a packet is using a particular set of VLAN tags.
> Then there are other complicated issues, like finding which VLAN
> tag works for which neighbors. And then if you form an adjacency 
> with each neighbor via a potentially different (set of) VLAN tags,
> then how would you send multicast on a link? There wouldn't be
> guaranteed to be a single VLAN tag that would reach everyone on
> the link.
> 
> So the proposal is to use a single, unpartitioned VLAN tag for 
> communication on the link, and if anyone can't talk to the DRB on
> that link using the VLAN tag that the DRB specifies, then they
> basically can't use the link. 
>
> If "which VLAN number" is configurable, then we have to deal with
> different configurations in different RBridges, which we do by
> having the DRB inform all the other RBridges what VLAN tag to
> use.
> 
> Radia
> 
> 
> Russ White wrote:
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> >
> >
> >   
> >> - but without explicitly forbidding the use of a VLAN tag in 
> >> the link-level encapsulation required to get a frame from one
> >> RBridge to another.
> >>     
> >
> > Sure--If the only way to reach the next hop is through a 
> vlan, then you
> > would need to encap in that vlan to get to the next hop. I think the
> > cleanest way to do this is:
> >
> > 1. Receive packet.
> > 2. Look up exit rbridge.
> > 3. Find next hop to the exit.
> > 4. Look at the outbound interface towards this next hop.
> > 5. If the outbound interface is a 1q interface (logical, rather than
> > physical), then encap with the inside vlan stuff, then the tunnel
> > header, then put it in another tunnel header, with the destination
> > address being the next hop, and the vlan stuff being the 
> correct one to
> > reach that next hop.
> > 6. If the outbound interface is not a 1q interface (physical, rather
> > than logical), then encap with the vlan stuff, then the 
> tunnel header
> > for the outer edge rbridge (egress rbridge), and forward it.
> >
> > When the next hop receives the packet in the case of #5, it 
> will see the
> > packet is to it, strip the outer header, and then see the 
> inner tunnel,
> > and forward the packet according to local rules, based on it's tree,
> > etc. I think this is much simpler than having a "set" vlan 
> on any given
> > link, or having to carry around a set of vlans you forward 
> for, and such.
> >
> > :-)
> >
> > Russ
> >
> > - --
> > riw at cisco.com CCIE <>< Grace Alone
> >
> > -----BEGIN PGP SIGNATURE-----
> > Version: GnuPG v1.4.6 (MingW32)
> > Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
> >
> > iD8DBQFHMJOgER27sUhU9OQRAmPPAJ9QC7qUavulxDpa5am4RxbTUBJ38gCdGFc9
> > RfgcEqMnZgWPpnAh+RRwy0k=
> > =//s3
> > -----END PGP SIGNATURE-----
> >   
> 
>