Subject: [rbridge] (no subject)

From: "Eric Gray" <[email-masked]>
Date: Tue, 4 Dec 2007 12:57:50 -0600

Folks,

	Here is the problem that occurs when VLAN state is inferred
for one VLAN from connectivity provided by another.  This is a
general problem, but has specific applicability to the current
set of assumptions used in the protocol specification.  This came
up in off-line discussions with Anoop Ghanwani (and others) at an
IEEE meeting a couple of weeks ago.

	A key thing to understand in looking at this problem is it
is a comparison between how a network works with 802.1Q bridges
and the same network after some 802.1Q bridges have been replaced
with RBridges.  The example shows a partial RBridge deployment
and this is compared with how it will have worked with 802.1Q
bridges where the example shows RBridges (i.e. - it is an after-
the-fact comparison of L2 forwarding functionality).

	The network looks like this (initially):

      \\\\|////   \\\\\|||/////   \\\|///
        __|__         __|__        __|__
       | B-1 |       | B-2 |      | B-3 |
       |_____|       |_____|      |_____|
          |  \       /     \_____ /  |
          |   \_____/      | B-5 |   |
          |   | B-4 |      |_____|   |
          |   |_____|         |      |
        __|__       \         |      |
       | B-6 |_______\ _______|    __|__
       |_____|        \___________| B-7 |
          |                       |_____|
          |                          |
        __|___                     __|___
       | RB-1 |                   | RB-2 |
       |______|                   |______|
              \         _         /
               \__   __( )___   _/
                  \_(  Core  )_/
                  (_  RBridge _)
                    (_ Cloud _)
                      (_   _)
                        (_)
 
	In this figure, B-1, B-2 and B-3 are aggregation bridges with 
multiple (lots and lots) of VIDs.  

	B-4 is a special purpose bridge used for VLAN-A only, and B-5 
is a special purpose bridge used for VLAN-B only.  

	All remaining bridges are configured to participate in VLAN-A, 
VLAN-B and an arbitrary set of zero or more other VLANs.  Since B-4 
and B-5 are configured for specific VLANs only, the ports on their 
adjacent bridging peers are configured only for those VLANs.  

	To be clear, the links between B-4 and B-7, and between B-6 
and B-5 are not connected (they merely overlap in the drawing).
 
	In this network, RB-1 and RB-2 are both RBridges and both have 
access to VLAN A and VLAN B and each other (via both VLAN A and VLAN 
B) - as well as the same arbitrary set of zero or more VLANs that 
any of the other bridges in the drawing have.  However, the two 
RBridges use another VLAN - say VLAN C - to exchange hellos.  Under
the normal operating conditions intended, this works fine and RB-1 
and RB-2 may separately be elected DRB for either of VLAN A or VLAN B.
 
	If bridge B-4 fails, then VLAN A would be segmented, at least 
temporarily.  Hellos continue to work, however, so the 2 RBridges 
do not discover the partition and the DRB election remains unchanged.  
In this case, part of the VLAN is orphaned - particularly from the
perspective of any locally attached end-stations.  

	However, this is not acceptable behavior.  No misconfiguration
exists and the ideal (and reasonably expected) behavior would be for 
the RBridges to discover the partition and redo the DRB election - 
making RB-1 the DRB for one partition and RB-2 the DRB for the other 
partition.

	If (when) RB-1 and RB-2 were 802.1Q bridges, using MSTP for 
multiple VLANs (in particular, for VLAN A and B), this failure will
have resulted in re-running (M)STP for the affected VLAN connectivity
and the segmentation (partitioning) would be healed.  In the same way,
if the status of VLAN's A and B were derived directly from messages
that use VLAN A and VLAN B (as opposed to using VLAN C), this same
robust behavior would occur.

--
Eric Gray
Principal Engineer
Ericsson 

_______________________________________________
rbridge mailing list
[email-masked]
http://mailman.postel.org/mailman/listinfo/rbridge

---

From: Radia Perlman <[email-masked]>
Date: Tue, 04 Dec 2007 19:14:40 -0800

Putting in a subject line since Eric didn't.

To restate Eric's concern -- it is possible that VLAN A might be 
partitioned on a link, and since the DRB selects only
a single VLAN-A-forwarder, some VLAN A endnodes on the cloud might get 
orphaned (since they are on the
other side of the partition from the appointed VLAN A forwarder on the 
link).

And that is correct.

So, what is the alternative? Everything is an engineering tradeoff.
We could run DRB elections on every possible VLAN, and with a 
partitioned VLAN, wind up with multiple DRBs for
that VLAN. If there were n VLANs, we'd wind up with n DRBs (one per 
VLAN), n pseudonodes, n times as many Hello
messages, etc.

We chose to consider a partiitoned VLAN, caused by bridges configured to 
not pass data traffic for a particular VLAN,
as a misonfiguration. This can happen with bridges anyway, if you mark a 
bunch of your potential through links as not
being allowed for VLAN A transit. The solution in the current spec is 
low overhead (at most one pseudonode per link,
one Hello per RBridge except for the DRB) and relatively simple. 
Hopefully eventually more bridges will be replaced by
RBridges and this sort of thing won't happen.

Radia

---

From: "Eric Gray" <[email-masked]>
Date: Wed, 5 Dec 2007 12:41:41 -0600

Radia,

	I've been sort of wondering what the point is in having
a subject line anyway.  After all, the subject surely must be
obvious from the text in the message, right?  :-)

Thanks!

--
Eric Gray
Principal Engineer
Ericsson  

> -----Original Message-----
> From: Radia Perlman [mailto:[email-masked]] 
> Sent: Tuesday, December 04, 2007 10:15 PM
> To: Eric Gray
> Cc: Developing a hybrid router/bridge.
> Subject: Orphaned endnodes with partitioned VLANs on a cloud
> Importance: High
>

---

From: "Eric Gray" <[email-masked]>
Date: Wed, 5 Dec 2007 13:19:38 -0600

Radia,

	I don't think this is either as hard to solve as you make
it, nor as easy to ignore as it seems you would like us to think.

	From what you say, we have apparently decided in the
protocol specification that we're going to declare something
to be a misconfiguration once we replace one or more 802.1Q
bridges with RBridges on a one-for-one basis - that was not a
misconfiguration previously - simply because doing so makes it 
easier to do the protocol specification.

	Frankly, in my opinion, that is an excellent example of
why that type of decision is not usually made in the protocol
specification process - except maybe as a last resort (clearly
nobody expects a protocol specification to do the impossible).

	So, to be clear, what you're proposing to do is to make 
yet another decision not to support existing L2 forwarding
capabilities with RBridges in the interest of expediency.

	Is this decision explicitly supported somewhere by WG
