Subject: [rbridge] Preview of changes for VLANs, etc.

From: Radia.Perlman at sun.com ([email-masked])
Date: Mon, 05 Nov 2007 19:48:53 -0800

Russ,

The way to look at it is that the VLAN tag with which RBridges talk to each other on one link is
irrelevant outside the link. So really...one pseudonode, and one VLAN per link
for interRBridge communication is a simplification. Really. Though I'm
not surprised if my sketch of a design might have not been self-explanatory.

Let me try to explain a bit more, and from an IS-IS point of view. If this isn't
clear, or if you still have concerns,
then we (you and I) can have a quick phone call (are you available tomorrow afternoon?),
or you can wait until
you see the details in the spec. Or you can ask another question on the list.

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.

b) All RBridge-RBridge links can be used as transit for data that
belongs on any VLAN. So a data packet from VLAN x on one link destined
to VLAN x on some other link in the campus can transit any RBridge-RBridge
link (say from R2 to R3) regardless of what VLAN tag R2 has to slap on the
outside of the frame in order to carry the frame from R2 to R3.

c) the only time VLANs are relevant, in terms of IS-IS forwarding, is when
pruning multicast (you don't have to send down a branch if none of the links
at the end of that branch support that VLAN. But for sending unicast...you
are sending to the specified egress RBridge. The forwarding RBridge
does not care at all what the inner VLAN is. It also doesn't care
what VLAN tag R3 has to tack on in order to forward it across the next
hop to R4.

e) A LAN will have a single DRB. A single pseudonode. No VLANs or
endnodes are
associated with the pseudonode.  Endnodes and VLANs are
only associated with RBridges. If R1 is DRB for pseudonode R1.25,
then R1.25's LSP only lists the other RBridges attached to R1.25.
Whatever RBridge R2 is appointed by R1 to forward VLAN x traffic
to/from pseudonode R1.25 will specify in R2's LSP, "I, R2, am
attached to VLAN x". R2 might even have lots of links attached
to VLAN x. But R2 just says in R2's LSP "I am attached to VLAN x".

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
. "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 think we could come up with reasonably compact encodings for those. Though
they don't really have to be in the Hello. Instead, especially the "bidding"
part could be in a separate message to the DRB.  I like having the
DRB specify assignments in its Hello, though, to ensure there is no confusion.
I'd think that 99% of the time there would be no assignments, and the DRB itself
would be the encapsulator/decapsulator for all VLANs on that link.

Hope that's clearer...

Radia

