[rbridge] Preview of changes for VLANs, etc.

[Eric Gray]

Russ,

	I think you have made a very valid point, here.  I would
like to qualify it somewhat by saying that we should specify 
this as the default behavior - for the exact reason you state
- 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.

	It's important to remember that VLAN tags may be used to
"virtualize" a LAN (link) and it may be the case that a VID is
mandated for some other reason.

Thanks!

--
Eric Gray
Principal Engineer
Ericsson  

> -----Original Message-----
> From: rbridge-bounces at postel.org 
> [mailto:rbridge-bounces at postel.org] On Behalf Of Russ White
> Sent: Tuesday, November 06, 2007 9:33 AM
> To: Radia.Perlman at sun.com
> Cc: Developing a hybrid router/bridge.
> Subject: Re: [rbridge] Preview of changes for VLANs, etc.
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> 
> > a) all RBridges on a link can talk to each other using a 
> single (outer) VLAN tag, and
> > that VLAN is not allowed to be partitioned. If it is, 
> whichever RBridges can't talk
> > to the DRB on that VLAN are just orphaned. All the other 
> RBridges send IS-IS
> > messages (Hellos, LSPs, CSNPs) on that link tagged with the 
> one VLAN tag.
> 
> Why have this vlan tag at all? If the traffic for any given vlan is
> tunneled to the outer edge using the direct layer 2 address 
> of the exit
> rbridge, then the "outer" vlan tag is an unnecessary complication. The
> simpler rule would be the only traffic on link which should 
> have a vlan
> tag will be that originating from a non-rbridge device. Once traffic
> hits the first rbridge, there should never be an "outer" vlan 
> tag, just
> the destination address in the outer tunnel header.
> 
> All the other stuff you talk about seems to be much easier 
> without this
> outer header--the way IS-IS runs, the DIS election on each link,
> forwarding, etc.
> 
> > f) Hellos shouldn't have to be bigger with this proposal. 
> What's in a Hello?
> > . my ID
> > . my priority for becoming DRB
> > . name of the pseudonode if I am DRB
> > . VLAN tag "V" to use for outer VLAN tag on this cloud if I am DRB
> > . set of neighbors I've heard Hellos from on the specified
> > VLAN tag (V)
> > . flag "please send CSNP" used when starting up, to ensure that
> > you have synchronized LSP databases with your neighbors
> > 
> > Now there might also be the following in the Hello:
> > . "Bidding for VLANs": If I'm not DRB, set of (priority, 
> {set of VLAN tags}) that I would like
> > to be assigned to en/decapsulate for
> 
> This does make the hello larger. Probably much larger....
> 
> > . "VLAN assignments" If I am DRB, en/decapsulator 
> assignments, of the form
> > (RBridge neighbor ID, {set of VLANs}) that I want that RBridge
> > to encapsulate/decapsulate for.
> 
> I don't understand why we need this.... I don't think you're really
> going to have a case where a single interface on the user side
> "services" multiple vlans, which are generally separated at the edge
> through virtual interfaces on the box. IE, if I receive a packet on
> interface ethernet 1.1, then it's vlan x, if it's on ethernet 
> 1.2, then
> it's vlan y. There's no reason not to stick with this convention--the
> chipsets already know how to separate things this way, I think.
> 
> IE, forwarding would look like this:
> 
> 1. Receive packet on interface X.
> 2. Check to see if there's a 1q header.
> 3. If so, then look up appropriate edge destination, encap in 
> a tunnel,
> and resend.
> 3. If not, then find correct vlan, look up appropriate edge 
> destination,
> place vlan header on packet, encap in tunnel, and resend.
> 
> On the receiving side, you just strip off mac headers and process them
> normally. There's no need for special processing of any type, 
> is there?
> 
> I don't see anything about the "merging" vlans 
> automatically.... I don't
> think this should be done, in any case.
> 
> :-)
> 
> 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
> 
> iD8DBQFHMHswER27sUhU9OQRAkk+AKDf3LMTQCXPCL3Z7vNy5mmZT9c7bgCfbldB
> RYbmkapg1cE1sSlsgQNVneQ=
> =1x27
> -----END PGP SIGNATURE-----
> _______________________________________________
> rbridge mailing list
> rbridge at postel.org
> http://mailman.postel.org/mailman/listinfo/rbridge
>