consensus?  Or is this yet another thing that we're going to
let slip through the cracks?

	To show that this is not really as difficult as you make
it sound, let's look at something Erik said during the meeting.  

	Erik said that this situation would be a mis-configuration 
if there was a single spanning tree for all VLANs anyway.  Yes,
that is true, but one of the things that a lot of the people in
the TRILL working group are apparently unaware of is the fact 
that Multiple Spanning Trees (MSTP - or 802.1S at one time) is
now a part of the base 802.1Q specification.

	While this does not guarantee that multiple spanning trees 
would actually be configured - and it never guaranteed that there
would be a spanning tree for each VLAN - it does allow VLAN's to
be correctly configured as I showed in my figure earlier (see in
the forwarded text below).

	To allow a similar level of support in RBridges, it is only
necessary to _allow_ per VLAN (or per-VLAN group - though that is 
a separate, and probably orthogonal, issue to this example) IS-IS 
peering - which the protocol specification now seems to explicitly 
forbid.  

	In the example, VLAN A and VLAN B IS-IS hello messages being
propagated via VLAN A and VLAN B explicitly, with all other VLAN
IS-IS hello messages using a single VLAN (VLAN C, for instance) is
all that would be required to correctly support this scenario - and
achieve the scalability that people apparently are concerned about.

	In fact, a more general statement can be made.  It will be the
case generally that it should be possible to support some number of 
per-VLAN (or VLAN-group) IS-IS peering (or at least IS-IS hello 
messaging) relationships as needed to support a topology in which 
specific links are excluded (by configuration) from VLAN used for 
the default VLAN group peering/hello-messaging.

	In order for a configuration to require any number N of 
distinct peering relationships on a per-VLAN, or per VLAN group,
basis - it is necessary to have N or more distinct links that 
exclude one or more VLANs from each of all of other relationships.  

	Without spending too much energy or thought on this, it is 
obvious (or not very difficult to realize) that complexity of the 
peering relationships is then bounded by the complexity of the 
configured topology.  This argue that a customer would have to 
have really good reasons to want to make this very complex.

	And, the absolute upper limit on the peering complexity is
directly analogous to the complexity of "peering" in MSTP - i.e.
- if MSTP implementations currently only support a relatively 
small number of separate spanning trees, then RBridges would not
be expected to necessarily support a larger number of peering
relationships.

	Based on all of this, I would argue that the problem is not
hard to solve.  Also, the cost of not solving it is not small.

--
Eric Gray
Principal Engineer
Ericsson

---

From: "Eric Gray" <[email-masked]>
Date: Wed, 5 Dec 2007 13:24:55 -0600

Anoop/Radia,

	This is not exactly the note on which we left off
in the off-line discussion.  As I recall (isn't E-Mail
great!), I replied to this with the following:

============================================================
	If the RBridges were inserted to replace 802.1Q 
bridges, and each was configured as I've described for access 
to both VLAN A and B, then the bridge failure I described 
would simply result in a different spanning tree for VLAN A.  
VLAN A would not be broken, it would simply be (potentially) 
less optimal.
============================================================

	This was specifically in response to your comment (to
the effect that this wouldn't have worked in an 802.1Q LAN -
so it would have been a misconfiguration there as well).

	In response to the above observation you said that you
agreed that this would not have been a misconfiguration error
in that case.  Aactually, what you said exactly was "Yes, you 
are right."

	More on this in a separate mail message response to 
Radia...

Thanks!

--
Eric Gray
Principal Engineer
Ericsson  

> From: Anoop Ghanwani [mailto:[email-masked]] 
> Sent: Tuesday, December 04, 2007 11:27 PM
> To: Radia Perlman; Eric Gray
> Subject: RE: [rbridge] Orphaned endnodes with partitioned 
> VLANs on a cloud
> Importance: High
> 
> 
> Radia,
> 
> This is what I told Eric during the offline discussion
> as well - that this is a misconfiguration and as long
> as bad things aren't happening, it's up to the administrator
> to configure things so that they work correctly when
> such failures happen.
> 
> It is no worse than what can happen in a misconfigured
> bridged network.
> 
> Anoop 
> 
> > From: [email-masked] 
> > [mailto:[email-masked]] On Behalf Of Radia Perlman
> > Sent: Tuesday, December 04, 2007 7:15 PM
> > To: Eric Gray
> > Subject: [rbridge] Orphaned endnodes with partitioned VLANs 
> on a cloud
> > 
> > To restate Eric's concern -- it is possible that VLAN A might 
> > be partitioned on a link, and since the DRB selects only a 
> > single VLAN-A-forwarder, some VLAN A endnodes on the cloud 
> > might get orphaned (since they are on the other side of the 
> > partition from the appointed VLAN A forwarder on the link).
> > 
> > And that is correct.
> > 
> > partitioned VLAN, wind up with multiple DRBs for that VLAN. 
> > If there were n VLANs, we'd wind up with n DRBs (one per 
> > VLAN), n pseudonodes, n times as many Hello messages, etc.
> > 
> > We chose to consider a partiitoned VLAN, caused by bridges 
> > configured to not pass data traffic for a particular VLAN, as 
> > a misonfiguration. This can happen with bridges anyway, if 
> > you mark a bunch of your potential through links as not being 
> > allowed for VLAN A transit. The solution in the current spec 
> > is low overhead (at most one pseudonode per link, one Hello 
> > per RBridge except for the DRB) and relatively simple. 
> > > 	Here is the problem that occurs when VLAN state is 
> > inferred for one 
> > > VLAN from connectivity provided by another.  This is a general 
> > > problem, but has specific applicability to the current set of 
> > > assumptions used in the protocol specification.  This came up in 
> > > off-line discussions with Anoop Ghanwani (and others) at an IEEE 
> > > meeting a couple of weeks ago.
> > >
> > > 	A key thing to understand in looking at this problem is it is a 
> > > comparison between how a network works with 802.1Q 
> bridges and the 
> > > same network after some 802.1Q bridges have been replaced with 
> > > RBridges.  The example shows a partial RBridge deployment 
> > and this is 
> > > compared with how it will have worked with 802.1Q bridges 
> where the 
> > > example shows RBridges (i.e. - it is an after- the-fact 
> > comparison of 
> > > L2 forwarding functionality).
> > >
> > > 	B-4 is a special purpose bridge used for VLAN-A only, 
> > and B-5 is a 
> > > special purpose bridge used for VLAN-B only.
> > >
> > > 	All remaining bridges are configured to participate in 
> > VLAN-A, VLAN-B 
> > > and an arbitrary set of zero or more other VLANs.  Since 
> > B-4 and B-5 
> > > are configured for specific VLANs only, the ports on 
> their adjacent 
> > > bridging peers are configured only for those VLANs.
> > >
> > > 	To be clear, the links between B-4 and B-7, and between 
> > B-6 and B-5 
> > > are not connected (they merely overlap in the drawing).
> > >  
> > > 	In this network, RB-1 and RB-2 are both RBridges and 
> > both have access 
> > > to VLAN A and VLAN B and each other (via both VLAN A and VLAN
> > > B) - as well as the same arbitrary set of zero or more 
> > VLANs that any 
> > > of the other bridges in the drawing have.  However, the two 
> > RBridges 
> > > use another VLAN - say VLAN C - to exchange hellos.  Under 
> > the normal 
> > > operating conditions intended, this works fine and RB-1 and 
> > RB-2 may 
> > > separately be elected DRB for either of VLAN A or VLAN B.
> > >  
> > > temporarily.  Hellos continue to work, however, so the 2 
> > RBridges do 
> > > not discover the partition and the DRB election remains unchanged.
> > > 	However, this is not acceptable behavior.  No 
> > misconfiguration exists 
> > > and the ideal (and reasonably expected) behavior would be for the 
> > > RBridges to discover the partition and redo the DRB 
> > election - making 
> > > RB-1 the DRB for one partition and RB-2 the DRB for the other 
> > > partition.
> > >
> > > 	If (when) RB-1 and RB-2 were 802.1Q bridges, using MSTP 
> > for multiple 
> > > VLANs (in particular, for VLAN A and B), this failure will have 
> > > resulted in re-running (M)STP for the affected VLAN 
> > connectivity and 
> > > the segmentation (partitioning) would be healed.  In the 
> > same way, if 
> > > the status of VLAN's A and B were derived directly from 
> > messages that 
> > > use VLAN A and VLAN B (as opposed to using VLAN C), this 
> > same robust 
> > > behavior would occur.
> > >
> > >
> > > --
> > > Eric Gray
> > > Principal Engineer
> > > Ericsson
> > >