----- Original Message -----
From: Russ White <riw at cisco.com>
Date: Monday, November 5, 2007 5:53 pm
Subject: Re: [rbridge] Preview of changes for VLANs, etc.

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> 
> > Based on talking to people, here is how I'm assuming the VLAN stuff
> > will look. The main points are
> 
> I'm a bit confused by this entire thread, and these changes....
> 
> > a) single DRB per link (rather than DRB election per VLAN).
> 
> I assume this is to reduce overhead by reducing the number of
> hello's.... But, then we turn around and make the hellos significantly
> larger, and change the format significantly, and we change their
> processing significantly.... I don't think there's any savings here.
> 
> Further, how does this look in SPF to other devices? Suppose you have
> one pnode per link, with multiple vlans:
> 
> o Do all the devices on the link advertise themselves as connected to
> the pnode? How does the pnode indicate all the vlans it transits, 
> so the
> SPF tree will work correctly? Does the pnode advertise one lsp per 
> vlan?If so, then how does this one pnode per link really save 
> anything?
> o What if there is no device that's actually on every vlan on the
> segment? Does it act as the pnode for vlans in which it doesn't
> participate? How do other is' build a tree in this situation--do they
> route through a pnode that's not on the vlan they're building a 
> tree for?
> 
> > b) that DRB can delegate to another RBridge on the link the
> > job of forwarding VLAN-x data to/from the link.
> 
> I think this kills all thoughts of load sharing through any sort of
> multiaccess medium. You'll still be able to load share on point-to-
> pointlinks, but not across Ethernet, for instance.... Is that an 
> acceptabletradeoff?
> 
> What if an rbridge sends some traffic to the only path on which it can
> send traffic for a specific vlan, and the exit point finds the only 
> pathit has is through the rbridge that just sent it the traffic? 
> How do we
> resolve this? Do we need ICMP redirects for TRILL?
> 
> > c) RBridges MAY be configured to send Hellos on a set of VLANs,
> > though VLAN 1 is the default. They are also configured with a single
> > preferred VLAN "V". If RBridge RB1 is DRB, it tells all the other 
> RBridges> on the link to send ALL RBridge-Rbridge traffic (Hellos, 
> LSPs,> forwarded encapsulated data traffic) with outer VLAN tag "V".
> 
> Doesn't this concept of a single "management" vlan on any given link
> destroy the ability to see what's going on on a specific vlan 
> throughouta network? IE, if I want to look at the neighbor 
> adjacencies for vlan x,
> I must look at debugs for vlan y, because the hellos are only sent on
> vlan y. I find this confusing--it will probably contribute to many 
> hoursof lost network time as engineers try to figure out what "vlan 
> v" is so
> they can see what's actually going on.
> 
> > d) For safety, the DRB RB1 continues to send Hellos not only on V,
> > but on all the VLANs that RB1 is configured to send Hellos on.
> 
> Which kills off any advantages from not sending all those hellos and
> doing dis election on all those vlans, doesn't it?
> 
> > f) We use all the link-avoidance stuff we'd discussed before (don't
> > decapsulate from ingress RBx unless you have RBx's LSP and all 
> pseudonodes> that RBx claims to be attached to, and can verify that 
> none of them
> > have the same root bridge ID as the link you are about to 
> decapsulate> onto -- also, be conservative about when you start 
> encapsulting data
> > off the link by waiting a few Hello intervals, and waiting until
> > you've synchornized LSP databases with your neighbors).
> 
> This is a lot of complex stuff at layer 2.... Are current chipsets 
> goingto be able to handle all of this? Or have we abandoned the 
> idea of minor
> or no modifications in hardware?
> 
> > g) IS-IS Hellos list the set of neighbors from which Hellos are 
> heard.> Once the DRB RB1 specifies "V" as the VLAN, the only 
> neighbors listed
> > in IS-IS Hellos are those from which a Hello is received on VLAN V.
> 
> What if someone's not configured to run on vlan v? What if a box 
> has a
> limited number of vlans it can support, and already has that number of
> vlans configured? There will probably be an upper limit on support on
> any given box, after all, so this is always a possibility as we get 
> intothe virtualization that rbridges will open up as possibilities.
> 
> Finally, I see a lot of stuff about welding together vlans with the 
> sameid no matter where they are in the network. I consider this to 
> be a huge
> "surprise" problem, at the least, and extremely dangerous, at the
> worst.... Just because two vlans are configured with the same id does
> not mean they were intended to be in the same broadcast domain.
> 
> So, can someone explain why we are doing all of this work, changing
> fundamental principles of IS-IS, changing SPF operation, etc.?
> 
> :-)
> 
> 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
> 
> iD8DBQFHL8kaER27sUhU9OQRAjcEAKCFZEHG7u6OzBc8ysqc6h5u7IQMIACg9tCG
> RBP6jhPZ0HtaYae+XAYg+5A=
> =J+a1
> -----END PGP SIGNATURE-----
>

---

From: riw at cisco.com (Russ White)
Date: Tue, 06 Nov 2007 09:33:20 -0500

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

> to be assigned to en/decapsulate for

This does make the hello larger. Probably much larger....

> 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

- --

---

From: eric.gray at ericsson.com (Eric Gray)
Date: Tue, 6 Nov 2007 09:49:18 -0600

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.
> iD8DBQFHMHswER27sUhU9OQRAkk+AKDf3LMTQCXPCL3Z7vNy5mmZT9c7bgCfbldB
> RYbmkapg1cE1sSlsgQNVneQ=
> =1x27
> _______________________________________________
> rbridge mailing list
> rbridge at postel.org
> http://mailman.postel.org/mailman/listinfo/rbridge
>

---

From: riw at cisco.com (Russ White)
Date: Tue, 06 Nov 2007 11:17:36 -0500

> the link-level encapsulation required to get a frame from one

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

- --

---

From: Radia.Perlman at sun.com (Radia Perlman)
Date: Tue, 06 Nov 2007 09:34:55 -0800

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:
> iD8DBQFHMJOgER27sUhU9OQRAmPPAJ9QC7qUavulxDpa5am4RxbTUBJ38gCdGFc9
> RfgcEqMnZgWPpnAh+RRwy0k=
> =//s3

---

From: riw at cisco.com (Russ White)
Date: Tue, 06 Nov 2007 15:14:40 -0500

> particular set of VLAN tags. Then there are other complicated issues,

Since this is probably going to be 5% or less of the cases, we should
make this capability optional, and make the 95% case the simpler case of
sending with no vlan tag. The only case this really arises in is when
you have hosts on links with through traffic, which any good network
designer avoids like the plague.

I'd rather not make this whole thing really complicated just to support
a small set of networks....

:-)

Russ

- --

---

From: eric.gray at ericsson.com (Eric Gray)
Date: Tue, 6 Nov 2007 14:41:43 -0600

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  

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

---

From: Donald.Eastlake at motorola.com (Eastlake III Donald-LDE008)
Date: Tue, 6 Nov 2007 16:31:22 -0500

The big problem is incremental deployment. Sure, looking at existing
802.3 bridged networks, you almost never have links with both bridges
and end station on them. But with incremental deployment of Rbridges, a
bridged LAN between N Rbridges will commonly look like a through link
that also has end stations on it. And furthermore, it can easily be a
link between these N Rbridges with odd, VLAN dependent connectivity.
Some people in the working group consider the mixed bridges and Rbridges
case very important.
	So, while I'm fine with noticing/configuring point-to-point
Rbridge links and omitting the outer VLAN tag on them, since it pretty
much serves no function, you want a scheme that has a reasonable chance
of working if a link is a complex bridged LAN.

Donald

-----Original Message-----
From: rbridge-bounces at postel.org [mailto:rbridge-bounces at postel.org] On
Behalf Of Russ White
Sent: Tuesday, November 06, 2007 3:15 PM
To: Radia Perlman
Cc: Developing a hybrid router/bridge.
Subject: Re: [rbridge] Preview of changes for VLANs, etc.

:-)

Russ

- --

---

From: riw at cisco.com (Russ White)
Date: Tue, 06 Nov 2007 16:35:56 -0500

> of working if a link is a complex bridged LAN.

I'm not certain I can see where always putting an outer vlan tag on a
packet will really help on a mixed bridge/rbridge link.... You would
have the bridges configured with a bunch of subinterfaces, one for each
vlan, and you'd configure the rbridges the same way, I think. I don't
think it's useful to expect the rbridges to autodetect all the possible
vlans on the link, and try to sort out what the user normally sorts out
through manual configuration anyway.

The only other situation is an rbridge connected to a normal bridge
through a trunk port--but this would normally be a p-2-p link, so I
think the rules I suggested earlier would work in this situation.

:-)

Russ

- --

---

From: anoop at brocade.com (Anoop Ghanwani)
Date: Tue, 6 Nov 2007 13:56:58 -0800

> Sent: Tuesday, November 06, 2007 12:15 PM
> To: Radia Perlman
> > 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,
> 
> Since this is probably going to be 5% or less of the cases, 
> we should make this capability optional, and make the 95% 
> case the simpler case of sending with no vlan tag. The only 
> case this really arises in is when you have hosts on links 
> with through traffic, which any good network designer avoids 
> like the plague.
> 
> I'd rather not make this whole thing really complicated just 
> to support a small set of networks....

It's not that simple...again back to terminology:

- For ports that support only bridged traffic 802.1
  defines what they should do.
- For ports that support only TRILL traffic, we
  get to define how they operate (within some limits
  since we may still see link-local control traffic).