---

From: Dinesh G Dutt <[email-masked]>
Date: Thu, 06 Dec 2007 10:29:49 -0800

This is another reason for me to be nervous about making these changes 
now. The old method where we did DRB per VLAN, a single pseudo-node for 
all VLANs that the Rbridge was DRB for seemed sufficient to me and 
avoided all these issues. We've gotten into this mess because someone 
decided that sending multiple Hellos (one per active VLAN) is a huge 
burden on the CPU. I disagree with that assumption and would like to 
avoid all these issues by falling back to what we had earlier.

Dinesh

-- 
We make our world significant by the courage of our questions and by 
the depth of our answers.                               - Carl Sagan
_______________________________________________
rbridge mailing list
[email-masked]
http://mailman.postel.org/mailman/listinfo/rbridge

---

From: Russ White <[email-masked]>
Date: Thu, 06 Dec 2007 14:58:04 -0500

> avoid all these issues by falling back to what we had earlier.

IMHO, the mechanism proposed is broken in multiple ways.... I would be
glad to send out a few emails explaining specific situations where this
mechanism of "fixing broken connections in the bridged cloud in the
middle" is, itself, broken. I actually don't think you can fix this
problem--people will find more ways to misconfigure this stuff than you
can account for, or try to work around.

Again, IMHO, it shouldn't be a part of the rbridge spec to fix broken
connections in the middle of a cloud of rbridges. If folks want to
cogitate on the problems involved, and write docs in that area, it's
fine, but it shouldn't be a part of any sort of base specification.

First, there are a ton of different media types involved. Rbridges could
run over wireless media, MPLS, ATM, Frame, IP, and all sorts of other
things. Even if you say: "Ethernet only," there's Ethernet, and then
there's Ethernet.

Let's stop getting hung up on this problem, and figure out how to make
rbridges work at a base level.

:-)

Russ

- --
[email-masked] CCIE <>< Grace Alone

---

From: Russ White <[email-masked]>
Date: Thu, 06 Dec 2007 14:58:04 -0500

:-)

Russ

- --

---

From: Russ White <[email-masked]>
Date: Thu, 06 Dec 2007 14:58:04 -0500

:-)

Russ

- --

---

From: Russ White <[email-masked]>
Date: Thu, 06 Dec 2007 14:58:04 -0500

:-)

Russ

- --

---

From: Russ White <[email-masked]>
Date: Thu, 06 Dec 2007 14:58:04 -0500

:-)

Russ

- --

---

From: Russ White <[email-masked]>
Date: Thu, 06 Dec 2007 15:20:06 -0500

>> avoid all these issues by falling back to what we had earlier.

BTW--I actually agree with Dinesh' message here--there is no "massive
burden" of sending one hello per vlan. That's what I get for picking a
random message to reply to. :-)

In the real world, if someone configured 4000 parallel transit vlans,
we'd tell them to please redesign their network. In fact, most of the
routing sorts of devices we're talking about will only hold 256 or so
forwarding entries for any given destination--so 4000 is something of a
mute point, I think.

I'm in agreement that we should go back to the original concept--let the
user decide which logical links rbridge traffic should run on, and let
them configure it. If they misconfigure it, they do so at their own
cost. As I said before--they're going to find more ways to misconfigure
it than you can fix, and they're going to find them faster than you can
think of ways to fix them.

One of the things they'll need to consider when configuring this is the
overhead of multiple IS-IS hello's. It's already something they have to
think about in routing, so I don't see it as any great burden.

:-)

Russ

- --

---

From: Radia Perlman <[email-masked]>
Date: Thu, 06 Dec 2007 13:57:34 -0800

The two possible designs people are thinking about are:

a) separate DRB election per VLAN, possibly a different DRB per VLAN, 
and a different pseudonode (visible outside that link) for
each VLAN. Per-VLAN adjacencies to each neighbor on that link. And, get 
rid of the safety check of "report root bridge, and RB2 should
not decapslate something from ingress RB1 if RB1 reports the same root 
bridge", because with a partitioned VLAN, both RB1 and RB2
will see the same root bridge, and it looks like people advocating this 
option want to make sure both RB1 and RB2 will encpasulate/decapsulate
from the same link. Tough luck for orphaned endnodes if a VLAN is 
partitioned and there is no RBridge in the partition with the endnode.

b) one DRB, one pseudonode, tough luck for orphaned endnodes if a VLAN 
is partitioned, except for endnodes in the same partition
as the RBridge appointed forwarder for that VLAN.

The downside of a) is scalability. And if there is a link that is 
willing for any VLAN to traverse, wouldn't that be 4000 VLANs to
send Hellos on, on that link?

The downside of b) is that if there is a partitioned VLAN, then some 
endnodes will be orphaned. But a partitioned VLAN will only occur
if someone has configured bridges to refuse to pass certain VLANs, and 
can be easily fixed through a number of ways (like, for instance,
changing the configuration of the bridges). And note that orphaned 
endnodes can happen no matter what TRILL does because it could happen that
VLAN A is partitioned and there is no RBridge on one of the partitions. 
Endnodes in that partition would be orphaned even if we did a)

Note that if TRILL is trying to exactly copy all bridge functionality,
we are not doing that. Some people apparently configure partitioned 
VLANs, I've heard, because they are reusing VLAN nmbers.
TRILL is specifically not keeping different instances of VLAN A 
separate, but making the assumption that VLAN A = VLAN A.
I think it is perfectly reasonable to do b), which is safer (because of 
the root bridge check), and more scalable, and consider a link
with a partitioned VLAN as a configuration mistake. It seems like a 
better way of accomplishing whatever it is that the customers were
attempting to accomplish with restricting certain VLANs from traversing 
certain links, would be doing all the fancy traffic engineering
stuff using layer 3 techniques that have been around for awhile.

That being said---I'm always anxious to please everyone, here's a 
potential compromise to solve the partitioned VLAN problem.

The rule is: If you are appointed VLAN A forwarder, then you send 
Hellos, not just on the one VLAN specified by the DRB, but also
on VLAN A. If the DRB announces its VLAN forwarder assignments in its 
Hello, then if RB2 attaches to VLAN A, and knows that
RB1 is appointed VLAN A forwarder, then RB2, if it does not receive some 
VLAN A tagged Hellos from RB1 knows there
is a problem.

What to do when you know there's a problem? Here are some suggestions:
a) log a network management event
b) do separate DRB elections on any VLANs that have been detected
as being partiitoned. Wind up with a DRB, and pseudonode for each partition.
And get rid of the root bridge safety check because all the RBridges in 
all VLAN A partitions will see the same root bridge
anyway. Note: I find this scary (I like the safety check). It is more 
scalable than do separate DRB elections for every VLAN,
since except in the (hopefully very rare) case of a partitioned VLAN, 
there will be just a single Hello election and single pseudonode.

I strongly think we should have just a single DRB for a link. I'd prefer 
that DRB be the only one that forwards data to/from the link, but
I don't think it's that complicated or unsafe to have the DRB data 
packet forwarders per VLAN in order to do load splitting.  I prefer just
not worrying at all about endnodes orphaned by partitioned VLANs. 
However, I think it's OK to attempt to detect partitioned VLANs
by having the VLAN X forwarder send Hellos on VLAN X (in addition to the 
common VLAN).

If indeed there are 4000 VLANs on the link, that does mean that there 
will be 4000 Hellos, but not multiplied by the number of RBridges.
All RBridges will send Hellos on the single common VLAN specified by the 
DRB, plus whoever is VLAN x forwarder, for each value of x,
will send an additional Hello tagged with x.

Radia

---

From: Russ White <[email-masked]>
Date: Thu, 06 Dec 2007 18:07:53 -0500

> packet forwarders per VLAN in order to do load splitting.  

I'd prefer to let the user configure the broadcast links in the middle
the way they want to.... :-) I'd prefer to have a DRB per vlan, rather
than playing with different schemes to have a DRB per link, no matter
how many vlans you might happen to have.

There are three situations where you might have multiple parallel vlans
across a link:

1. It's a trunk. Well, that's a special case.

2. It's 4000 parallel transit links. Please send this person to the
nuthouse. I don't want them designing any network my data runs on.

3. It's 4000 parallel host attachment points. In this case, they don't
need to be transit links, and hence, they don't need to be carrying any
IS-IS hellos at all. This is why most all implementations have "passive
interfaces."

> will send an additional Hello tagged with x.

I don't think the DRB should specify the "hello vlan" at all,
honestly.... There are a lot of reasons that I think we should do a
hello per vlan, and leave it at that. I'll be glad to give some
examples, but they are long, and I should really send them in three
separate emails, probably, so people can try and understand them all really.

:-)

Russ

- --

---

From: "Anoop Ghanwani" <[email-masked]>
Date: Thu, 6 Dec 2007 18:42:59 -0800

> IMHO, the mechanism proposed is broken in multiple ways.... I 
> would be glad to send out a few emails explaining specific 
> situations where this mechanism of "fixing broken connections 
> in the bridged cloud in the middle" is, itself, broken. I 
> actually don't think you can fix this problem--people will 
> find more ways to misconfigure this stuff than you can 
> account for, or try to work around.
> 
> Again, IMHO, it shouldn't be a part of the rbridge spec to 
> fix broken connections in the middle of a cloud of rbridges. 
> If folks want to cogitate on the problems involved, and write 
> docs in that area, it's fine, but it shouldn't be a part of 
> any sort of base specification.

I don't think there's anything in the RBridge spec that's
attempting to fix broken connections.  It just detects any
serious problems and that's about it.

Anoop

---

From: "Anoop Ghanwani" <[email-masked]>
Date: Thu, 6 Dec 2007 18:38:36 -0800

Dinesh,

Let's work through the example.  I've asked Eric
for some more info and I'll respond once I get it. 

Control plane scaling issues are a big concern
for bridges.  It is also a concern for routers
until you get into the class of really big 
routers that do things like hold the entire
routing table.

While 4K VLANs is the limit I often cite, 
scaling will be a big problem in a device
with large port count and a few hundred
VLANs.

There is a reason why 802.1Q limits the 
number of STP instances to 64.

Anoop 

> [mailto:[email-masked]] On Behalf Of Dinesh G Dutt
> Sent: Thursday, December 06, 2007 1:30 PM
> To: Eric Gray
> Subject: Re: [rbridge] (no subject)
> 
> This is another reason for me to be nervous about making 
> these changes now. The old method where we did DRB per VLAN, 
> a single pseudo-node for all VLANs that the Rbridge was DRB 
> for seemed sufficient to me and avoided all these issues. 
> We've gotten into this mess because someone decided that 
> sending multiple Hellos (one per active VLAN) is a huge 
> burden on the CPU. I disagree with that assumption and would 
> like to avoid all these issues by falling back to what we had earlier.
> 
> 
> 
> Dinesh
> Eric Gray wrote:
> > Folks,
> >
> > comparison between how a network works with 802.1Q bridges and the 
> > compared with how it will have worked with 802.1Q bridges where the 
> > are configured for specific VLANs only, the ports on their adjacent

---

From: "Anoop Ghanwani" <[email-masked]>
Date: Thu, 6 Dec 2007 18:32:37 -0800

(There was some problem with the outgoing
alias of my email and as a result my posts
haven't been making it to the list; just
to private parties listed in the recipient
list.  Hopefully that should be fixed at
the time I send this message.)