- For ports that support both bridged and TRILL
  traffic we have to go with what 802.1 says
  (otherwise the traffic won't go through bridges).

Thus far, all RBridge ports are assumed to be 
of the last type.  That means the encapsulation has
to follow rules defined by 802.1 - i.e. you have
a set of VLANs on that port.  We only transmit
traffic on those VLANs.  Some of those VLANs belong
to the "tagged set" in which case we transmit frames
for those VLANs in tagged format; other VLANs belong
to the "untagged" set in which case we transmit 
frames without a tag.

I think what we have defined so far is fine.
There is no need to change it.  Making it optional
won't work.

Even routers have to follow those rules or
their packets don't make it through the LAN!

Anoop

---

From: riw at cisco.com (Russ White)
Date: Tue, 06 Nov 2007 19:09:21 -0500

> to the "untagged" set in which case we transmit 

In all implementations that I know of, such interfaces are always:

1. Trunk ports, which I've already covered.
2. A single physical interface with multiple logical "subinterfaces."

Can you point to a single case where a device can send multiple vlan
traffic on a single logical interface, or where it treats a single
interface as a link with multiple vlans while not calling it a "trunk,"
and putting special operational rules around it (such as no end host
devices)?

> There is no need to change it.  Making it optional

What has been defined so far is very complex--you're recreating
subinterfaces without subinterfaces, for no reason I can see.

> their packets don't make it through the LAN!

Routers don't follow these rules.... They don't simply put "some random
vlan number" on any packet they are transmitting to "get the packet
through the LAN." There is no "common vlan" assigned to each link to
allow routers to communicate. There is no concept of a "single hello"
for multiple virtual topologies on a single link, with all sorts of
stuff added so everyone on the link knows which virtual network everyone
else is on.

Routers operate exactly as I described previously. If a router receives
a packet on an interface, it will:

1. Find the next hop, by looking at the tree.
2. Figure out the outbound interface.
3. Encap the packet with the correct layer 2 header for that interface.
3a. If the outbound interface is a subinterface, the layer 2 header will
include, of course, a vlan header.
3b. If the outbound interface is not a subinterface, the layer 2 header
will not include a vlan header.

Whether or not there's a vlan tag that needs to be added plays no part
in the forwarding decision.

IMHO, rbridges _should_ operate as much like routers as possible, rather
than using some new forwarding paradigm. Once the traffic is placed in a
tunnel, it should be carried--as much as possible--just like an IP
packet is carried.

:-)

Russ

- --

---

From: Radia.Perlman at sun.com (Radia Perlman)
Date: Tue, 06 Nov 2007 16:24:08 -0800

Russ...as much as I share your love of the complexity of VLANs...

I think the reason RBridges are more complicated with the VLAN stuff 
than IP routers are
is that in IP a VLAN is an IP subnet, so a router would only be talking 
on a single VLAN
at a time over a particular port-as-seen-by-IP. If an IP node (whether it be
a router or a logically-multi-link endnode) were on multiple VLANs 
through the
same port, it would be configured so that the higher level software 
wouldn't have
to know anything about that stuff. If an IP node used a single port as 4 
logical ports,
by having each in a different VLAN, then each of those "ports" would be 
associated
with a single VLAN.

RBridges, on the other hand, like bridges, are simultaneously supporting 
multiple VLANs
over the same port. VLANs that the RBridge itself is not a member of in 
any sense -- just
that the RBridge is supposed to support to glue it to other pieces of 
the VLAN in other
parts of the campus.

Radia

Russ White wrote:
> iD8DBQFHMQIxER27sUhU9OQRAo51AJ4wilUVzWflNoanrdcX7U/nCtICMwCbBog6
> 50JNAS2hu/otps6EXwSZ4lc=
> =6yb5

---

From: riw at cisco.com (Russ White)
Date: Tue, 06 Nov 2007 19:48:49 -0500

> that the RBridge is supposed to support to glue it to other pieces of

Again, the only two instances I know of are:

1. There are subinterfaces, or physical interfaces, which belong to a
single vlan.

2. The port is declared a trunk, and specific rules apply to the port,
such as no end user traffic is allowed on the port.