Hi Eric,

I can't fully remember the example.  Would it
be possible for you to put the VLAN memberships
on the various ports in your figure?  That would
help me understand the picture better.
(I know I may be asking for much but please
be patient with me because I'd like to address
all your concerns.)

It is possible to misconfigure bridged LANs
so that VLANs end up getting partitioned.
The automated way to avoid that is using 
MVRP.

Anoop 

> From: Eric Gray [mailto:[email-masked]] 
> Sent: Wednesday, December 05, 2007 2:25 PM
> To: Anoop Ghanwani; Radia Perlman
> 	This is not exactly the note on which we left off in 
> the off-line discussion.  As I recall (isn't E-Mail great!), 
> I replied to this with the following:
> 
> 	More on this in a separate mail message response to Radia...
> 
> Thanks!
> 
> --
> Eric Gray
> Principal Engineer
> Ericsson  
> 
> VLANs on a 
> > cloud
> > This is what I told Eric during the offline discussion as 
> well - that 
> > this is a misconfiguration and as long as bad things aren't 
> happening, 
> > it's up to the administrator to configure things so that they work 
> > correctly when such failures happen.
> > 
> > It is no worse than what can happen in a misconfigured bridged 
> > network.
> > 
> > Anoop
> > 
> > > partitioned on a link, and since the DRB selects only a single 
> > > VLAN-A-forwarder, some VLAN A endnodes on the cloud might get 
> > > orphaned (since they are on the other side of the 
> partition from the 
> > > If there were n VLANs, we'd wind up with n DRBs (one per VLAN), n 
> > > pseudonodes, n times as many Hello messages, etc.
> > > 
> > > configured to not pass data traffic for a particular VLAN, as a 
> > > misonfiguration. This can happen with bridges anyway, if 
> you mark a 
> > > bunch of your potential through links as not being 
> allowed for VLAN 
> > > A transit. The solution in the current spec is low 
> overhead (at most 
> > > one pseudonode per link, one Hello per RBridge except for 
> the DRB) 
> > > and relatively simple.

---

From: Russ White <[email-masked]>
Date: Thu, 06 Dec 2007 22:00:08 -0500

> The automated way to avoid that is using 

Is MVRP, or emulation of MVRP, in scope for this WG?

:-)

Russ

- --

---

From: Russ White <[email-masked]>
Date: Thu, 06 Dec 2007 21:54:18 -0500

> I'm not sure what you mean by parallel transit link.
> Perhaps you can elaborate?

Any link over which traffic may pass from rbridge to rbridge, rather
than from rbridge to host.

> Passive interfaces won't work for RBridges because you
> could get really nasty loops and duplication of traffic.
> These devices are different than routers.

Can you please post a specific example? I've posted specific examples of
where trying to infer one piece of state from another results in very
bad results--and, IMHO, it will always be this way. If you're going to
claim that there are possible loops which cannot be resolved without
inferring this state, please post an example on the list.

:-)

Russ

- --

---

From: Russ White <[email-masked]>
Date: Thu, 06 Dec 2007 21:59:24 -0500

> routers that do things like hold the entire

Not really.... In real life, all routers suffer from scaling issues, no
matter what their processors look like. Massively parallel links are one
thing any good routing book will tell you to avoid like the plague.

Not to mention that highly parallel links will slow down convergence
dramatically, sometimes actually causing convergence to fail altogether.
I'd guess that 50% of the networks I've seen large scale failures in
have massive parallelism as a contributing factor.

:-)

Russ

- --

---

From: Russ White <[email-masked]>
Date: Thu, 06 Dec 2007 22:07:37 -0500

> I think the consensus at the last meeting
> was that RBridges MAY choose to participate
> in MVRP.

Does that mean they MUST "work around" MVRP on the links between the
rbridges? OR does it mean they may support MVRP like functionality
edge-to-edge? What does "participate" mean, precisely?

:-)

Russ

- --

---

From: "Anoop Ghanwani" <[email-masked]>
Date: Thu, 6 Dec 2007 19:01:35 -0800

> From: Russ White [mailto:[email-masked]] 
> Sent: Thursday, December 06, 2007 9:59 PM
> To: Anoop Ghanwani
> Cc: Dinesh G Dutt; Eric Gray; Developing a hybrid router/bridge.
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> 
> > Control plane scaling issues are a big concern for bridges.  It is 
> > also a concern for routers until you get into the class of 
> really big 
> > routers that do things like hold the entire routing table.
> 
> Not really.... In real life, all routers suffer from scaling 
> issues, no matter what their processors look like. Massively 
> parallel links are one thing any good routing book will tell 
> you to avoid like the plague.

The point is most bridges don't have scaling issues like
that.  If we're going to build a technology that costs
as much as routers and has the same (if not even worse
scaling properties), why would people want to deploy it?  

Anoop

---

From: Russ White <[email-masked]>
Date: Thu, 06 Dec 2007 22:06:29 -0500

> scaling properties), why would people want to deploy it?  

I would argue that most bridges do have scaling issues like that, first
of all. Second, I would argue that rbridges, built properly, and
deployed properly, won't have worse scaling properties. Finally, I'd
point out that rbridges might not replace STP bridges, but rather
augment them in some specific places, etc.

In general, I consider this line of reasoning a red herring. We need to
focus on realistic situations, and find solutions which don't incur
large new pieces of complexity for very small gains. I would also point
out that if you're counting on this "elect a single DRB on a segment"
idea to prevent problems in the case you're using as an example--it
won't in any case. I've already shown two cases where it fails, and can
easily find at least one more. Those cases apply to your examples, as well.

:-)

Russ

- --

---

From: Russ White <[email-masked]>
Date: Thu, 06 Dec 2007 22:20:09 -0500

> But the level of participation that I envisage is
> that of end station.

Why?

We should *never* assume an underlying media of any type. It will tie
the spec into a corner, and make it impossible to use in other situations.

:-)

Russ

- --

---

From: "Anoop Ghanwani" <[email-masked]>
Date: Thu, 6 Dec 2007 18:49:32 -0800

> [mailto:[email-masked]] On Behalf Of Russ White
> Sent: Thursday, December 06, 2007 6:08 PM
> To: Radia Perlman
> Subject: Re: [rbridge] Orphaned endnodes with partitioned 
> VLANs on a cloud
> 
> > I strongly think we should have just a single DRB for a link. I'd 
> > prefer that DRB be the only one that forwards data to/from 
> the link, 
> > but I don't think it's that complicated or unsafe to have 
> the DRB data 
> I'd prefer to let the user configure the broadcast links in 
> the middle the way they want to.... :-) I'd prefer to have a 
> DRB per vlan, rather than playing with different schemes to 
> have a DRB per link, no matter how many vlans you might 
> happen to have.
> 
> There are three situations where you might have multiple 
> parallel vlans across a link:
> 