And I still don't see what any of this has to do with all this
complexity. I've described all the situations in previous emails, and
how to handle them, without the concept of a "common vlan," etc. Again,
why do we need this complexity? What is it supporting? Can someone point
to a specific situation that wouldn't be handled by the forwarding rules
I proposed earlier--that's not contrived, and impossible with all
current implementations?

:-)

Russ

- --

---

From: anoop at brocade.com (Anoop Ghanwani)
Date: Tue, 6 Nov 2007 17:39:08 -0800

> From: Russ White [mailto:riw at cisco.com] 
> Sent: Tuesday, November 06, 2007 4:09 PM
> To: Anoop Ghanwani
> Cc: Radia Perlman; Developing a hybrid router/bridge.

We must be talking past each other because I'm
not sure what the above comment is getting at.
Nowhere have I talked about "multiple VLAN
traffic on a single logical interface".  Please
give me the full context if possible.

By the way, trunk ports in one large, prominent
vendor's implementation is a subset of the 
standard.  The 802.1 document does not talk
about trunk ports at all, and on a given port
you can have any bunch of VLANs, some of which
are tagged and some of which are untagged.  
And this is different that the "trunk port".

> subinterfaces without subinterfaces, for no reason I can see.

The subinterfaces are there because an RBridge
is also a bridge.  Just like a bridge has VLANs
configured on ports, an RBridge will also have
VLANs configured on ports.  The reason this is
needed is because we have to know which VLANs
are configured on a port when we receive
a multicast packet from another RBridge that
needs to be forwarded on the port.
 
> stuff added so everyone on the link knows which virtual 

We are not talking about putting a random number.
We are talking about putting some VLAN ID that is
configured on the port.

> will not include a vlan header.

I agree with this.
 
> in the forwarding decision.

That is correct...however, as you note in 3, 3a, 3b,
you have to know the interface that you're forwarding
the packet on.  That interface, in the RBridge world,
is a VLAN on a specific port (for unicast) or a \
VLAN on a set of ports (for multicast).

> tunnel, it should be carried--as much as possible--just like an IP

So if I have the following configuration:
(R1) <---(vlan1)---> (R2) <---(vlan1)---> (R3)
the packets between the routers could either
be tagging the frames or not and that depends
on the configuration of the port in question.
(In the implementation you are familiar with,
untagged would mean there is no subinterface,
and tagged means there is a subinterface with
a tag of 1.  Just because I have a subinterface
in the latter case, does not mean another 
subinterface must exist on that router port.)

Anoop

---

From: riw at cisco.com (Russ White)
Date: Wed, 07 Nov 2007 06:52:45 -0500

> needs to be forwarded on the port.

I don't see where this matters.... All that matters is which egress
devices are within the correct vlan for the multicast packet you've just
received. You are forwarding to egress devices, not along vlans within
the cloud.

IMHO, this is why this entire confusion has arisen.... You don't need to
forward along a given tree, and along a given vlan, and glue vlans
together.... Choose one, not all three. The entire point of rbridges is
that the entire "core" of the rbridge network forwards towards egress
bridges, rather than mimicking the virtual topologies along the edge.
You're now introducing requirements to do both--treat the core as a vlan
free space, and only forward along vlans within the core.

It makes no sense.

> We are talking about putting some VLAN ID that is

The phrase "some random vlan number, just to get the packet through the
LAN," has been used multiple times on list. Second, restricting all
traffic flowing between any set of rbridges on a single link to one vlan
across that link makes no sense.

>> will not include a vlan header.

Then you don't need all this vlan stuff in the middle. You are
forwarding through the underlying cloud to the address of an egress
device. That address should be in the tunnel encap once the packet
enters the cloud.

It appears we are creating different forwarding rules for multicast than
for unicast, without considering the implications of such alternate rule
sets on the forwarding hardware, or the simplicity of managing and
troubleshooting this stuff.

:-)

Russ

- --

---

From: riw at cisco.com (Russ White)
Date: Wed, 07 Nov 2007 07:44:23 -0500

>> I agree with this.

Since this is obviously not the forwarding path for rbridges, I think it
would be very useful if you could outline the actual forwarding path,
with all the possible "if" statements involved.

If an rbridge receives a unicast packet without a VLAN tag, it will:

1. Examine the local tree to determine the egress rbridge.
2. Examine the local tree to determine the next hop towards that rbridge.
3. Encapsulate the packet in a tunnel header with the next hop being the
egress rbridge.
4. (add another tunnel header to get to the next hop with a "common
vlan" tag, to "get through the network???")

If an rbridge receives a multicast packet without a VLAN tag, it will:

1. Examine the local tree to determine the set of egress rbridges.
2. Examine the local tree to determine the next hop towards that set of
egress rbridges.
3. Add a VLAN tag to denote the VLAN on which this multicast belongs.
4. (add another VLAN tag to get the packet to the next hop, one per next
hop????)

If an rbridge receives a unicast packet with a VLAN tag, it will:

....

If an rbridge receives a multicast packet with a VLAN tag, it will:

....

I think it would be very useful to combine all of this into a single
forwarding path, so we can see what the complexity of this proposal is.
It would also be useful to explain the full process from the attachment
of a new IS onto a broadcast link through the ability of that IS to
forward rbridge traffic--every step involved. Again, it would be useful
to see the complexity level involved of all the different pieces being
proposed.

:-)

Russ

- --

---

From: anoop at brocade.com (Anoop Ghanwani)
Date: Wed, 7 Nov 2007 06:00:52 -0800

> Sent: Wednesday, November 07, 2007 3:53 AM
> To: Anoop Ghanwani
> > The subinterfaces are there because an RBridge is also a 
> bridge.  Just 
> > like a bridge has VLANs configured on ports, an RBridge 
> will also have 
> > VLANs configured on ports.  The reason this is needed is because we 
> > have to know which VLANs are configured on a port when we receive a 
> > multicast packet from another RBridge that needs to be forwarded on 
> > the port.
> 
> I don't see where this matters.... All that matters is which 
> egress devices are within the correct vlan for the multicast 
> packet you've just received. You are forwarding to egress 
> devices, not along vlans within the cloud.
> 
> IMHO, this is why this entire confusion has arisen.... You 
> don't need to forward along a given tree, and along a given 
> vlan, and glue vlans together.... Choose one, not all three. 

We don't forward along a tree except for multicast.
We don't glue VLANs together unless they have the
same VID.  And there's no way around that either.

> The entire point of rbridges is that the entire "core" of the 
> rbridge network forwards towards egress bridges, rather than 
> mimicking the virtual topologies along the edge.
> You're now introducing requirements to do both--treat the 
> core as a vlan free space, and only forward along vlans 
> within the core.
> 
> It makes no sense.

I disagree.  What is the point in sending traffic to
an egress RBridge if it is going to discard it anyway?
 
> > We are talking about putting some VLAN ID that is configured on the 
> > port.
> 
> The phrase "some random vlan number, just to get the packet 
> through the LAN," has been used multiple times on list. 

Well at least I have never used that, so I'll let
others who have proposed that I idea defend it.

> Second, restricting all traffic flowing between any set of 
> rbridges on a single link to one vlan across that link makes no sense.

Then you will have the problems for multicast pointed
out by Radia in an earlier email.
 
> >> Routers operate exactly as I described previously. If a router 
> >> receives a packet on an interface, it will:
> >>
> >> 3a. If the outbound interface is a subinterface, the layer 
> 2 header 
> >> will include, of course, a vlan header.
> >> 3b. If the outbound interface is not a subinterface, the layer 2 
> >> header will not include a vlan header.
> > 
> > I agree with this.
> 
> Then you don't need all this vlan stuff in the middle. You 
> are forwarding through the underlying cloud to the address of 
> an egress device. That address should be in the tunnel encap 
> once the packet enters the cloud.

You deleted my nice picture with the routers discussing
the tagging/untagging issue.  You have to follow the
tag/untag rules of the intermediate bridged clouds.
You don't need it if there is no intermediate cloud.