And one that needs to be handled.

> 2. It's 4000 parallel transit links. Please send this person 
> to the nuthouse. I don't want them designing any network my 
> data runs on.

> 3. It's 4000 parallel host attachment points. In this case, 
> they don't need to be transit links, and hence, they don't 
> need to be carrying any IS-IS hellos at all. This is why most 
> all implementations have "passive interfaces."

> > All RBridges will send Hellos on the single common VLAN 
> specified by 
> > the DRB, plus whoever is VLAN x forwarder, for each value 
> of x, will 
> > send an additional Hello tagged with x.
> 
> honestly.... There are a lot of reasons that I think we 
> should do a hello per vlan, and leave it at that. I'll be 
> glad to give some examples, but they are long, and I should 
> really send them in three separate emails, probably, so 
> people can try and understand them all really.
> 

Remember we will run into scaling issues even with
100's of VLANs because there are many ports on 
typical bridges.  These hellos have to be sent
even on so called edge ports in order to detect
misconfiguration problems that could result in
loops.

Anoop

---

From: Russ White <[email-masked]>
Date: Thu, 06 Dec 2007 22:17:02 -0500

> Because they don't have to send 4000 BDPUs if they have
> 4000 VLANs configured on that port.

Then, again, this suggests a solution that doesn't require the
complexity you're talking about. A simple IS-IS hello with a marker
saying: "This is not a transit link" would do nicely, probably.

> Just the same example above.  RB1 & RB2 are edges to the
> RBridge core but they are each connected to bridged LANs
> configured with 4K VLANs.

And why are you connecting them this way? To provide resilience to a set
of servers? Then there are other solutions. To provide 4000 transit
links for better throughput? Then you need a new network.

:-)

Russ

- --

---

From: Russ White <[email-masked]>
Date: Thu, 06 Dec 2007 22:03:23 -0500

> Rbridge core
> |         |
> RB1      RB2
> |         |
> +---------+
> 
> This is the case...RB1 and RB2 are connected
> to the core on the top and at the bottom they
> are supposedly edge ports.  However, these 
> accidentally get connected.  What we have is 
> loop and multicast traffic which gets sent
> into the core by both RB1 and RB2.

Two things:

1. There are other ways to resolve this. uRPF would probably would, in
fact. Or, perhaps, sending out hellos marked so they don't form an
adjacency in IS-IS. I should point out that modern bridges don't seem to
have a problem with the bpdu transmissions in this situation, so I don't
see why they would have a problem with IS-IS hellos.

2. We seem to tolerate this misconfiguration problem in modern day
switches all the time, and everyone just seems to live with it.

I would point out that the link here is not intended to transit traffic.
I'm waiting for an example where you'd have 4000 VLANs connected between
two rbridges which are intended to transit traffic.

:-)

Russ

- --

---

From: "Anoop Ghanwani" <[email-masked]>
Date: Thu, 6 Dec 2007 18:59:58 -0800

Rbridge core
|         |
RB1      RB2
|         |
+---------+

Anoop

> Sent: Thursday, December 06, 2007 9:54 PM
> To: Anoop Ghanwani
> Cc: Radia Perlman; Developing a hybrid router/bridge.
> Any link over which traffic may pass from rbridge to rbridge, 
> rather than from rbridge to host.
> 
> > Passive interfaces won't work for RBridges because you could get 
> > really nasty loops and duplication of traffic.
> Can you please post a specific example? I've posted specific 
> examples of where trying to infer one piece of state from 
> another results in very bad results--and, IMHO, it will 
> always be this way. If you're going to claim that there are 
> possible loops which cannot be resolved without inferring 
> this state, please post an example on the list.
> 
> :-)
> 
> Russ
> 
> - --
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.6 (MingW32)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
> 
> iD8DBQFHWLXaER27sUhU9OQRAgYhAJ9mCcdyuEvuUmVSg4m3s/UcpyXMRgCfbRJD
> MlS3vZJB9buXRju8uiN3eN4=
> =nmrq
> -----END PGP SIGNATURE-----
>

---

From: "Eric Gray" <[email-masked]>
Date: Thu, 6 Dec 2007 20:53:17 -0600

Anoop,

	The picture is a direct variation from the access-like
network picture you drew on a napkin in whatever restaurant
it was that we started talking about this in.

	The aggregation bridges - according to your description
would assign VIDs to aggregated subscribers.  Let us ignore -
for a while (as we did during that discussion) that this is
very explicitly not in scope for the chartered objective and
pretend that this type of deployment is common (or, at least, 
not unheard of) in a large enterprise network.

	As I was then, I am still prepared to stipulate that may
be the case - at least somewhere in the universe.

	In your example, the aggregation bridges would have many
(as in a thousand or more) down-link interfaces which they are
aggregating onto a much smaller number of up-link interfaces.
Your claim at the time was that most such deployments wouldn't
trunk (Q-in-Q) these VIDs - hence all of them would be visible
to the RBridges (RB-1 and RB-2 in my example).  This was the
basis for your claim that per-VLAN peering of IS-IS instances
could produce serious scalability issues.

	This is a not-unreasonable claim to make and a hard claim
to argue against, especially given the already deep level of
suspended disbelief involved at this point in our discussion.

	Now, you propose that I should label the interfaces I've
adopted from your example with VLAN IDs?  Are you sadistic, or
just having a mean moment?  :-)

	Frankly, given the nature of the problem, I can't imagine
why you really need to have that information.  What is important 
is that there are two VLANs (A and B) that are being routed in 
some special way (shown in the diagram) and an arbitrary number 
of VLANs (but necessarily at least 1 and not more than 4092) of 
other VLANs that are also present in the network (as shown - and 
described - in my diagram).

--
Eric Gray
Principal Engineer
Ericsson  

> From: Anoop Ghanwani [mailto:[email-masked]] 
> Sent: Thursday, December 06, 2007 9:33 PM
> To: Eric Gray; Radia Perlman

---

From: Russ White <[email-masked]>
Date: Thu, 06 Dec 2007 22:37:25 -0500

> Probably not...if the VLAN number selected for
> that hello happens to be the one that has no connectivity
> on that link, then hello doesn't make it through
> but the problem remains on all the other VLANs.

That's no different than what is already proposed--sending a single vlan
with a list of all the attached vlans. Hence my original post--there's
no point in doing something that doesn't solve the problem it's supposed
to address.

Or is it important how well is scales while it's failing? :-)

:-)

Russ

- --

---

From: "Anoop Ghanwani" <[email-masked]>
Date: Thu, 6 Dec 2007 19:06:08 -0800

Anoop 