> It appears we are creating different forwarding rules for 
> multicast than for unicast, without considering the 
> implications of such alternate rule sets on the forwarding 
> hardware, or the simplicity of managing and troubleshooting 
> this stuff.

If you have suggestions, we are all ears!  But
your proposal must be complete.  We have spent
_months_ on the list discussing these issues and
we're starting to revisit them all over again.

Anoop

---

From: anoop at brocade.com (Anoop Ghanwani)
Date: Wed, 7 Nov 2007 06:06:39 -0800

> Sent: Wednesday, November 07, 2007 4:44 AM
> To: Anoop Ghanwani
> >>> 3a. If the outbound interface is a subinterface, the 
> layer 2 header 
> Since this is obviously not the forwarding path for rbridges, 
> I think it would be very useful if you could outline the 
> actual forwarding path, with all the possible "if" statements 
> involved.

I thought that is what the draft does.

> If an rbridge receives a unicast packet without a VLAN tag, it will:

Assuming we're talking about the inner tag...

The problem with special casing the no-VLAN case
is that we're now build a new type of bridging 
that combines 802.1D with 802.1Q, and in the 
process will likely break both.  With 802.1Q
a packet always has a VLAN context.  With 802.D
there is no VLAN context.  This matters especially
when you encounter situations with the same
MAC addresses in different VLANs.
 
Anoop

---

From: riw at cisco.com (Russ White)
Date: Wed, 07 Nov 2007 09:44:03 -0500

> I thought that is what the draft does.

The current draft has all of these different forwarding modes in it?

> Assuming we're talking about the inner tag...

No, the entire process. Look at the outer tag, determine it's not the
real vlan (how do you do this?), then you do x, then y, then z....

What's the entire decision tree for all possible types of traffic--not
little bits and pieces of it, the entire thing? IMHO, once you see the
entire tree in one place, you're going to realize this is a very complex
forwarding mechanism, compared to anything currently running.

Forwarding hardware eats power, space, and cooling. Simple forwarding
processes are better than complex ones, where you have to do a lot of
peeking and poking to figure out what to do with a packet.

> MAC addresses in different VLANs.

Why do you need the vlan context in the cloud? You are forwarding to an
egress rbridge, not along a vlan.

:-)

Russ

- --

---

From: anoop at brocade.com (Anoop Ghanwani)
Date: Wed, 7 Nov 2007 08:39:30 -0800

> Sent: Wednesday, November 07, 2007 6:44 AM
> To: Anoop Ghanwani

It's been a while since I looked at it, but it looked
reasonable in terms of forwarding rules.  We've had 
some discussions around minor issues but nothing to
the extent of revamping the whole thing.
 
> No, the entire process. Look at the outer tag, determine it's 
> not the real vlan (how do you do this?), then you do x, then 
> y, then z....

Well, if the frame is not addressed to the RBridge,
or if it's not addressed to the All-RBridges multicast
address, then you pretty much treat it like
a bridged frame.  I really recommend reading the
draft.  Even in its current version it will tell
you a lot about the issues and the thought process
that has got us to where we are.

> What's the entire decision tree for all possible types of 
> traffic--not little bits and pieces of it, the entire thing? 
> IMHO, once you see the entire tree in one place, you're going 
> to realize this is a very complex forwarding mechanism, 
> compared to anything currently running.
> 
> Forwarding hardware eats power, space, and cooling. Simple 
> forwarding processes are better than complex ones, where you 
> have to do a lot of peeking and poking to figure out what to 
> do with a packet.

No argument there whatsoever!

> > The problem with special casing the no-VLAN case is that we're now 
> > build a new type of bridging that combines 802.1D with 
> 802.1Q, and in 
> > the process will likely break both.  With 802.1Q a packet 
> always has a 
> > VLAN context.  With 802.D there is no VLAN context.  This matters 
> > especially when you encounter situations with the same MAC 
> addresses 
> > in different VLANs.
> 
> Why do you need the vlan context in the cloud? You are 
> forwarding to an egress rbridge, not along a vlan.