> Sent: Thursday, December 06, 2007 10:00 PM
> To: Anoop Ghanwani
> Cc: Eric Gray; Radia Perlman; Developing a hybrid router/bridge.
> > It is possible to misconfigure bridged LANs so that VLANs end up 
> > getting partitioned.
> > The automated way to avoid that is using MVRP.
> 
> iD8DBQFHWLc4ER27sUhU9OQRAlF5AJ9KY9cL3vI3ARQNKLRTZNOauSbrwQCfXhjx
> LoSy2T6UAKwoxpnJtTHIDro=
> =EqjY

---

From: "Anoop Ghanwani" <[email-masked]>
Date: Thu, 6 Dec 2007 19:11:58 -0800

Well, if the Bridged VLAN just did MVRP, we wouldn't
have any of these problems with partitioned VLANs.
(Even without any RBridge participation.)

Anoop 

> Sent: Thursday, December 06, 2007 10:08 PM
> To: Anoop Ghanwani
> > I think the consensus at the last meeting was that RBridges 
> MAY choose 
> > to participate in MVRP.
> 
> Does that mean they MUST "work around" MVRP on the links 
> between the rbridges? OR does it mean they may support MVRP 
> like functionality edge-to-edge? What does "participate" 
> mean, precisely?
> 
> :-)
> 
> Russ
> 
> - --
> iD8DBQFHWLj5ER27sUhU9OQRAsL/AJ96V7Y/V6c++7NUnt2MZJjAHbUIXQCg5j2V
> p9bUf8++WgztyaXeKVdo8S4=
> =KLib

---

From: "Anoop Ghanwani" <[email-masked]>
Date: Thu, 6 Dec 2007 19:29:35 -0800

> Sent: Thursday, December 06, 2007 10:20 PM
> To: Anoop Ghanwani
> > But the level of participation that I envisage is that of 
> end station.
> 
> Why?
> 
> We should *never* assume an underlying media of any type. It 
> will tie the spec into a corner, and make it impossible to 
> use in other situations.

This I do not get at all.  I need more explanation
with an example that does not work.

Anoop

---

From: "Anoop Ghanwani" <[email-masked]>
Date: Thu, 6 Dec 2007 19:08:55 -0800

> Sent: Thursday, December 06, 2007 10:03 PM
> To: Anoop Ghanwani
> > This is the case...RB1 and RB2 are connected to the core on the top 
> > and at the bottom they are supposedly edge ports.  However, these 
> > accidentally get connected.  What we have is loop and multicast 
> > traffic which gets sent into the core by both RB1 and RB2.
> 
> Two things:
> 
> 1. There are other ways to resolve this. uRPF would probably 
> would, in fact. Or, perhaps, sending out hellos marked so 
> they don't form an adjacency in IS-IS. I should point out 
> that modern bridges don't seem to have a problem with the 
> bpdu transmissions in this situation, so I don't see why they 
> would have a problem with IS-IS hellos.

> 2. We seem to tolerate this misconfiguration problem in 
> modern day switches all the time, and everyone just seems to 
> live with it.
> 
> I'm waiting for an example where you'd have 4000 VLANs 
> connected between two rbridges which are intended to transit traffic.

Anoop

---

From: "Anoop Ghanwani" <[email-masked]>
Date: Thu, 6 Dec 2007 19:10:29 -0800

> Sent: Thursday, December 06, 2007 10:06 PM
> To: Anoop Ghanwani
> > The point is most bridges don't have scaling issues like that.  If 
> > we're going to build a technology that costs as much as routers and 
> > has the same (if not even worse scaling properties), why 
> would people 
> > want to deploy it?
> 
> I would argue that most bridges do have scaling issues like 
> that, first of all. 

Please be specific.  I can't think of any such
example.

> Second, I would argue that rbridges, 
> built properly, and deployed properly, won't have worse 
> scaling properties. Finally, I'd point out that rbridges 
> might not replace STP bridges, but rather augment them in 
> some specific places, etc.
> 
> In general, I consider this line of reasoning a red herring. 
> We need to focus on realistic situations, and find solutions 
> which don't incur large new pieces of complexity for very 
> small gains. I would also point out that if you're counting 
> on this "elect a single DRB on a segment"
> idea to prevent problems in the case you're using as an 
> example--it won't in any case. I've already shown two cases 
> where it fails, and can easily find at least one more. Those 
> cases apply to your examples, as well.

I'm just starting to respond to those.

Anoop

---

From: Russ White <[email-masked]>
Date: Thu, 06 Dec 2007 22:41:41 -0500

> with an example that does not work.

I would think it should be clear.

Rbridges should care about getting good connectivity between the
rbridges, not fixing bad connectivity for this media type or the other
because they might happen to be the media type used to connect the
rbridges. Should we also be specifying the way an rbridge interoperates
with an ADM if there happens to be one in the middle? Or perhaps a
satellite link?

The connectivity between the rbridges should be assumed, and we should
worry about how to emulate a bridged network over that connectivity. All
this stuff trying to figure out how to make it work over a specific
media in a specific situation should be put in another doc, if it's
discussed at all, and not in the base specification.

:-)

Russ

- --

---

From: "Anoop Ghanwani" <[email-masked]>
Date: Thu, 6 Dec 2007 19:28:45 -0800

> Sent: Thursday, December 06, 2007 10:17 PM
> To: Anoop Ghanwani
> > Because they don't have to send 4000 BDPUs if they have 4000 VLANs 
> > configured on that port.
> 
> Then, again, this suggests a solution that doesn't require 
> the complexity you're talking about. A simple IS-IS hello 
> with a marker

> RBridge core 
> > but they are each connected to bridged LANs configured with 
> 4K VLANs.
> 
> And why are you connecting them this way? To provide 
> resilience to a set of servers? Then there are other 
> solutions. To provide 4000 transit links for better 
> throughput? Then you need a new network.

That is your opinion vs mine about how to build
the network.  People don't always do what we tell them.
Which is why we're even having this discussion.
Otherwise, use correct configuration per recommendation
and we'd have none of the problems.

Anoop

---

From: "Anoop Ghanwani" <[email-masked]>
Date: Thu, 6 Dec 2007 19:43:07 -0800

> Sent: Thursday, December 06, 2007 10:37 PM
> To: Anoop Ghanwani
> > Probably not...if the VLAN number selected for that hello 
> happens to 
> > be the one that has no connectivity on that link, then 
> hello doesn't 
> > make it through but the problem remains on all the other VLANs.
> 
> That's no different than what is already proposed--sending a 
> single vlan with a list of all the attached vlans. Hence my 
> original post--there's no point in doing something that 
> doesn't solve the problem it's supposed to address.
> 