You don't for unicast (assuming you're talking
about the inner tag).  For multicast, it's needed
as an optimization to limit propagation to only
those egress RBridges that are interested in 
the frame.  A lot of this information is discussed
in the draft.

Anoop

---

From: eric.gray at ericsson.com (Eric Gray)
Date: Wed, 7 Nov 2007 10:58:59 -0600

Radia,

	I have to agree with what Russ says below.  I think 
this has been a part of the issue in previous discussions:
people are trying to see things simply (by pretending that
VLANs can be treated arbritrarily) but have been making it
all much more complicated in doing so.

	Russ' description of VLAN interactions is simple and 
correct.

--
Eric Gray
Principal Engineer
Ericsson  

> Sent: Tuesday, November 06, 2007 7:49 PM
> To: Radia Perlman
> iD8DBQFHMQtxER27sUhU9OQRAoeAAKDx4z6UoUgHVEWSMibQ7Z/sOfknDgCg1+YI
> HDaYykz4jypmQnjo9P5KNcU=
> =yDY4

---

From: riw at cisco.com (Russ White)
Date: Wed, 07 Nov 2007 12:00:26 -0500

> the extent of revamping the whole thing.

The draft has been updated to include the discussion of the last two
weeks, and the idea of including a vlan tag on all packets, unicast and
multicast, in order to get across broadcast links?

> the frame.  A lot of this information is discussed

But, the recent discussion has been to add it for _all_ packets, unicast
and multicast.

First, I think we may have overoptimized for multicast--when we get to
the point where we're adding context that's no needed in unicast to
optimize for multicast, we're eating the bandwidth we thought we'd be
saving through the optimization. Second, I think we may be overthinking
the problem in general. There's no reason, I don't think, for vlan
context tags even for multicast within the rbridge cloud. I suspect a
lot of this doesn't revolve around multicast optimization, but rather
around the idea of having fully mixed rbridge/bridge environments.

:-)

Russ

- --

---

From: eric.gray at ericsson.com (Eric Gray)
Date: Wed, 7 Nov 2007 11:11:24 -0600

Anoop,

	When you talk of an implementation that allows for sending
and receiving frames for multiple VLANs in a single interface, I
strongly suspect that this is because your model for what "logical
interfaces" are is different.

	If you define a logical (Ethernet) interface as being - for 
example - qualified by the MAC address and a specific VID, than
it is non-sensical to talk about having multiple VLAN associations
via that logical interface.  Many implementers use the term logical
interface exactly this way.

	On the other hand, if you define logical (Ethernet) interfaces
by MAC address alone - or perhaps using some distinguishing factor,
other than VID - then what you are saying is not incorrect.  

	I wonder, though, how useful that model is from an implementer
perspective.  VID is - with the exception of the SVL case - integral
to the forwarding context associated with any frames received on any
interface (and - obviously - the same would apply when sending, since
there is a similar implied context at the next receiver).  

	Hence - from the perspective of making a forwarding decision -
receiving a frame on a different VLAN is not different from receiving
it on a completely different physical interface.

	What can an implementer gain from distinguishing "forwarding 
context" from "logical interface"?

--
Eric Gray
Principal Engineer
Ericsson  

> [mailto:rbridge-bounces at postel.org] On Behalf Of Anoop Ghanwani
> Sent: Tuesday, November 06, 2007 8:39 PM
> To: Russ White
> Cc: Developing a hybrid router/bridge.; Radia Perlman

---

From: eric.gray at ericsson.com (Eric Gray)
Date: Wed, 7 Nov 2007 11:19:56 -0600

Anoop,

	I think you make the mistake of thinking that - because 
all of the comments appear to be at a high level and none are
specifically calling out flaws in the existing text - there 
are no issues with the existing text.

	It may very well be the case that some of us feel that 
the existing text is heading in a way that will lead to a 
hopeless tangle and that pursuing detailed evaluation of the
existing text only helps to make that happen.

--
Eric Gray
Principal Engineer
Ericsson  

> Sent: Wednesday, November 07, 2007 11:40 AM
> To: Russ White