No.  In this case the failure is a catastrophic
one.  In the case where the single VLAN hello failed
the failure was not catastrophic.  The problem is
detected and one of the RBs disables forwarding
from that LAN.

Anoop

---

From: "Anoop Ghanwani" <[email-masked]>
Date: Thu, 6 Dec 2007 19:46:30 -0800

> Sent: Thursday, December 06, 2007 10:42 PM
> To: Anoop Ghanwani
> > This I do not get at all.  I need more explanation with an example 
> > that does not work.
> 
> Rbridges should care about getting good connectivity between 
> the rbridges, not fixing bad connectivity for this media type 
> or the other because they might happen to be the media type 
> used to connect the rbridges. Should we also be specifying 
> the way an rbridge interoperates with an ADM if there happens 
> to be one in the middle? Or perhaps a satellite link?
> 
> The connectivity between the rbridges should be assumed, and 
> we should worry about how to emulate a bridged network over 
> that connectivity. All this stuff trying to figure out how to 
> make it work over a specific media in a specific situation 
> should be put in another doc, if it's discussed at all, and 
> not in the base specification.

If the world were really that simple we'd be done by
now.  Reality of it is we have to worry about what's
going on in the underlying media.  For every interface
type that you can run a router on, we have a corresponding
RFC that says what specific things need to be done for
that interface type.   When we get to other RBridge
interface types, we'll have to deal with similar issues.

Anoop

---

From: Russ White <[email-masked]>
Date: Fri, 07 Dec 2007 07:18:01 -0500

> now.  

You mean we'd have a finished spec people could start implementing? I
don't consider that a bad thing.

> Reality of it is we have to worry about what's

Then I would suggest the rbridge WG catalogue a list of all possible
failure modes in 802.1, and address each one. There are many more other
than this specific instance of misconfiguration--I'm not certain why
this one was singled out for correction.

The reality is you don't try to correct misconfigurations in lower
layers when you're writing a protocol to run on top of them. You assume
the lower layer is configured correctly, work around places where the
lower layer protocol doesn't really support you, but you don't try to
guess how that lower layer might break, and try to work around every
possible case.

:-)

Russ

- --

---

From: Radia Perlman <[email-masked]>
Date: Fri, 07 Dec 2007 09:18:46 -0800

Not trying to "fix" the failure mode is exactly what the current thing 
is doing: it favors simplicity and scaling, and not
trying to heal partitions within a cloud, but instead making sure that 
if there is a partition, it won't cause loops.

Radia

Russ White wrote:
> iD4DBQFHWTn5ER27sUhU9OQRArssAKCHCl7t0NMc7sOUVHhj0zwo22AFMACYkDgA
> ogzxbM5cHYvsYCtUay2QLA==
> =KlVU

---

From: Russ White <[email-masked]>
Date: Fri, 07 Dec 2007 12:44:15 -0500

> if there is a partition, it won't cause loops.

Loops on the edge ports are a problem--I'm cogitating on a set of
solutions for that which don't require the complexity involved in the
proposed solution. IMHO, the specification should be flexible here, and
allow tradeoffs.

I'm not getting where a loop can form due to a link failure in the
underlying transport between rbridges. Could someone provide an example?

:-)

Russ

- --

---

From: "Eric Gray" <[email-masked]>
Date: Mon, 10 Dec 2007 08:42:08 -0600

By the way, there is definitely something wrong with the mailing
list.  The mail below was not received until 12 hours after it 
was sent.  This is particularly annoying since I was getting ready
to pack for my return trip when I sent it, but I was in an airplane
at probably about 30,000 feet when people started receiving it.

Is it possible to determine what is causing the posting delay?

--
Eric Gray
Principal Engineer
Ericsson  

> [mailto:[email-masked]] On Behalf Of Eric Gray
> Sent: Thursday, December 06, 2007 9:53 PM
> a single

---

From: Joe Touch <[email-masked]>
Date: Mon, 10 Dec 2007 07:14:17 -0800

The system that handles this list processes email on a periodic basis.
Posts can be delayed up to 15 minutes. This is not uncommon for large
mail list servers - it avoids process thrashing for individual posts.

If anyone else has seen substantial delays, please let me know and I'll
look into it.

This message, FWIW, was posted at 07:14am PST; let's see when it shows up.

Joe (list admin)

---

From: "Eastlake III Donald-LDE008" <[email-masked]>
Date: Mon, 10 Dec 2007 22:57:56 -0500

The incremental deployment requirement means that the links between
Rbridges could be arbitrarily complex bridged LANs including hubs and
repeaters. A physical link or hub or repeater or bridge coming up or
failing within such a bridge LAN could variously increase or decrease or
partition or unite the sets of Rbridges interconnected by such a bridged
LAN, in some cases due to spanning tree reconfiguration.

(I must also say that I think the word "media" has mostly to do with
link physics in my mind. Whether a link can be a bridged LAN or not is,
in my opinion, a wholly different type of question from whether it is
any particular type of "media" such as wired or optical 802.3, 802.11,
802.16, etc., etc. I don't think anything in the current TRILL spec
depends on what type of physical media your are using, it only requires
that it be "802.1 conformant". How to handle bridges and whether they
are allowed is pretty independent of which or what combination of the
above "media" types you have.)

Thanks,
Donald

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Russ White
Sent: Friday, December 07, 2007 12:44 PM
To: Radia Perlman
Cc: Developing a hybrid router/bridge.
Subject: Re: [rbridge] Orphaned endnodes with partitioned VLANs on a
cloud

:-)

Russ

- --

---

From: "Eric Gray" <[email-masked]>
Date: Tue, 11 Dec 2007 14:09:49 -0600

Donald,

	See some amplifcations below...

Thanks!

--
Eric Gray
Principal Engineer
Ericsson  

> [mailto:[email-masked]] On Behalf Of Eastlake III 
> Donald-LDE008
> Sent: Monday, December 10, 2007 10:58 PM
> To: Developing a hybrid router/bridge.
> failing within such a bridge LAN could variously increase or decrease 
> or partition or unite the sets of Rbridges interconnected by such a
> bridged LAN, in some cases due to spanning tree reconfiguration.

It is at least likely that some of these may occur as a result of IS-IS
RBridge peer discovery as well - hence the need to ensure that we define

things correctly (and - hence - the reason why I wanted to define all
such things within a single LAN/VLAN context) so that RBridges - and 
existing bridges - work correctly as they would in a comparably deployed
network of either all bridges or all RBridges.

Note the the "comparably deployed" is also very significant to the goal
of incremental deployment - since that allows the simplest transition
models (1 by 1 replacement).

> above "media" types you have.)

I think I agree, though I feel that I may be missing the context.  What
part of the thread below prompts this parenthetical observation?