Subject: [rbridge] Critical bits for options

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

I'd like to make sure the decision about whether to define critical bits 
for options is made with "informed consent" of the WG. I will write
this with no opinion -- just the tradeoffs.

Currently the TRILL spec says to ignore all options -- the only thing 
the spec says is how to skip the options, if any.

A "critical" option (some people call it "mandatory") is an option that 
if it appears and you don't understand it, you MUST drop
the packet. A noncritical option is one that you are allowed to ignore 
and skip over.

The way the spec is now precludes critical options, because RBridges 
following the current spec will skip all options.

An alternative is for TRILL to define two bits at the beginning of the 
options (these bits only appear if the options length is
greater than 0).

The two bits are:
a) a critical hop-by-hop option exists
b) a critical end-to-end option exists.

If we define these bits, then an egress RBridge MUST look to see if 
either of those bits are set, and if so, parse the options.
A transit RBridge MUST look to see if the hop-by-hop bit is set, and if 
so, MUST parse the hop-by-hop options.
Though I suppose an RBridge that doesn't support ANY critical options 
would know based on the presence of a critical
option that it should drop the packet, without having to parse to find 
the critical option.

So, our choices as a WG:

Choice A: Define NOW that the first 2 bits in the option portion, if the 
option length is nonzero are those two
critical bits. And that if you are forwarding an encapsulated data 
packet (i.e., you are acting as a transit RBridge
for this packet), and thost of choice first (hop-by-hop critical) bit is 
set, you MUST drop the packet. And if you are egress
RBridge, and either of the first two bits are set, you MUST drop the packet.

Choice B: Leave the spec as it is

The cost of choice A is a bit more complexity, and a bit more overhead 
of forwarding because of having the set the bit.
The cost of choice B is that we cannot ever define critical options.

The other arguments might be
. how likely is it that we'd ever need critical options? Can we imagine 
some examples that we'd ever really want/need?
. we could support such things by using a new version TRILL header when 
including critical options, so we are not
really precluding critical options.
. we could advertise (in LSPs for end-to-end critical options, in Hellos 
for hop-by-hop critical options), support for critical
options, and the previous hop RBridge can throw the packet away if 
there's no way to forward it without the critical option, so
we don't really need for the receiving RBridge to discard the packet.
. how bad would it be for an RBridge to ignore a critical option?

So...what do people think?

Radia

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

---

From: Joe Touch <[email-masked]>
Date: Tue, 04 Dec 2007 20:23:20 -0800

> either of those bits are set, and if so, parse the options.

I believe we're talking about a "summary" bit in each case. As a result,
the goal of these bits is to avoid parsing the options in detail.

There is benefit ONLY for hop-by-hop bits, i.e., to accelerate
forwarding. Egress rbridges would need to parse the entire header anyway.

That said, I'm not sure this is the right meaning for these bits. They
are useful as a summary ONLY if they indicate whether "CAN IGNORE" in
fast path rbridges.

Let's presume that's NOT what the bit means, i.e., the bit means there
is a critical option (as defined above). The rbridge still needs to
parse the entire option set to find out WHICH options are listed, and to
decide whether each is supported or not anyway.

> option that it should drop the packet, without having to parse to find 

That works ONLY for the case where an rbridge supports NO critical
options. If it supports any, then it needs to parse the entire header
anyway. Is that really worth this?

Joe

---

From: James Carlson <[email-masked]>
Date: Wed, 5 Dec 2007 09:14:23 -0500

> the spec says is how to skip the options, if any.

I think the part that's actually broken here is not the lack of some
summary bits for the option list, but the fact that we haven't defined
the basic option format.  We should do that, and not just leave it to
some "later documents."  *Then* we can say that transit RBridges must
obey the critical hop-by-hop options, and the egress RBridge must obey
all critical options.

(Where "obey" means "process if you understand, drop if you don't.")

Yes, that means that all option creators need to weigh carefully the
costs of creating a new option (in terms of slow-path expense in all
systems) versus the benefit the option claims to provide.  I think
that's a good thing, and the warning in section 3.5 makes it pretty
clear.

-- 
James Carlson, Solaris Networking              <[email-masked]>
Sun Microsystems / 35 Network Drive        71.232W   Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757   42.496N   Fax +1 781 442 1677
_______________________________________________
rbridge mailing list
[email-masked]
http://mailman.postel.org/mailman/listinfo/rbridge

---

From: Joe Touch <[email-masked]>
Date: Wed, 05 Dec 2007 09:24:56 -0800

A few lessons from IP (which we may or may not want to emulate):

--------------------------
V6 rules:

- hop-by-hop options MUST come before E2E ones

- unrecognized options have 4 variants indicated via flags:
	- silent pass (skip over silently)
	- silent discard
	- discard w/ICMP
	- discard w/ICMP iff source != multicast

- an additional per-option flag indicates:
	- immutable en-route
	- mutable en-route (i.e., ignore in Auth)

--------------------------
V4 rules:

- unrecognized options
	- silent pass

-------------------------

I'll note that IPv6 doesn't e have a summary bit about critical HBH
options. I don't see why we would anticipate being more complex than
IPv6 in this regard.

IMO, the IPv6 rules are probably sufficient to use as-is.

Joe

---

From: "Eastlake III Donald-LDE008" <[email-masked]>
Date: Wed, 5 Dec 2007 15:52:32 -0500

Hi Joe,

See comments below at @@@

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Joe Touch
Sent: Tuesday, December 04, 2007 11:23 PM
To: Radia Perlman
Cc: [email-masked]
Subject: Re: [rbridge] Critical bits for options

@@@ Yes, "summary" is a reasonable description of these bits. And, if
one is trying to postpone defining the structure of options in detail,
as the current protocol draft does, making it possible to avoid parsing
them seems like a good idea :-)

There is benefit ONLY for hop-by-hop bits, i.e., to accelerate
forwarding. Egress rbridges would need to parse the entire header
anyway.

@@@ If by "parse the entire header" you mean look at each option
individually, I disagree. If all options present are non-critical, the
egress Rbridge, like all Rbridges, need not look at any of them.

@@@ If by "parse the entire header" you mean examine stuff beyond the
TRILL Header, the egress Rbridge has to do that to decapsulate but
transit Rbridges have to do this also. While there are lots of other
reasons to look beyond the TRILL header for various cases of
multi-destination tree pruning, the most general reason is to get the
frame priority from the inner VLAN tag. This is necessary even for known
unicast frames for robustness since the outer VLAN tag may have been
stripped. However, skipping over the options without parsing them is
easy since their length is given and, if you know there were no critical
options present, safe. 

@@@ Well, I expect that many Rbridges will, for a long time, not
implement any options, so they clearly wouldn't need to parse them if
these summary bits were available. Even with Rbridges that do support
some options, I would expect the more detailed TRILL option feature
specification to require that all hop-by-hop options to precede all
end-to-end options (and perhaps, within those categories, to have
critical options precede non-critical options) so a transit Rbridge
could stop parsing as soon as it hits an end-to-end option. You could
also add a summary bit for the existence of non-critical hop-by-hop
options so a transit Rbridge would know if all the options present are
end-to-end.

@@@ Transit Rbridges that support no hop-by-hop options, critical or
non-critical, are expected to be very common.

@@@ It is also good to keep in mind that, at least for unicast, these
summary bits are probably just a safety measure. That's because I would
expect that Rbridges will be required to announce in their LSP what
options they support (at least for critical options and probably for
all). Thus, by imposing requirements on the sender, you could claim that
no unicast frame with a critical option should ever be sent to an
Rbridge that does not support it. However, in the real world, errors of
all types happen. If, say, a transit Rbridge that supported no options
did receive a frame with a critical hop-by-hop option in it and you did
not have these summary bits (or they were set wrong), it will screw up.
But there is no way in the real world to guarantee that something like
that could never happen.

@@@ An argument in favor of the bits is that you might have a case where
you are forwarding a multi-destination frame down a distribution tree
from Rbridge Z and out one port there are three downstream Rbridges one
hop away, A, B, and C, where the frame has a critical option that you
know from the link state database is supported by A and B but not C. It
might be nice, for some options, to be able to just multicast the frame
knowing that C will just discard it. This would be a decision by RBridge
Z (which must understand the option or it would not have created or
successfully received the frame).

Joe

@@@ Thanks,
@@@ Donald

---

From: Joe Touch <[email-masked]>
Date: Wed, 05 Dec 2007 23:45:19 -0800

> See comments below at @@@
...
> individually,

Yes.

> I disagree. If all options present are non-critical, the

Optional non-critical options?

Here's the issue: let's say you have a hop option that IS implemented at
the internal hops, but is NOT critical. Which hops would ever see them?
If nobody looks at them, why bother putting them in?

IMO, every internal hop must examine all hop options, and an egress must
examine all end options - that's the only way for either to know which
ones they implement that they CAN handle. The only short-cut here is
that internal hops could skip examining options if there were no hop
options.

> easy since their length is given and, if you know there were no critical

Yes, safe, but again what's the point of putting things in that nodes
can ignore even if they implement? If the node doesn't examine the
options, how does it know it does or does not support them?

> these summary bits were available.

The bits are relevant only to rbridges that don't implement the options
used. As you point out, that is useful for rbridges that implement NO
options.

An rbridge that implements ANY options would then need to examine them
ALL to see which ones to handle.

> Even with Rbridges that do support

You don't need that bit - you get that info from examining the first
option (if it's not HBH, then there are no HBH options!).

> non-critical, are expected to be very common.

Sure - for nodes that support NO options, these flags might be useful. B

> successfully received the frame).

Overall, I'd like to see a case for using these bits. You've made the
case for IPv6 rules - ordering the options, and there clearly also needs
to be IPv6-like flags inside the options.

If the only reason for the summary flag is for transit rbridges
implementing NO options, that's an extraordinarily specific corner case,
IMO, for such a flag.

The flag isn't particularly useful at the egress, IMO.

Joe

---

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

v6 rules are more complicated than we need, aren't they ? All we need is 
the ability for an Rbridge to say, "I don't support any options, but 
this frame has options which I understand are fine to ignore and so I'll 
process the frame in fast path AND not delete the options from the 
outgoing frame". This allows us to define options that can pass through 
transit Rbridges. If we don't do this, I'd say that options would in 
"dead in the water", pretty much like IP options.

Dinesh
Joe Touch wrote:
> ------------------------------------------------------------------------
>

-- 
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: Joe Touch <[email-masked]>
Date: Thu, 06 Dec 2007 10:30:47 -0800

Dinesh G Dutt wrote:
> outgoing frame". 

If there are two variants:
	- NO options implemented
	- some options implemented

AND we're trying to optimize the no-options case, then yes, a single bit
would be useful. I am concerned that "no options" is a corner case; it's
more likely that over time there will be some options in most devices.

If that's the case, then a single bit doesn't help.

> This allows us to define options that can pass through

If we need to optimize for the 'no critical options' case, then ALL
critical options are dead in the water, by the above logic...

Joe

---

From: "Eastlake III Donald-LDE008" <[email-masked]>
Date: Thu, 6 Dec 2007 14:17:19 -0500

Hi James,

See below at @@@

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of James Carlson
Sent: Wednesday, December 05, 2007 9:14 AM
To: Radia Perlman
Cc: [email-masked]
Subject: Re: [rbridge] Critical bits for options

@@@ There is clearly a spectrum of possibilities for the details in the
"base protocol" specification. The current document is pretty much at
one extreme, having just a size field and saying nothing about the
content of the options area.

@@@ Adding a specification of a few summary bits at the start of the
options area if the options length is non-zero would be the next step.
While I personally favor this, I used to think it didn't make much
difference because you would be able to tell what options an Rbridge
supports by looking in the link state database and not send an Rbridge
any options it does not support. But that only works well for unicast.
Because of multi-destination frames (broadcast, unknown unicast, and
non-IP-derived multicast) I'm even more convinced that it would be
useful to specify these summary bits now.

@@@ The next stage after summary bits would be to specify the format,
ordering, etc., of options, which is what you are suggesting.
Unfortunately, I think that could be fairly controversial. Furthermore,
I believe that the design of the options format would be greatly
improved by designing a number of specific options at the same time.
Some such options, like a data frame security option, might be fairly
complex. Furthermore, I believe there are multiple efforts working
towards high speed Rbridges that implement no options and which would
benefit from progressing the specification to the stability of an RFC.

@@@ All in all, I think that trying to put the detailed option format in
the specification could delay things by 6 months. A separate document
seems to me like the way to go. 

@@@ Thanks,
@@@ Donald

---

From: Dinesh G Dutt <[email-masked]>
Date: Thu, 06 Dec 2007 11:03:38 -0800

You're saying that if we make options support possible in the fast path, 
most likely over time there will be more devices that support some 
options but not others, so a single bit doesn't suffice because the 
device that supports some options cannot decide if a specific option is 
critical or not. So you're saying if we define within  the options two 
additional containers, hop-by-hop and e2e,  and state that one comes 
before the other, we're in a better shape.

I agree with your logic.

I'm still not sure whether we need all the logic of IPv6 options such as 
stating whether an option may change HbH and we can probably use a 
single bit to decide whether we can skip over the option or discard the 
frame; we can ignore the ICMP options piece.

Dinesh

---

From: James Carlson <[email-masked]>
Date: Thu, 6 Dec 2007 14:20:15 -0500

> "dead in the water", pretty much like IP options.

I don't understand that quoted section.  Why would we define options
that "everybody" is going to ignore?  What would be the point in
having always-ignored options?

If an implementation actually has support for a given option, then I
would expect it to be obligated[1] to process that option, and it
should not just "ignore" it.  Ignoring is equivalent to _not_
implementing.

I think the only question is whether a node receiving a TRILL frame
can determine if there are options that it must process.  The rules
sound to me like:

	- If you're a transit node, then process all options up to
          either the end of the list or the first end-to-end option,
          if any.

	- If you're an end node, then process all the options.

We can "special case" the critical options by tweaking the order, if
necessary.  Just make the order:

   1. Critical hop-by-hop
   2. Non-critical hop-by-hop
   3. Critical end-to-end
   4. Non-critical end-to-end

Then, if there are implementations that don't implement any options
and if those implementations need to "optimize" the discard/pass
action (!), they can simply look to see if the first option on the
list is critical, and bail if so, and pass otherwise.  (Decapsulating
end nodes would have to span over non-critical hop-by-hop options, but
that seems like a small price.)

[1] Choosing my words carefully here -- "obligated" in moral sense,
    rather than "required" in an RFC 2119 sense.

---

From: James Carlson <[email-masked]>
Date: Thu, 6 Dec 2007 14:39:44 -0500

> See below at @@@

Oh, how I wish the quoting styles were common ...

> content of the options area.

Indeed.  The problem that causes is that you can't really have a
meaningful conversation about when to drop or pass based on options,
as there's currently no understanding of what's *in* the options.

> options area if the options length is non-zero would be the next step.

I don't agree.  That's a *possible* next step, but not *the* next
step.  The assumption you're making is that summary bits are either
useful or necessary, and until we have some clue about the semantics
we want, we don't know that.

So, for example, it's possible to arrange the options such that a
transit node that implements _no_ options at all can determine whether
to pass or drop a frame based on the flags on the first option alone.
In that case, there's really very little reason to define "summary
bits" because all we're doing is very slightly and trivially
optimizing that one special edge case -- while at the same time adding
another point where things can be broken.

What happens if the summary bits disagree with the options contained?
Obviously, the system fails, but the point is that duplicating data --
bits from the options into bits in the header -- *always* causes a
risk of data synchronization errors.  Consider for example a node that
must remove options because of the way the options work or because of
local configuration that dictates how optioned-packets are forwarded.
What will it do?  There's a good risk here that the summary bits will
become wrong, as they need to be recalculated during changes.

> useful to specify these summary bits now.

I think we need a solid framework for options first, and *then* decide
whether it's worthwhile to add extra flags to optimize corner cases.

The summary bits aren't primary functionality.  They're secondary.
They're derived from the information in the options themselves.  As
such, they're expendable and merely performance hacks.  The life of a
performance hack depends pretty strongly on the performance case for
it, and I haven't seen that argument made yet.

> Unfortunately, I think that could be fairly controversial.

It might be controversial, but what we have right now is a #include in
the specification that names a non-existent file.  We can pretend
that's not a problem by papering around it, but it's going to bite us
eventually.

> Furthermore,
> complex.

Agreed; having some idea of what might be in options would help, but
it's also true (as others have pointed out) that we can borrow ideas
from other successful option mechanisms.

Having critical/non-critical and hop-by-hop/end-to-end seems like a
sufficient diversity -- but simple specification -- that we can layer
other mechanisms on top later.

> Furthermore, I believe there are multiple efforts working

I don't see that as a serious issue.  What's stopping people from
building implementations before there's an RFC?  What makes them think
that there won't be changes _after_ there's an RFC?  This isn't an
IEEE spec.

I agree that all implementations will benefit from getting this right.
I think they'll benefit more if we define it correctly, so that it
doesn't cause more trouble down the road.

> seems to me like the way to go. 

Six months seems unlikely to me ... but even if it is that long, I'd
rather have a more robust document than a "quick" one that (years from
now) has vestigial bits relating to performance hacks for obscure
implementations that've been long forgotten.  Protocols are forever,
hardware is not.

---

From: Russ White <[email-masked]>
Date: Thu, 06 Dec 2007 16:05:39 -0500

I'm going to try a little summary here, just to see if I'm getting
this.... :-) I'll include some questions to things I really don't know
(?)....

1. For each packet processed, there will be some set of options
contained within the header.

2. Some platforms might be able to switch some or no options in a faster
switching path (hardware, for instance).

3. There are some options which must be switched because they are
hop-by-hop, no matter what they do to the switching speed.

So, the problem is--how do you signal, without looking for the options,
whether or not the faster switching path the packet comes in on should
punt the packet to some slower path because of the presence of some
option or another.

Now, if this is all correct, the questions:

1. What are these options for? I'm a bit confused as to why there are
such things as options (?)....

2. Will there be a consistent list, through time, of which options a
given platform will switch in some faster path, and which they will
switch in some slower path?

3. Will it be faster to sort through an option summary per option rather
than through the options themselves?

Trying to sort this out:

1. It seems like if 2 is false, then there's no point in trying to put
the options in any sort of order (?).... How can the sender know what
some processing node in the middle can switch faster or slower?

2. It also seems like if 2 is false, there's no point in trying to put
some sort of "I can be switched in the faster path," bit, because we
don't really know what's switchable in the "faster path." I'm uncertain
on this one, so please straighten me out if I'm wrong. :-)

3. If 3 is no, then I'm not certain what we would gain by these things?

Overall, I think it might be useful to have a bit saying: "This packet
has options you really need to process, so don't just switch it without
paying attention." A bit that says: "I have no options" might also be
useful.

I'm not certain I understand the rest.

:-)

Russ

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

---

From: Radia Perlman <[email-masked]>
Date: Thu, 06 Dec 2007 14:39:56 -0800

I think the possibilities are
a) what's in the spec now: a way to skip over all options. This means we 
can't define a critical option, because current RBridges
will skip over it, and not realize that they are supposed to drop the 
packet because it has a "critical" option in it
b) define option format, including marking each option as critical or not
c) everything in b, but also have two summary bits "critical hop by hop 
option is in this packet" and "critical end to end option is in this packet"
d) just define the two bits "critical hop by hop" and "critical end to 
end" option exists.
The issues in each
a) we won't be able to define an option that is "critical" without using 
a new version of the TRILL header (which is actually a plausible
work-around), because current RBridges will just skip all options
b) Might slow the WG down, but maybe the format won't be controversial. 
If the two critical bits are not there, then it will slow down
RBridges that don't support any critical options, because they will have 
to parse through all the options.
c) the two summary bits are, as someone pointed out, redndant 
information if each option is marked as critical or not. However,
the summary bits do make forwarding faster for bridges that don't 
support any options, because they don't have to look through the
options
d) this is the minimal thing we'd need to do if we want to allow 
critical options

At this point I favor d), because it's really easy to specify, and then 
we don't have to argue about the format of options.
Don Eastlake actually had designed a format, and has verbiage for it, 
but I had perhaps bullied him into taking it out of the spec because
at the time I didn't think it was worthwhile defining the option formats 
if we weren't defining any options.

Radia

---

From: James Carlson <[email-masked]>
Date: Thu, 6 Dec 2007 17:27:57 -0500

> punt the packet to some slower path because of the presence of some

Yes.  In a particular degenerate case that appears to be of interest
to several posters here, systems that implement _no_ options at all
would like to know if any "critical" (must-comply) ones are present.
If they are, then the only thing the node can do is drop.

> such things as options (?)....

Good question.  Presumably, they'd be there to handle special
features, such as encryption in transit and labeling for security
purposes, and perhaps for debug options (trill-traceroute).  It's hard
to imagine too many _other_ purposes here, but I suppose others are
possible.

> switch in some slower path?

Almost certainly not.  The only assertion I've seen here is that some
implementations will be completely unable to support options at all.
They need to know whether to drop or pass a packet with options.

> some processing node in the middle can switch faster or slower?

There's a difference between critical and non-critical hop-by-hop
options.

If there are any critical options, then all nodes on the path must
process them.  Any nodes that don't understand the option must drop
the packet.  That's the reason some are requesting a "summary" bit.

One way to resolve the whole problem is to outlaw critical hop-by-hop
options.  Maybe not the _best_ way, though.

> paying attention." A bit that says: "I have no options" might also be

The latter we have -- Op-Length will be zero when there are no
options.

The former we can get in one of at least two ways:

  - Summary bits (some like this, I don't)

  - Option ordering such that must-parse options are always first.

---

From: James Carlson <[email-masked]>
Date: Thu, 6 Dec 2007 18:01:06 -0500

> I think the possibilities are
[a...d]

e) Specify that, although the option format is not yet defined, all
   options are assumed to be non-critical.  All implementations are
   expected to forward properly regardless of Op-Length.  This allows
   us to define the option format later in order to introduce
   non-critical options without disturbing any existing
   implementations that have no options.

   If we ever need critical options in the future, then we bump the V
   (version) field, and define the option format at the same time.
   This creates a flag day for the old implementations.  But if we're
   creating "critical" options that all implementations must have,
   then there's a darned good reason for it, and those old machines
   need to be upgraded or retired anyway.

I'd still prefer to see an option format spec, but the solution above
looks slightly better to me than adding summary flags, which I really
don't like.

---

From: "Eastlake III Donald-LDE008" <[email-masked]>
Date: Sat, 8 Dec 2007 17:52:58 -0500

See below at @@@

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of James Carlson
Sent: Thursday, December 06, 2007 5:28 PM
To: Russ White
Cc: [email-masked]
Subject: Re: [rbridge] Critical bits for options

@@@ My personal opinion is that high end wired networks are a bit over
represented in the TRILL WG and that community dislikes options and has
no plans to implement any. And a number of people have spoken out
against a security option on the grounds that its too computation
intensive at high data rates. Design decisions might have been quite
different if wireless transport was over represented. People from the
wireless community are worried about every byte over their restricted
paths and if they dominated the TRILL WG we might already have option
bits to reversibly delete the inner Q-tag, IPv4, and IPv6 Ethertypes,
etc., inside encapsulated frames like 802.16 (Wi-Max) has for the
outside of all frames. Furthermore, because for their equipment security
hardware assist that runs at line speed (actually air speed I suppose)
is almost always included, people from the wireless community think of
adding data encryption and authentication as free.

@@@ Anyway, I'm not trying to say anything against the high end wired
applications, which are clearly important, nor saying we should define
and include options for constituencies that don't seem to be showing up
in the TRILL WG right now. What I am saying is that we should have an
option feature for flexibility, which is why I have been pushing for at
least a minimal hook for options, and we should not be surprised if for
some time the most prominent applications of TRILL are for Rbridges that
support no options at all. I also hope that TRILL will spread to a wide
variety of networks types in the future and I think that spread is
likely to motivate the specification of some options.

@@@ Some specific options have been mentioned at the last several
meetings, including LIDs (port IDs), Flow Tags, Security, frame
optimizations, ... See, for example, the slide on options in my
presentation on the meeting materials page at
http://www3.ietf.org/proceedings/07dec/slides/trill-4.ppt. Furthermore,
an advantage of having an options feature is that we can add options
later that we can't think of right now.

@@@ +1

> some processing node in the middle can switch faster or slower?

@@@ There may also be security (i.e.,  canonicalization for
authentication) reasons to order options as well as the processing
efficiency reasons...

@@@ Keep in mind that there are critical options that can be reversed
without loss of information. Almost all optimization options are of this
type. You can just de-optimize the frame and remove the option. Since
you can tell what options an Rbridge supports from the link state
database, when the preceding Rbridge sees that the next hop does not
support such a reversible critical option, it can drop the frame or it
reverse the option and then forward the frame.

@@@ Right

@@@ I'll post some text I happen to have around.

@@@ I think you should have a canonical ordering anyway if you might be
defining a security option later. And if you are specifying an ordering,
it might as well be such as to make processing more efficient.

@@@ Thanks,
@@@ Donald

---

From: "Eric Gray" <[email-masked]>
Date: Mon, 10 Dec 2007 09:44:50 -0600

Radia, Donald, et al,

	The one thing I don't seem to be getting out of this
discussion is even the most general idea what the application
is (or applications are) for these 'options' we are talking
about - or even a vague idea when and where they may apply.

	I assume - because we're talking about HbH and E2E -
that we're talking about data frames.  Frankly the idea of
putting data frames in jeopardy because some implementation
downstream from the ingress doesn't understand (or chooses to
pretend not to understand) an option is an EXTREMELY powerful 
argument for NEVER using options - and certainly not any of
the 'critical options' that might provide an excuse to drop
an entire class of frames.  This is - in a very real way -
roughly the same as providing yet another discard eligibility
mechanism since any implementation could decide to discard a
frame containing a 'critical option' - and be justified in
doing so.  

	Also note that - particularly for data frames - the most
reasonable interpretation for 'discard' is 'silent discard' 
since returning an error for every dropped frame (or even on a
periodic basis while dropping frames) is going to be a problem
- especially if some subset of all implementations 'cleverly'
decides to increase their 'sensitivity' to 'critical options'
under congestion conditions (very likely, given that - under
congestion - it is very likely that implementations will not
be able to keep up with at least some processing of 'critical
options').

	If that is - in fact - a correct understanding of the 
intent, then we're wasting time even talking about it (given 
the unlikelihood of there ever being a use for such a thing).
So that makes me ask: who dreamed this nightmare up and why?

	On the other hand, at least one person seems to interpret
this 'critical  option' indicator as 'must be processed' - which
includes 'process on the slow path' if you don't support doing
so on the fast path.  The distinction - again particularly for
data frames - is minor, given that it will not take long to 
over-whelm the slow path with data frames if we start seeing a
lot of 'critical options' and it will then be the case that the
implementations not capable of fast path processing of 'critical
options' will have no choice but to discard them.

	However, this latter case makes some sense if there is an
application for 'critical options' that either never, or very
rarely - results in using 'critical options' - but only 'some
sense', given the possibility that we're relying on a behavior
that probably cannot be reliably/deterministically predicted.

	So, my apologies if I am the only one that doesn't know
the answer to this question - but - what is the point of this
discussion (i.e. why do we need options and why 'critical' vs.
'non-critical' or HbH vs. E2E)?

	Based on the discussion so far (and as I have understood
it), I cannot make an informed decision.  All sorts of issues 
come to mind in the absence of knowing why we need this...

--
Eric Gray
Principal Engineer
Ericsson  

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Radia Perlman
> Sent: Tuesday, December 04, 2007 10:03 PM
> To: [email-masked]
> Subject: [rbridge] Critical bits for options
>

---

From: "Drake, John E" <[email-masked]>
Date: Mon, 10 Dec 2007 15:01:56 -0800

Eric,

I think this is a great e-mail.  Piggybacking control plane functions,
especially critical ones, on data frames seems ill-advised for the
health and well being of both the control plane and the data plane.

Thanks,

John 

>From: Eric Gray [mailto:[email-masked]] 
>Sent: Monday, December 10, 2007 7:45 AM
>To: Radia Perlman; Eastlake III Donald-LDE008; [email-masked]
>the 'critical options' that might provide an excuse to drop an 
>entire class of frames.  This is - in a very real way - 
>frame containing a 'critical option' - and be justified in doing so.  
>
>	Also note that - particularly for data frames - the 
>most reasonable interpretation for 'discard' is 'silent discard' 
>	On the other hand, at least one person seems to 
>interpret this 'critical  option' indicator as 'must be 
>processed' - which includes 'process on the slow path' if you 
>don't support doing so on the fast path.  The distinction - 
>again particularly for data frames - is minor, given that it 
>will not take long to over-whelm the slow path with data 
>frames if we start seeing a lot of 'critical options' and it 
>will then be the case that the implementations not capable of 
>fast path processing of 'critical options' will have no choice 
>but to discard them.
>
>	However, this latter case makes some sense if there is 
>an application for 'critical options' that either never, or 
>very rarely - results in using 'critical options' - but only 
>'some sense', given the possibility that we're relying on a 
>behavior that probably cannot be reliably/deterministically predicted.
>
>	Based on the discussion so far (and as I have 
>understood it), I cannot make an informed decision.  All sorts 
>of issues come to mind in the absence of knowing why we need this...
>
>--
>Eric Gray
>Principal Engineer
>Ericsson  
>
>> I'd like to make sure the decision about whether to define critical 
>> bits for options is made with "informed consent" of the WG. I will 
>> write this with no opinion -- just the tradeoffs.
>> 
>> A "critical" option (some people call it "mandatory") is an option 
>> that if it appears and you don't understand it, you MUST drop the 
>> packet. A noncritical option is one that you are allowed to 
>ignore and 
>> skip over.
>> 
>greater than 
>> 0).
>> A transit RBridge MUST look to see if the hop-by-hop bit is set, and 
>> if so, MUST parse the hop-by-hop options.
>> would know based on the presence of a critical option that it should 
>> drop the packet, without having to parse to find the critical option.
>> 
>> So, our choices as a WG:
>> 
>> Choice A: Define NOW that the first 2 bits in the option portion, if 
>> the option length is nonzero are those two critical bits. 
>And that if 
>> you are forwarding an encapsulated data packet (i.e., you are acting 
>> as a transit RBridge for this packet), and thost of choice first 
>> (hop-by-hop
>> critical) bit is
>> set, you MUST drop the packet. And if you are egress RBridge, and 
>> either of the first two bits are set, you MUST drop the packet.
>> 
>> . how likely is it that we'd ever need critical options? Can we 
>> imagine some examples that we'd ever really want/need?
>> . we could support such things by using a new version TRILL header 
>> when including critical options, so we are not really precluding 
>> critical options.
>> . we could advertise (in LSPs for end-to-end critical options, in 
>> Hellos for hop-by-hop critical options), support for 
>critical options, 
>> and the previous hop RBridge can throw the packet away if there's no 
>> way to forward it without the critical option, so we don't 
>really need 
>> for the receiving RBridge to discard the packet.

---

From: "Eastlake III Donald-LDE008" <[email-masked]>
Date: Tue, 11 Dec 2007 16:26:51 -0500

Hi John,

Can you point to a specific option that has been suggested which is a
control plane function? I don't think any of them are. Let me describe
two and tell me what you think.

(In this message, I'm not arguing for or against these options or giving
much detail but just trying to give a sketch to see if you think these
are control plane functions.)

Port ID (also called Local ID or LID): The idea is to avoid the MAC
address to port look up at an Egress Rbridge for unicast traffic. It
works by supplementing the source and destination MAC with a source and
destination LID. LIDs are probably 16-bits and would be learned the same
way MAC addresses and egress Rbridge are learned, by default from data
frame observation. There would probably have to be a distinguished LID
value which means unknown but otherwise LIDs are a local matter
presumably chosen so that the LID to port mapping is trivial.
	Obviously an Rbridge that didn't support the option wouldn't
send it and would ignore it on receipt. Since support would be indicated
in the link state database, an Rbridge that supported it might still
choose not to include it in a frame to an egress Rbridge that will
ignore it. For unknown unicast, you might want to include it or not or
maybe it's configurable but this and other considerations would be part
of the more detailed design. This option is probably not useful for
control (TRILL IS-IS) frames.

Security: The idea would be to leverage any IS-IS security keying so as
to authenticate or authenticate and encrypt data frames. This would
probably require hardware assist to be practical. While you could put
such an option in a control frame, it's probably better to use the IS-IS
security features directly. A security option could be used either
hop-by-hop or ingress-to-egress but ItE probably makes more sense. But
maybe there are some high security applications where you want both or
cases where a particular physical link goes through an area subject to
less physical control and security, where it would be worth getting
Rbridges with security assist hardware in their ports just for that one
hop or the like.

Do you consider the above options to be control plane functions that are
inappropriate to include in a data frame?

Thanks,
Donald 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Drake, John E
Sent: Monday, December 10, 2007 6:02 PM
To: [email-masked]
Subject: Re: [rbridge] Critical bits for options

Eric,

Thanks,
John

---

From: "Eastlake III Donald-LDE008" <[email-masked]>
Date: Wed, 12 Dec 2007 00:28:41 -0500

Warning: This message has had one or more attachments removed
Warning: (Drafts.xnk).
Warning: Please read the "ISI-4-43-8-Attachment-Warning.txt" attachment(s) for more information.

Hi Eric,

See below at @@@

-----Original Message-----
From: Eric Gray [mailto:[email-masked]] 
Sent: Monday, December 10, 2007 10:45 AM
To: Radia Perlman; Eastlake III Donald-LDE008; [email-masked]
Subject: RE: [rbridge] Critical bits for options

Radia, Donald, et al,

@@@ Many options have been presented or discussed and described at many
TRILL WG meetings and those presentation are in the IETF proceedings for
those meetings. Suggestions have included port ID (LID), flow ID,
security, Customer ID, and various optimizations. See also descriptions
of two of these in my previous message to John Drake.

@@@ In any case, I think one of the largest benefits of an options
feature is the ability to add options later that you can't think of to
start with.

@@@ We are talking about boxes that are all in the same broadcast domain
and are quite often subject to coordinated management. In any case, if
the boxes are fighting with each other, than can throw away data
whenever they want regardless of whether any option feature or options
are defined or used.

@@@ Since the options are in the TRILL header, they could be added to
any frame. Whether a particular option would make sense for data and/or
control (TRILL IS-IS) frames depends on the option. Seems like adding a
non-critical option to a frame would be more likely put it "in jeopardy"
if some down stream Rbridges can't figure out what the situation is in
terms of criticality, etc., which is why you want to specify a little
more now.

@@@ People keep telling me that in the high end wired switch market,
which is well represented in the TRILL WG, people build things to run
the worst case that's still on the fast path at line speed so, for
example, it is rarely useful to add an optimization unless it also helps
the worst case. A similar consensus is why we dropped any encoding into
the TRILL header of what tree pruning should be used for a frame but
instead are currently forcing every Rbridge including transit RBridges,
if they wish to do such pruning, to do the frame examination. I think
such people would say that your concept of an Rbridge increasing its
"sensitivity" to a critical frame because it was "congested" is bizarre
and would never happen in anything they plan to build. I think they
would also tell you that they don't plan to implement any options but if
they did implement one that might commonly appear in frames, their
bridges would be able to process it in the fast path for reasonable
cases. I would expect the support of an option by an Rbridge to be
reported in the link state database and be extremely stable, baring
firmware updates or the like.

@@@ I did and I'm proud of it. There are a number of options whose
inclusion, in my opinion, would not be a nightmare but would rather be
sweetness and light. The inclusion of an options feature substantially
improves the TRILL protocol. And, as I recall, there is a formal WG
consensus determination specifying the TRILL header with Option Length
field. We are just discussing details of options and which of those
details to include in the protocol specification now.

@@@ Are you saying that no protocol should have extensions or options?
Seems to me that many of the most successful protocols do. See the
presentation at the Thursday evening Plenary at IETF 70 which finds a
correlation between flexibility and protocol success:
http://www3.ietf.org/proceedings/07dec/slides/plenaryt-1.pdf. And it
seems to rarely if ever be the case that a simple linear sequence of
versions is adequate. (I think we also have a number of other success
factors listed in that presentation.)

@@@ It's silly to think that adding an option to a frame would magically
cause all downstream Rbridges to implement that option. But I would
agree that if an Rbridge advertises in the link state database that it
supports an option, then it should do so.

...

@@@ "need" is a funny word but yes, I believe that at some point in the
future we will find that we "need" to add an option. As to why having an
option feature is "desirable", which I think is a more reasonable
criteria, see the presentation whose URL appears above, some of the
TRILL presentations in recent IETF proceedings, etc.

@@@ As to why its useful to distinguish HbH and ItE options and critical
vs. non-critical options: If you marshal your options in a rational way,
the more you can classify as ItE, the fewer might have to be looked at
by a transit Rbridge that implements one or more HbH options. As for
criticality, TRILL is an interesting case. Since I believe the Rbridges
will be required to advertise their support of options in the link state
database, it will be reasonable, at least in the known unicast case, to
require an Rbridge not to send any critical options to an Rbridge that
won't understand them. But the multi-destination case is, as usual, more
complex. By the way, I think ItE is more precise than E2E. The option
isn't in the frame from end-to-end. It's in the TRILL Header from
Ingress to Egress.

@@@ Since I believe one of the primary purposes of an options feature is
to accommodate future options that have not yet been considered, it is
going to be a bit hard to give you the details of such options. I
believe that by consensus we have an options feature with a 5 bit
Options Length field and an options area whose size in bytes is four
times that Length. But perhaps, as they say, the devil is in the details
beyond that.

@@@ Thanks,
@@@ Donald

--
Eric Gray
Principal Engineer
Ericsson  

> So...what do people think?
This is a message from the MailScanner E-Mail Virus Protection Service
----------------------------------------------------------------------
The original e-mail attachment "Drafts.xnk"
has an unusual filename and could possibly be infected with a virus.
As a precaution, the attachment has been quarantined.

Virus scanner report for Tue Dec 11 21:28:53 2007:
   MailScanner: Microsoft Exchange Shortcuts are dangerous in email (Drafts.xnk)

Quarantine location:  4-43-8 /var/spool/quarantine/20071211 (message lBC5Sm1J022982).

If you were expecting the attachment and would like to receive it,
please forward this e-mail to [email-masked] for assistance.  If this
is urgent, please call Action at x88289 after forwarding the message.

Thank you,

IPC Computing Services

---

From: Erik Nordmark <[email-masked]>
Date: Wed, 12 Dec 2007 18:26:51 -0800

> that seems like a small price.)

With the above ordering constraint it might still be useful to include a 
length of each of the four types, for instance by having the option part 
of the packet start with four N-bit numbers.

That allows a transit RBridge which supports no hop-by-hop options to 
just look at "length of #1 != 0" and if so discard the packet, and it 
allows decapsulating RBridges that don't support any end-to-end options 
to also check quickly that length, and determine the offset for the 
critical end-to-end options.

I think that would make it slightly more efficient to implement RBridges 
that support some options.

But it still isn't clear to me which cases of options we think are worth 
optimizing.

    Erik

---

From: "Eric Gray" <[email-masked]>
Date: Thu, 13 Dec 2007 01:02:46 -0600

Donald,

	It looks as if some part of your E-Mail got jettisoned
by the forwarder.  Hopefully it was nothing central to your
point in this posting.

--
Eric Gray
Principal Engineer
Ericsson  

> [mailto:[email-masked]] On Behalf Of Eastlake III 
> Donald-LDE008
> Sent: Wednesday, December 12, 2007 12:29 AM
> To: [email-masked]
> Subject: [rbridge] {Filename?} RE: Critical bits for options
> 
> @@@ Many options have been presented or discussed and 
>	described at many TRILL WG meetings and those 
>	presentation are in the IETF proceedings for
>	those meetings. Suggestions have included port ID 
>	(LID), flow ID, security, Customer ID, and various 
>	optimizations. See also descriptions of two of these 
>	in my previous message to John Drake.

I may want to respond to each of these on a separate thread,
but - in general - I thought these were brought up to justify
including the "options length" field in the header.  That was
a reasonable - forward-looking - compromise to satisfy those
who felt that options might become important.

The current proposals - in particular related to the concept
of a 'critical bit' (and associated handling) and the notion
of HbH verses E2E are not as generally applicable as you may
think.  In fact, the same point has been (and is conitnuing
to be) made in other currently on-going work in the IETF now.

As an example, suppose you have an option that applies to 
multicast forwarding but only needs to be acted upon by the
replication points in a multicast tree.  Is that HbH or E2E?

Also, the definition of 'critical' and corresponding handling
seems somewhat strained for general applicability.  I thought
I had been explicit enough on this point previously, but that
may not have been the case.  Is it always going to be the case
that simply discarding a frame is sufficient, or will there be
cases in which the application is critical and the device that 
inserted the option needs to know that the frame was delivered
(or, if not delivered, the point at which delivery fails)?

> 
> @@@ In any case, I think one of the largest benefits of 
>	an options feature is the ability to add options 
>	later that you can't think of to start with.

Yeah, right.  And therefore it is important - once you start
thinking about this options feature - that you include robust
"future proofing" for at least those applications you already 
can think of.

I would argue that we are not doing that and that the current
discussion appears to be more concerned about a specific set
of applications that have not been explicitly defined.  Let's
spell-out specifically the set of applications we are looking
at implementing right now to see if the current proposals are
sufficient for that purpose, and then worry about how to make
this proposal "future proof" against subsequent potential
applications.  Are you prepared to define explicit, currently
existing, requirements for this options feature?

> @@@ We are talking about boxes that are all in the same 
>	broadcast domain and are quite often subject to 
>	coordinated management. In any case, if the boxes 
>	are fighting with each other, than can throw away 
>	data whenever they want regardless of whether any 
>	option feature or options are defined or used.
> 
> @@@ Since the options are in the TRILL header, they could 
>	be added to any frame. Whether a particular option 
>	would make sense for data and/or control (TRILL IS-IS) 
>	frames depends on the option. 

Very much so.

> @@@ (cont.)
>	Seems like adding a non-critical option to a frame 
>	would be more likely put it "in jeopardy" if some 
>	down stream Rbridges can't figure out what the 
>	situation is in terms of criticality, etc., which 
>	is why you want to specify a little more now.

This is an interesting assertion.  For one thing, it brings
up the question of whether or not the option is considered
to be more critical than the data.

My point is that we are probably not specifying enough, now,
unless we simply leave it as is (meaning we include a field
for options length in the header but don't actually define
anything else at this point).  Not knowing what the specific
applications are, how can we define 'critical', how can we
define appropriate handling and how can we even define what 
the meaning of terms - like HbH and E2E - is?

> @@@ People keep telling me that in the high end wired switch 
>	market, which is well represented in the TRILL WG, people 
>	build things to run the worst case that's still on the 
>	fast path at line speed so, for example, it is rarely 
>	useful to add an optimization unless it also helps the 
>	worst case. 

People do say the most interesting things.

> @@@ (cont.)
>	A similar consensus is why we dropped any encoding into 
>	the TRILL header of what tree pruning should be used for 
>	a frame but instead are currently forcing every Rbridge 
>	including transit RBridges, if they wish to do such 
>	pruning, to do the frame examination. 

As a matter of curiosity (because I tend to agree with this),
was this a WG consensus, or a design team consensus?

> @@@ (cont.)
>	I think such people would say that your concept of an 
>	Rbridge increasing its "sensitivity" to a critical frame 
>	because it was "congested" is bizarre and would never 
>	happen in anything they plan to build. 

Yep, heard that one before as well.  People who say things
like that are clearly assuming that no disconnect ever occurs
between what gets specified and what gets implemented, or that
people doing implementation and testing look at these things 
from the same perspective (as other people doing the same) or 
even that there has to be some degree of deliberation in 
implementation for something like this to happen.

In my mind, the likelihood that 'anti-social' behavior like 
this would occur in a specific implementation is related to
the complexity of the feature in question and the likelihood
that this feature is affected by proprietary implementation
details - rather than to any sort of maliciousness on the
part of a specific implementor.

Clearly this "options feature" is dead-center in the middle
of an area where proprietary implementation choices are very
likely to affect feature interoperability.

> @@@ (cont.)
>	I think they would also tell you that they don't plan 
>	to implement any options but if they did implement one 
>	that might commonly appear in frames, their bridges 
>	would be able to process it in the fast path for 
>	reasonable cases. 

Wow!  Imagine that!  An implementor that says their equipment
does everything fast.  Imagine my surprise (you'll need to, 
because you won't find it any other way)...

> @@@ (cont.)
>	I would expect the support of an option by an Rbridge 
>	to be reported in the link state database and be 
>	extremely stable, baring firmware updates or the like.

Ah, yes.  And this is another case that has been discussed 
relative to options before: if I think that acceptability
of an option has been established (particularly within an
implementation of protocol involving a state-machine), then
the failure of an option to be accepted as expected is an
indication of an "insane state."  Under these circumstances,
it has been argued previously, not only should the receiver
of an unexpected 'critical option' discard the associated
frame, but it should also consider the sender to be in an
insane state (and take appropriate corrective action by -
for instance - reseting the peer relationship).

Also, before we talk to much about adding this level of per
link information to be stored in the LSDB, we should call
in the Link-State routing experts to comment on the validity
of the assumption that we can do this.

> @@@ I did and I'm proud of it. There are a number of options 
>	whose inclusion, in my opinion, would not be a nightmare 
>	but would rather be sweetness and light. 

Yeah, well, as they like to say at auctions - one man's trash 
is another man's treasure.

> @@@ (cont.)
>	The inclusion of an options feature substantially improves 
>	the TRILL protocol. 

More precisely, the inclusion of the ability to later add this
feature substantially improves the future viability of TRILL.
Adding this feature explicitly at this point does nothing of
the sort.

> @@@ (cont.)
>	And, as I recall, there is a formal WG consensus 
>	determination specifying the TRILL header with Option 
>	Length field. 

Precisely.

As an analogy, you get the kid who threatens to hold his 
breath until you give him a pony.  You think, well maybe
the kid really could use a pony.  Now the kid wants to 
take the pony and join the circus.

What we have consensus on is to allow for options in the
future.  Including an options length field is sufficient
to allow for that.

> @@@ (cont.)
>	We are just discussing details of options and which 
>	of those details to include in the protocol 
>	specification now.
> 

No.

> @@@ (cont.)
>	Seems to me that many of the most successful protocols 
>	do. 

Yes, and at least some of those have never actually had much 
use of the options feature.  That would argue that - possibly
- you're getting the cart befor the horse.  Maybe successful
protocols are sometime successful in spite of the fact that 
they may include options, huh?

> @@@ (cont.)
>	See the presentation at the Thursday evening Plenary at 
>	IETF 70 which finds a correlation between flexibility 
>	and protocol success:
> 	http://www3.ietf.org/proceedings/07dec/slides/plenaryt-1.pdf. 

Thanks for providing me with an URL for a plenary presentation
for the meeting I was just at.

> @@@ (cont.)
>	And it seems to rarely if ever be the case that a simple 
>	linear sequence of versions is adequate. (I think we also 
>	have a number of other success factors listed in that 
>	presentation.)
> 
> @@@ It's silly to think that adding an option to a frame 
>	would magically cause all downstream Rbridges to 
>	implement that option. 

It's even sillier to suppose that anyone suggested that.

> @@@ (cont.)
>	But I would agree that if an Rbridge advertises in the link 
>	state database that it supports an option, then it should do 
>	so.

And now we are assuming that this will be included in the LSDB
(as opposed to asserting that it may be)?

The statement I made above (relative to approriate responses
in this case) applies.  Failure of a device to accept what it
has previously agreed to accept represents a serious error -
for which "oh, well, maybe if I simply forget about it, it
will go away" may be a less than adequate response.

> @@@ "need" is a funny word but yes, I believe that at some 
> 	point in the future we will find that we "need" to add 
>	an option. As to why having an option feature is 
>	"desirable", which I think is a more reasonable criteria, 
>	see the presentation whose URL appears above, some of the

I guess you missed my point.  I do not argue that we don't
need to leave open the possibility of having options in the
future.  I do argue that we don't know enough at this point
to say more than that about it.

You argue that we need to also include a mechanism to allow
for appropriate handling of different types of options - in
a forward-compatible context.  This is not an unreasonable
position.  However, we simply do not have enough information
to determine the level of detail in "appropriate handling"
that you want to define.

> 
> @@@ As to why its useful to distinguish HbH and ItE options 
>	and critical vs. non-critical options: If you marshal 
>	your options in a rational way, the more you can classify 
>	as ItE, the fewer might have to be looked at by a transit 
>	Rbridge that implements one or more HbH options. As for
>	criticality, TRILL is an interesting case. Since I believe 
>	the Rbridges will be required to advertise their support 
>	of options in the link state database, it will be 
>	reasonable, at least in the known unicast case, to require 
>	an Rbridge not to send any critical options to an Rbridge 
>	that won't understand them. But the multi-destination case 
>	is, as usual, more complex. By the way, I think ItE is more 
>	precise than E2E. The option isn't in the frame from 
>	end-to-end. It's in the TRILL Header from Ingress to Egress.

I think this is pretty clear, but rests on assumptions we do
not have enough information to make.

I also think that I've explained that enough in previous parts
of this message that I don't need to say more along those lines.

I will add, however, that the above seems to conflate the use
of 'critical options' with the assumption of extended LSDB 
content/negotiation as well as additional informaion assumed
on a per-forwarding entry basis.  This is a nice detail to
be making people aware of.

> @@@ Since I believe one of the primary purposes of an options 
> 	feature is to accommodate future options that have not yet 
>	been considered, it is going to be a bit hard to give you 
>	the details of such options. I believe that by consensus 
	we have an options feature with a 5 bit Options Length 
>	field and an options area whose size in bytes is four times 
>	that Length. But perhaps, as they say, the devil is in 
>	the details beyond that.

Yeah, that would be the case.  And I'm not particularly ready
for (or interested in) an interview with the devil, just yet.

---

From: James Carlson <[email-masked]>
Date: Thu, 13 Dec 2007 10:07:08 -0500

> replication points in a multicast tree.  Is that HbH or E2E?

Forcing that case to be HbH solves the problem.  The hops that are not
replication points need do no work, but we don't necessarily know
which ones these are ahead of time, so we do need each hop to handle
it.

(I get the general point that there may be choices outside of HbH and
E2E, but I'm not sure this example nails the problem.)

> future.  Including an options length field is sufficient

It's sufficient only if we also remove the text in the current draft
that supposes the existence of "critical" options.

With that text in place, we're in an impossible position: nodes are
required to drop packets with uninterpreted "critical" options, but
they have no way to determine whether any such options are present
that might pose a problem.

That's why I previously suggested defining the length field, supposing
all options are "non-critical," and then bumping the TRILL version
field if we ever require "critical" options.

> will go away" may be a less than adequate response.

It's actually unclear to me whether it constitutes any sort of error
for the general case.

The problem is that TRILL packets are forwarded based on tables at
each hop -- they're not source-routed.  That means that the original
sender who generated the packet and inserted those options may not
necessarily know which nodes will actually handle the packet, and thus
doesn't necessarily know which options can be interpreted on the path.

---

From: "Drake, John E" <[email-masked]>
Date: Thu, 13 Dec 2007 10:33:08 -0800

Donald,

The two options that you mention below are data plane functions, but
there may be control plane interactions required to instantiate them and
it wasn't clear whether these interactions would be piggybacked on data
frames.  They also appear to introduce unnecessary complexity.

Additional comments are inline.

Thanks,

John

>From: Eastlake III Donald-LDE008 [mailto:[email-masked]] 
>Sent: Tuesday, December 11, 2007 1:27 PM
>To: [email-masked]
>Can you point to a specific option that has been suggested 
>which is a control plane function? I don't think any of them 
>are. Let me describe two and tell me what you think.
>
>(In this message, I'm not arguing for or against these options 
>or giving much detail but just trying to give a sketch to see 
>if you think these are control plane functions.)
>
>Port ID (also called Local ID or LID): The idea is to avoid 
>the MAC address to port look up at an Egress Rbridge for 
>unicast traffic. It works by supplementing the source and 
>destination MAC with a source and destination LID. LIDs are 
>probably 16-bits and would be learned the same way MAC 
>addresses and egress Rbridge are learned, by default from data 
>frame observation.

JD:  Since an Rbridge will still have to do MAC address to port look-up,
this other mechanism simply adds additional complexity.  Also, why is it
easier for the ingress Rbridge to perform the egress MAC address to port
look-up than it is for the egress Rbridge? 

>There would probably have to be a 
>distinguished LID value which means unknown but otherwise LIDs 
>are a local matter presumably chosen so that the LID to port 
>mapping is trivial.
>	Obviously an Rbridge that didn't support the option 
>wouldn't send it and would ignore it on receipt. Since support 
>would be indicated in the link state database, an Rbridge that 
>supported it might still choose not to include it in a frame 
>to an egress Rbridge that will ignore it. For unknown unicast, 
>you might want to include it or not or maybe it's configurable 
>but this and other considerations would be part of the more 
>detailed design. This option is probably not useful for 
>Security: The idea would be to leverage any IS-IS security 
>keying so as to authenticate or authenticate and encrypt data 
>frames. This would probably require hardware assist to be 
>practical. While you could put such an option in a control 
>frame, it's probably better to use the IS-IS security features 
>directly. A security option could be used either hop-by-hop or 
>ingress-to-egress but ItE probably makes more sense.

JD:  Is there a requirement to do this, or is it simply a case of it can
be supported so it should be supported?  If the applications want
security, why wouldn't they simply use IPsec?   

>But maybe 
>there are some high security applications where you want both 
>or cases where a particular physical link goes through an area 
>subject to less physical control and security, where it would 
>be worth getting Rbridges with security assist hardware in 
>their ports just for that one hop or the like.

JD:  How would high security applications have any knowledge of the
Rbridge topology, in particular that encryption was available on a given
insecure link, or be able to influence the path that its packets take
through the Rbridge topology such that its packets transit that link?

>
>Do you consider the above options to be control plane 
>functions that are inappropriate to include in a data frame?
>
>Thanks,
>Donald 
>
>[mailto:[email-masked]] On Behalf Of Drake, John E
>I think this is a great e-mail.  Piggybacking control plane 
>functions, especially critical ones, on data frames seems 
>ill-advised for the health and well being of both the control 
>plane and the data plane.
>
>Thanks,
>John 
>

---

From: Joe Touch <[email-masked]>
Date: Thu, 13 Dec 2007 10:37:38 -0800

IMO, here are the important elements:

1. option order
	if you care about short-circuit option processing,
	which is reasonable, then we should put HBH options
	before E2E ones, and required options (i.e., discard
	if not supported) before voluntary options (i.e.,
	pass if not supported)

2. option groups

	Hop-by-hop
		examined at all rbridges

	End-to-end
		examined ONLY at ingress and egress rbridges

	Discard
		if not supported, the device discards the segment

	Pass
		if not supported, the device passes the segment

	Silent
		if not supported, the device acts as indicated
		with no further action (e.g., discard or pass)

	Noisy
		if not supported, the device sends a signal segment
		indicating the failure upstream towards the offending
		segment source; this MAY occur periodically as an
		aggregate signal

	NB: that means THREE flags in every option

Some on this list argue that the common case will be devices that
support no options, thus it would be useful to also know the following:

3. summary flag in the main header

	ALL SILENT, ALL PASS

This would be a logical OR of all equivalent bits in the options.

The cost of doing this is that:

	1. space in the main header

	2. adding/removing any option MUST update the summary flag

	COST to add: easy; just OR the extra bits

	COST to delete: expensive; MUST scan other headers
	to determine whether the summary flag changes
	i.e., every option delete is O(entire option space) in cost

Whether this summary flag represents HBH only or includes E2E, or
whether there are two flags - one for each - is also up in the air.

A key point here is that the summary flag makes sense ONLY if there are
SILENT, PASS options. IMO, they're useless - if an rbridge can ignore an
option and be equivalently compliant, why would it ever implement that?

I.e., I would argue that any SILENT, PASS options are thus implicitly
optional, and should be omitted from consideration anyway.

As a result, it makes no sense to me to include the summary bit(s).

Joe

---

From: Dinesh G Dutt <[email-masked]>
Date: Thu, 13 Dec 2007 11:48:07 -0800

Very nice summary Joe.

I disagree with your conclusion of "If an RBridge can ignore an option 
and be compliant, who would implement it". For cost reasons, I see that 
we can build a device with a small MAC table than uses the LID, in 
Donald's example, to forward the frame at the last hop RBridge (this 
will be in a modular chassis with separate ingress and egress forwarding 
tables). I can also see a bunch of other examples where the core 
RBridges are the existing ones, with no support for options, but the 
edges support a new option that provides a value add and so customers 
can only change the edge devices and not upgrade their core RBridges 
(i.e. all their infrastructure to gain support of a feature).

If we don't add support for this (a summary bit or two), I think options 
are dead in the water. Bumping the version number doesn't work unless we 
add verbiage to indicate essentially the same thing. Most implementors 
barf if they see a version that is different from what they're expecting.

I also see that the cost of parsing options is something that those 
RBridges that support options must do and so setting the summary bit, 
clearing the summary bit is all work that they'll do anyway. Unsetting a 
bit is far less work than stripping an option, for example and so I'm 
not worried about that complexity. But those RBridges that don't support 
options can merely look at the summary bits without worrying about 
understanding and parsing through all the options.

Dinesh

---

From: Joe Touch <[email-masked]>
Date: Thu, 13 Dec 2007 12:07:29 -0800

> (i.e. all their infrastructure to gain support of a feature).

The last issue would address the HBH vs E2E options. It still begs the
question of silent pass E2E options.

> barf if they see a version that is different from what they're expecting.

I don't see why the decision is:

	a) summary bit (or two)
	OR
	b) version numbers

There is a fine third option, which is what IPv6 uses:

	c) declare the basic format of an option now
	and the bits therein, and parse the options at each hop

Note also that the summary bits are basically equivalent to:

	d) declare an option right now that is a function of these
	bits in all the other options, and which must appear first
	in the option list

> clearing the summary bit is all work that they'll do anyway.

Processing a single HBH option is much less work than scanning all
remaining options to decide whether to clear the summary bit.

> Unsetting a
> not worried about that complexity.

To be more clear, stripping an option - or changing its bits - involves
 work, but much less than subsequently scanning all remaining options to
recalculate the summary bit.

> But those RBridges that don't support

If we outlaw options that are SILENT, PASS, HBH - which is a very wierd
case - then we really don't need a bit at all. All we need to do is
examine the first option:

a HBH rbridge could then execute the following:

	- if there ARE options, AND the first option is HBH
		FAIL
	else
 		PASS
	
IMO, E2E rbridges don't need this optimization.

Joe

---

From: "Caitlin Bestler" <[email-masked]>
Date: Thu, 13 Dec 2007 15:59:06 -0500

Thanks for a very useful summary. Comments in-line.

> Sent: Thursday, December 13, 2007 10:38 AM
> To: [email-masked]
> Subject: [rbridge] Summary of "critical bits" issues
> 

A Devil's  Advocate question here: Is this the *only* option required?

That is, how severe a limitation would it be if all options were
mandatory,
but end-to-end options were ignored by all intermediate rbridges?

Wouldn't that be sufficient for the strawman options that have been
discussed?

---

From: Dinesh G Dutt <[email-masked]>
Date: Thu, 13 Dec 2007 13:17:10 -0800

Joe,

I see now that what you're proposing is that all RBridges learn how to 
process options from day one, the processing logic is what an 
intelligent IPv6 router does. I see the logic. If this acceptable to 
all, I'm fine with it.

Dinesh

---

From: James Carlson <[email-masked]>
Date: Thu, 13 Dec 2007 16:20:29 -0500

> barf if they see a version that is different from what they're expecting.

I'm not sure exactly what "barf" means in this context, but the
current draft says that if you see a packet with the wrong version
number, you must drop it.

That's consistent with the definition of critical options: if any are
present, and you don't know what they mean, then you must drop.  Thus,
the two seem fairly well aligned; it's possible to insist today that
all future options are exactly that -- optional -- and that if this
position changes to included non-optional-options ("critical"), then
we will have a new protocol.

> understanding and parsing through all the options.

I'm less worried about the work involved than the likelihood of
error.  Any time information is duplicated -- carrying both a "this
option is critical flag" as well as a "there are critical options
present" flag -- you run the risk of having the two independent
sources of information being out of sync.

What's perhaps worse is that you have to define procedures in the
protocol for systems that may encounter these error states.  It adds
complexity.

---

From: "Eric Gray" <[email-masked]>
Date: Thu, 13 Dec 2007 18:12:20 -0600

James,

	See below.

--
Eric Gray
Principal Engineer
Ericsson  

> From: James Carlson [mailto:[email-masked]] 
> Sent: Thursday, December 13, 2007 10:07 AM
> To: Eric Gray
> Cc: Eastlake III Donald-LDE008; [email-masked]
> Subject: Re: [rbridge] {Filename?} RE: Critical bits for options
> Importance: High
> 
> Eric Gray writes:

That obviously depends on what it takes to convince you that
the problem has been "nailed."  In my opinion, the argument
you make is equally valid for anything currently discussed
for the I2E (verses E2E - as Donald points out) - you could
always force any case to be HbH.

The argument that it may be unnecessary to have core RBridges
upgraded to accommodate even a 'critical' option if there is
the ability to indicate that the option only matters at the 
egress seems to apply equally well in other cases - possibly
including the multicast case (although that may be a stretch
in the general multicast case, there are applications for IP
multicast where only a certain well-defined subset of the IP
routers involved ever need to perform replication - and I am
reasonably sure that the same could apply RBridges).

In any case, if you acknowledge the general point, then you
admit that we're guessing that HbH and I2E is sufficient.

> that might pose a problem.

And yet still this seems strange to me an I cannot see why it
does not seem equally strange to everyone else.

Consider that we're presumably talking about data frames - at
least from the perspective of the forwarding function, and for 
all frames containing what we're referring to as a 'critical 
option.'  Yet the handling described seems unprecedented in
anything I am aware of that the industry has done in the past
- except for control PDUs (frames and/or packets).

Maybe I missed it, but I don't recall seeing anything that has
indicated this would apply only to RBridge control protocols -
which I believe are all still neighbor to neighbor.  

I believe that it has already been suggested that "options" 
that might apply I2E (or any subset of "hops" that a given
class of frames will traverse) are most appropriately going
to be handled as a higher level function based on in payload 
contained in a frame - rather than on the frame as a whole.

Why is it that everyone is not asking themselves why we're
trying to solve this problem, here in TRILL and now at the
current level of protocol immaturity and inexperience?

> field if we ever require "critical" options.

I would qualify this similarly; we can decide now whether or
not all options are critical or no options are critical in 
this version.  

It is unlikely that we'll decide every option is critical,
because doing that would make defining an option length
field silly in this version.  Simply having a non-zero
value in that field could be tantamount to inserting a 
'discard me' flag as far as any existing implementation 
is concerned.

But, if we did do that, we could still deal with critical
options in future protocol extenions - without necessarily
bumping the version number.  The proof-of-concept approach
to doing that is to include option-support advertisement
in LSAs and in the LSDB.  Then only a broken implementation
would ever insert any option in a frame due to be forwarded 
on a path including one or more hops that didn't indicate 
that they could handle that option.

This, incidentally, is what I found to be strange in what
Donald said earlier about his presumption that this would
be in the LSDB - but that we still need to indicate whether
or not any particular option is critical.  Why would you
ever need both?

On the other hand...

If we decide that no option is critical, but subsequently 
come up with a 'critical' application (forgive the play on 
words), there are ways to handle that - either in the same 
version or by bumping the version.  

Strictly as a proof of concept example, if future protocol 
extensions require some subset of all RBridges to process 
an option, then part of "processing an option" may include 
inserting a cooky to indicate that you've processed the
option - after verifying that your predecessor did so and 
before passing the cooky-containing option to a successor.

Note that - in this case - "predescessor" would be defined 
in a way that would apply for any specific future protocol 
extension in question.  That might include every hop (in
which case a simple implementation of this cooky approach
is so trivial I won't even bother describing it), or it 
may include any arbitrary subset of the hops along any
particular path (in which case the same scheme would be 
slightly more complicated). Also note that none of this 
has to be defined now.

That approach places the entire onus of dealing with the 
new protocol extension(s) on the implementations that are
required to participate (and therefore would have been 
upgraded to have the capability) - and does not require 
a bump in the version number.

And - clearly - there is always the possibility of bumping
the version number.  As others have not hesitated to use 
this argument, I will not either: several of the successful 
protocols around today have enjoyed the privilege of doing
so.  We're not, for example, currently using IPv1, nor is
the Internet meticulously stitched together using BGPv1.

> It's actually unclear to me whether it constitutes any sort of error

Let's first assume that - as is the case with IS-IS generally -
establishment of a peering relationship occurs before forwarding
is possible.

For this general case, negotiation results that MUST occur at the
time of establishing a relationship MUST be valid for the duration 
of the relationship.  Otherwise, the negotiation means nothing.
If re-negotiation is allowed for a valid existing relationship, 
things get a bit dicier (but then the first MUST above doesn't
apply); in this case, there MAY be a window of opportunity during 
which forwarding MAY occur that is inconsistent with negotiated
terms.  There are ways to avoid this, but the simplest is to avoid
re-negotiation.

But that may not be necessary.

This argument is true for general case of advertised capabilities - 
with some caveats:

o	it is likely (possibly even unavoidable) advertised
	capabilities will change,
o	advertisements do not always enjoy the deterministic
	nature of a relationship (e.g. - such as peering) and
o	windows of opportunity (where forwarding may not be
	consistent with advertised capabilities) are most 
	likely going to be unavoidable.

However, if you look at these "windows of opportunity" in both 
cases - and assume that all options are treated as if critical
- then what you get is dropped frames during the same window
of opportunity.  Since this WoO occurs as a result of changed
advertisements, I fail to see how this should alarm anyone.

> doesn't necessarily know which options can be interpreted on the path.

Actually this is not true for steady-state forwarding.  In the
absence of an ongoing transient, every link state router has 
exactly the same information as ever other link state router
and is in possession of all that it needs to know to be aware 
of the path any frame will traverse.

And - as descibed above - in the transient case - the result of
imperfect knowledge is that frames will get dropped that might
not otherwise have been dropped.  This is a characteristic of
network transients and not something to be alarmed about.

Content-class: urn:content-classes:message
Date: Thu, 13 Dec 2007 18:12:20 -0600
From: "Eric Gray" <[email-masked]>
To: "James Carlson" <[email-masked]>
Cc: [email-masked]
Subject: Re: [rbridge] {Filename?} RE:  Critical bits for options
Status: RO
Content-Length: 9814

James,

	See below.

--
Eric Gray
Principal Engineer
Ericsson  

> From: James Carlson [mailto:[email-masked]] 
> Sent: Thursday, December 13, 2007 10:07 AM
> To: Eric Gray
> Cc: Eastlake III Donald-LDE008; [email-masked]
> Subject: Re: [rbridge] {Filename?} RE: Critical bits for options
> Importance: High
> 
> Eric Gray writes:

That obviously depends on what it takes to convince you that
the problem has been "nailed."  In my opinion, the argument
you make is equally valid for anything currently discussed
for the I2E (verses E2E - as Donald points out) - you could
always force any case to be HbH.

The argument that it may be unnecessary to have core RBridges
upgraded to accommodate even a 'critical' option if there is
the ability to indicate that the option only matters at the 
egress seems to apply equally well in other cases - possibly
including the multicast case (although that may be a stretch
in the general multicast case, there are applications for IP
multicast where only a certain well-defined subset of the IP
routers involved ever need to perform replication - and I am
reasonably sure that the same could apply RBridges).

In any case, if you acknowledge the general point, then you
admit that we're guessing that HbH and I2E is sufficient.

> that might pose a problem.

And yet still this seems strange to me an I cannot see why it
does not seem equally strange to everyone else.

Consider that we're presumably talking about data frames - at
least from the perspective of the forwarding function, and for 
all frames containing what we're referring to as a 'critical 
option.'  Yet the handling described seems unprecedented in
anything I am aware of that the industry has done in the past
- except for control PDUs (frames and/or packets).

Maybe I missed it, but I don't recall seeing anything that has
indicated this would apply only to RBridge control protocols -
which I believe are all still neighbor to neighbor.  

I believe that it has already been suggested that "options" 
that might apply I2E (or any subset of "hops" that a given
class of frames will traverse) are most appropriately going
to be handled as a higher level function based on in payload 
contained in a frame - rather than on the frame as a whole.

Why is it that everyone is not asking themselves why we're
trying to solve this problem, here in TRILL and now at the
current level of protocol immaturity and inexperience?

> field if we ever require "critical" options.

I would qualify this similarly; we can decide now whether or
not all options are critical or no options are critical in 
this version.  

It is unlikely that we'll decide every option is critical,
because doing that would make defining an option length
field silly in this version.  Simply having a non-zero
value in that field could be tantamount to inserting a 
'discard me' flag as far as any existing implementation 
is concerned.

But, if we did do that, we could still deal with critical
options in future protocol extenions - without necessarily
bumping the version number.  The proof-of-concept approach
to doing that is to include option-support advertisement
in LSAs and in the LSDB.  Then only a broken implementation
would ever insert any option in a frame due to be forwarded 
on a path including one or more hops that didn't indicate 
that they could handle that option.

This, incidentally, is what I found to be strange in what
Donald said earlier about his presumption that this would
be in the LSDB - but that we still need to indicate whether
or not any particular option is critical.  Why would you
ever need both?

On the other hand...

If we decide that no option is critical, but subsequently 
come up with a 'critical' application (forgive the play on 
words), there are ways to handle that - either in the same 
version or by bumping the version.  

Strictly as a proof of concept example, if future protocol 
extensions require some subset of all RBridges to process 
an option, then part of "processing an option" may include 
inserting a cooky to indicate that you've processed the
option - after verifying that your predecessor did so and 
before passing the cooky-containing option to a successor.

Note that - in this case - "predescessor" would be defined 
in a way that would apply for any specific future protocol 
extension in question.  That might include every hop (in
which case a simple implementation of this cooky approach
is so trivial I won't even bother describing it), or it 
may include any arbitrary subset of the hops along any
particular path (in which case the same scheme would be 
slightly more complicated). Also note that none of this 
has to be defined now.

That approach places the entire onus of dealing with the 
new protocol extension(s) on the implementations that are
required to participate (and therefore would have been 
upgraded to have the capability) - and does not require 
a bump in the version number.

And - clearly - there is always the possibility of bumping
the version number.  As others have not hesitated to use 
this argument, I will not either: several of the successful 
protocols around today have enjoyed the privilege of doing
so.  We're not, for example, currently using IPv1, nor is
the Internet meticulously stitched together using BGPv1.

> It's actually unclear to me whether it constitutes any sort of error

Let's first assume that - as is the case with IS-IS generally -
establishment of a peering relationship occurs before forwarding
is possible.

For this general case, negotiation results that MUST occur at the
time of establishing a relationship MUST be valid for the duration 
of the relationship.  Otherwise, the negotiation means nothing.
If re-negotiation is allowed for a valid existing relationship, 
things get a bit dicier (but then the first MUST above doesn't
apply); in this case, there MAY be a window of opportunity during 
which forwarding MAY occur that is inconsistent with negotiated
terms.  There are ways to avoid this, but the simplest is to avoid
re-negotiation.

But that may not be necessary.

This argument is true for general case of advertised capabilities - 
with some caveats:

o	it is likely (possibly even unavoidable) advertised
	capabilities will change,
o	advertisements do not always enjoy the deterministic
	nature of a relationship (e.g. - such as peering) and
o	windows of opportunity (where forwarding may not be
	consistent with advertised capabilities) are most 
	likely going to be unavoidable.

However, if you look at these "windows of opportunity" in both 
cases - and assume that all options are treated as if critical
- then what you get is dropped frames during the same window
of opportunity.  Since this WoO occurs as a result of changed
advertisements, I fail to see how this should alarm anyone.

> doesn't necessarily know which options can be interpreted on the path.

Actually this is not true for steady-state forwarding.  In the
absence of an ongoing transient, every link state router has 
exactly the same information as ever other link state router
and is in possession of all that it needs to know to be aware 
of the path any frame will traverse.

And - as descibed above - in the transient case - the result of
imperfect knowledge is that frames will get dropped that might
not otherwise have been dropped.  This is a characteristic of
network transients and not something to be alarmed about.

Date: Thu, 13 Dec 2007 14:53:15 -0800
From: Radia Perlman <[email-masked]>
To: "Drake, John E" <[email-masked]>
Cc: [email-masked]
Subject: [rbridge] Offlist Re:  Critical bits for options
Status: RO
Content-Length: 2776

John -- I'm answering your question about "customer ID" offlist because 
it's kind of orthogonal to this thread,
which is how to encode the options. I think it was discussed on the list 
awhile ago, and I will want to
discuss it on the list at length at some point, but I don't want to 
distract people now.

So...what was I mumbling about with "customer ID"...

Suppose you have a provider that is gluing together customer Ethernets. 
Each customer is using VLANs, and with
overlapping numbers. VLAN "3" for one customer is not the same as VLAN 3 
at another customer, and your customers
would not want their VLAN 3 traffic sent to the other customer's VLAN 3.

The way I'd like to do this is for there to be kind of "level 1 TRILL" 
and "level 2 TRILL". Within a customer campus, the
VLAN would be the 12 bit thing defined by IEEE 802.1Q. However, an edge 
RBridge, RB1, at the provider (ones that connect to
customer campuses but are participating in the backbone that connects all
the customer campuses) know that there is actually another level of 
hierarchy; "customer ID". The customer ID can take any
form -- it need not look like a VLAN tag. For instance, it could be a 5 
byte number, or it even could
be variable length. I'll use ASCII strings in this email for the 
customer ID.

RB1 (edge provider RBridge) is configured to know that this port goes to 
customer "ACME-CORP", and this other port goes
to "VWX-ENTERPRISES". To edge RBridges, the concatenation of "customer 
ID" and "VLAN" acts as a larger VLAN space. Let's
call that space "C-VLAN", for "concatenated customer ID and VLAN".
So RB1 keeps a learning table for C-VLANs, and otherwise performs just 
like an ingress/egress RBridge in the current TRILL spec.
When RB1 sees a native frame on a port that RB1 is configured to assume 
belongs in
("ACME-CORP", VLAN 3), it looks in its learning table for C-VLAN 
("ACME-CORP", VLAN 3)
to see if it knows which egress RBridge owns the destination. If RB1 has 
learned that the frame should be forwarded across the
backbone to RB2, then RB1 encapsulates towards RB2, but adds the 
critical ItE option "customer ID="ACME-CORP".

Transit RBridges don't care about the customer ID. Only the egress, RB2, 
needs to understand it. If RB2 does not understand it, then
there is the danger RB2 will forward it to a different customer's "VLAN 3".

Now one could argue that RB1 would not send it to RB2 if RB2 didn't 
understand the "customer ID" option, and I have to admit
I am not all that enthralled with "critical" options.

Hope that clarifies somewhat.

Radia

Drake, John E wrote:
> Radia,
>
> The customer ID listed in your e-mail, below, makes no sense to me.  How
> would the ingress discover this information and what would the egress do
> with it?  

Date: Thu, 13 Dec 2007 16:20:29 -0500
From: James Carlson <[email-masked]>
To: Dinesh G Dutt <[email-masked]>
Cc: [email-masked], Joe Touch <[email-masked]>
Subject: Re: [rbridge] Summary of "critical bits" issues
Status: RO
Content-Length: 2029

Date: Thu, 13 Dec 2007 13:17:10 -0800
From: Dinesh G Dutt <[email-masked]>
To: Joe Touch <[email-masked]>
Cc: [email-masked]
Subject: Re: [rbridge] Summary of "critical bits" issues
Status: RO
Content-Length: 3334

Joe,

Dinesh

Content-class: urn:content-classes:message
Date: Thu, 13 Dec 2007 15:59:06 -0500
From: "Caitlin Bestler" <[email-masked]>
To: "Joe Touch" <[email-masked]>, <[email-masked]>
Subject: Re: [rbridge] Summary of "critical bits" issues
Status: RO
Content-Length: 1045

Date: Thu, 13 Dec 2007 12:07:29 -0800
From: Joe Touch <[email-masked]>
To: Dinesh G Dutt <[email-masked]>
Cc: [email-masked]
Subject: Re: [rbridge] Summary of "critical bits" issues
Status: RO
Content-Length: 3474

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig7BFDB83566CCDF43E970A12C
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Dinesh G Dutt wrote:
>=20
> and be compliant, who would implement it". For cost reasons, I see that=

> will be in a modular chassis with separate ingress and egress forwardin=
g

> If we don't add support for this (a summary bit or two), I think option=
s
> are dead in the water. Bumping the version number doesn't work unless w=
e
> barf if they see a version that is different from what they're expectin=
g.

	a) summary bit (or two)
	OR
	b) version numbers

=09

Joe

--------------enig7BFDB83566CCDF43E970A12C
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

--------------enig7BFDB83566CCDF43E970A12C--

Date: Thu, 13 Dec 2007 11:48:07 -0800
From: Dinesh G Dutt <[email-masked]>
To: Joe Touch <[email-masked]>
Cc: [email-masked]
Subject: Re: [rbridge] Summary of "critical bits" issues
Status: RO
Content-Length: 4062

Very nice summary Joe.

Dinesh

Content-class: urn:content-classes:message
Date: Thu, 13 Dec 2007 10:44:57 -0800
From: "Drake, John E" <[email-masked]>
To: <[email-masked]>, "Eric Gray" <[email-masked]>
Cc: [email-masked]
Subject: Re: [rbridge] Critical bits for options
Status: RO
Content-Length: 9547

Radia,

The customer ID listed in your e-mail, below, makes no sense to me.  How
would the ingress discover this information and what would the egress do
with it?  

I'm not sure there is any value in compression or encryption, for the
reasons I listed in the reply I just sent Donald, but if compression
and/or encryption were to be performed, wouldn't it be done on all
packets between ingress and egress, and wouldn't there need to be a
negotiation between ingress and egress on the specifics of the
compresssion and/or encryption protocol to be used?

If so, then the options field is totally useless because the ingress and
egress will know exactly how to perform packet processing without it.
It also  means that these types of functions can be implemented without
being specified in any Rbridge spec.

Thanks,

John 

>From: [email-masked] [mailto:[email-masked]] 
>Sent: Tuesday, December 11, 2007 7:46 PM
>To: Eric Gray
>Cc: [email-masked]
>(using a "please limit your internet to 10 minutes" machine at 
>the conference, so hopefully I've not misinterpreted the email).
>
>Eric -- I very much sympathize with your email. In an earlier 
>version of the spec, Don had a couple of pages defining 
>options formats, and I thought it was just too complicated, 
>since I didn't think we'd ever use options, and I've never 
>liked "critical" options.
>
>However, he did tell me some examples of options. We could 
>always not have options, and only allow them with the next 
>version header, but here are some examples:
>a) a "customer ID" that you want transit RBridges to just 
>ignore, but will be useful for ingress and egress RBridges.
>b) a way of compressing the data packet, that you should be 
>careful that your upstream guy knows how to do before you send 
>it, but it's safer to make it critical so in case you 
>accidentally send it to him he won't misparse it
>c) cryptographic protection (again, should be critical so 
>someone doesn't try to interpret an encrypted packet).
>
>So he won me over and convinced me that at some point we might 
>want to allow all 4 types of options (critical/not, EtE, ItE).
>
>Radia
>
>----- Original Message -----
>From: Eric Gray <[email-masked]>
>Date: Monday, December 10, 2007 11:44 pm
>discussion is 
>> even the most general idea what the application is (or applications 
>> are) for these 'options' we are talking about - or even a vague idea 
>> when and where they may apply.
>> 
>> 	I assume - because we're talking about HbH and E2E - that we're 
>> talking about data frames.  Frankly the idea of putting data 
>frames in 
>> jeopardy because some implementation downstream from the ingress 
>> doesn't understand (or chooses to pretend not to understand) 
>an option 
>> is an EXTREMELY powerful argument for NEVER using options - and 
>> certainly not any of the 'critical options' that might provide an 
>> excuse to drop an entire class of frames.  This is - in a very real 
>> way - roughly the same as providing yet another discard eligibility 
>> mechanism since any implementation could decide to discard a frame 
>> containing a 'critical option' - and be justified in doing so.
>> 
>most reasonable 
>> interpretation for 'discard' is 'silent discard'
>> congestion - it is very likely that implementations will not be able 
>> to keep up with at least some processing of 'critical options').
>> 
>intent, then 
>> we're wasting time even talking about it (given the unlikelihood of 
>> there ever being a use for such a thing).
>> 	On the other hand, at least one person seems to interpret this 
>> 'critical  option' indicator as 'must be processed' - which includes 
>> 'process on the slow path' if you don't support doing so on the fast 
>> path.  The distinction - again particularly for data frames - is 
>> minor, given that it will not take long to over-whelm the slow path 
>> with data frames if we start seeing a lot of 'critical 
>options' and it 
>> will then be the case that the implementations not capable of fast 
>> path processing of 'critical options' will have no choice but to 
>> discard them.
>> 
>an application 
>> for 'critical options' that either never, or very rarely - 
>results in 
>> using 'critical options' - but only 'some sense', given the 
>> possibility that we're relying on a behavior that probably cannot be 
>> reliably/deterministically predicted.
>> 
>the answer to 
>> this question - but - what is the point of this discussion (i.e. why 
>> do we need options and why 'critical' vs.
>> 	Based on the discussion so far (and as I have understood it), I 
>> cannot make an informed decision.  All sorts of issues come 
>to mind in 
>> the absence of knowing why we need this...
>> 
>> --
>> Eric Gray
>> Principal Engineer
>> Ericsson
>> 
>> > [[email-masked]] On Behalf Of Radia Perlman
>> > packet. A noncritical option is one that you are allowed to ignore 
>> > and skip over.
>> > 
>> > An alternative is for TRILL to define two bits at the beginning of 
>> > the options (these bits only appear if the options length 
>is greater 
>> > than 0).
>> > 
>> > The two bits are:
>> > the option length is nonzero are those two critical bits. And that 
>> > if you are forwarding an encapsulated
>> data
>> > packet (i.e., you are acting as a transit RBridge for this 
>packet), 
>> > and thost of choice first (hop-by-hop
>> > critical) bit is
>> > The cost of choice A is a bit more complexity, and a bit more 
>> > overhead of forwarding because of having the set the bit.
>> > Hellos for hop-by-hop critical options), support for critical 
>> > there's no way to forward it without the critical option, so we 
>> > don't really need for the receiving RBridge to discard the
>> packet.> . how bad would it be for an RBridge to ignore a critical 
>> option?>

Date: Thu, 13 Dec 2007 10:37:38 -0800
From: Joe Touch <[email-masked]>
To: [email-masked]
Subject: [rbridge] Summary of "critical bits" issues
Status: RO
Content-Length: 2746

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enigD2ED000CCDD21CA48853BC95
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

1. option order

2. option groups

	Hop-by-hop
		examined at all rbridges

	End-to-end

	Discard

	Pass

	Silent

	Noisy

	ALL SILENT, ALL PASS

Joe

--------------enigD2ED000CCDD21CA48853BC95
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

--------------enigD2ED000CCDD21CA48853BC95--

Content-class: urn:content-classes:message
Date: Thu, 13 Dec 2007 10:33:08 -0800
From: "Drake, John E" <[email-masked]>
To: "Eastlake III Donald-LDE008" <[email-masked]>, <[email-masked]>
Subject: Re: [rbridge] Critical bits for options
Status: RO
Content-Length: 4284

Donald,

Thanks,

John

>plane and the data plane.

Date: Thu, 13 Dec 2007 10:07:08 -0500
From: James Carlson <[email-masked]>
To: Eric Gray <[email-masked]>
Cc: [email-masked]
Subject: Re: [rbridge] {Filename?} RE:  Critical bits for options
Status: RO
Content-Length: 2455

Content-class: urn:content-classes:message
Date: Thu, 13 Dec 2007 01:02:46 -0600
From: "Eric Gray" <[email-masked]>
To: "Eastlake III Donald-LDE008" <[email-masked]>, <[email-masked]>
Subject: Re: [rbridge] {Filename?} RE:  Critical bits for options
Status: RO
Content-Length: 20233

Donald,

--
Eric Gray
Principal Engineer
Ericsson  

Very much so.

Precisely.

No.

> @@@ Donald

Date: Wed, 12 Dec 2007 18:26:51 -0800
From: Erik Nordmark <[email-masked]>
To: James Carlson <[email-masked]>
Cc: [email-masked], Radia Perlman <[email-masked]>, Joe Touch <[email-masked]>
Subject: Re: [rbridge] Critical bits for options
Status: RO
Content-Length: 1346

    Erik

Date: Wed, 12 Dec 2007 10:54:20 -0500
From: James Carlson <[email-masked]>
To: Eastlake III Donald-LDE008 <[email-masked]>
Cc: [email-masked]
Subject: Re: [rbridge] Critical Bits Text
Status: RO
Content-Length: 1096

Eastlake III Donald-LDE008 writes:
> Here is an example of some text on critical summary bits cut and pasted
> from an internal version of the protocol document that was never posted:
[...]
>    To ensure backward compatible safe operation, when Op-Length is non-
>    zero, indicating that options are present, the top two bits of the
>    first byte of the options area are specified as follows:
> 
>                       +-----+-----+---+---+---+---+---+---+
>                       | HbH | ItE |       Reserved        |
>                       +-----+-----+---+---+---+---+---+---+

I'm not at all wild about forcing the nodes that manipulate options to
maintain the state of those two bits (particularly the ItE bit) -- it
looks like a good place to have an accident -- but this looks
sufficient, and I think something like it should find its way into the
document.

Content-class: urn:content-classes:message
Date: Wed, 12 Dec 2007 00:28:41 -0500
From: "Eastlake III Donald-LDE008" <[email-masked]>
To: <[email-masked]>
Subject: [rbridge] {Filename?} RE:  Critical bits for options
Status: RO
Content-Length: 12923

This is a multi-part message in MIME format.

------_=_NextPart_001_01C83C7F.DC06ECF5
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Warning: This message has had one or more attachments removed
Warning: (Drafts.xnk).
Warning: Please read the "ISI-4-43-8-Attachment-Warning.txt" attachment(s) =
for more information.

Hi Eric,

See below at @@@

-----Original Message-----
From: Eric Gray [mailto:[email-masked]]=20
Sent: Monday, December 10, 2007 10:45 AM
To: Radia Perlman; Eastlake III Donald-LDE008; [email-masked]
Subject: RE: [rbridge] Critical bits for options

Radia, Donald, et al,

pretend not to understand) an option is an EXTREMELY powerful=20
doing so.=20

reasonable interpretation for 'discard' is 'silent discard'=20

	If that is - in fact - a correct understanding of the=20
intent, then we're wasting time even talking about it (given=20
the unlikelihood of there ever being a use for such a thing).
So that makes me ask: who dreamed this nightmare up and why?

data frames - is minor, given that it will not take long to=20

...

	Based on the discussion so far (and as I have understood
it), I cannot make an informed decision.  All sorts of issues=20
come to mind in the absence of knowing why we need this...

@@@ Thanks,
@@@ Donald

--
Eric Gray
Principal Engineer
Ericsson=20=20

> From: [email-masked]=20
>=20
> I'd like to make sure the decision about whether to define=20
> critical bits=20
>=20
> Currently the TRILL spec says to ignore all options -- the only thing=20
>=20
> A "critical" option (some people call it "mandatory") is an=20
> option that=20
> the packet. A noncritical option is one that you are allowed=20
> to ignore=20
> and skip over.
>=20
> The way the spec is now precludes critical options, because RBridges=20
>=20
> An alternative is for TRILL to define two bits at the=20
> beginning of the=20
>=20
>=20
> If we define these bits, then an egress RBridge MUST look to see if=20
> A transit RBridge MUST look to see if the hop-by-hop bit is=20
> set, and if=20
> Though I suppose an RBridge that doesn't support ANY critical options=20
> option that it should drop the packet, without having to=20
> parse to find=20
> the critical option.
>=20
> So, our choices as a WG:
>=20
> Choice A: Define NOW that the first 2 bits in the option=20
> portion, if the=20
> critical bits. And that if you are forwarding an encapsulated data=20
> for this packet), and thost of choice first (hop-by-hop=20
> critical) bit is=20
> RBridge, and either of the first two bits are set, you MUST=20
> drop the packet.
>=20
>=20
> The cost of choice A is a bit more complexity, and a bit more=20
> overhead=20
>=20
> . how likely is it that we'd ever need critical options? Can=20
> we imagine=20
> . we could support such things by using a new version TRILL=20
> header when=20
> . we could advertise (in LSPs for end-to-end critical=20
> options, in Hellos=20
> options, and the previous hop RBridge can throw the packet away if=20
>=20
>=20

------_=_NextPart_001_01C83C7F.DC06ECF5
Content-Type: text/plain; charset="ISO-8859-1";
	name="ISI-4-43-8-Attachment-Warning.txt"
Content-Disposition: inline; filename="ISI-4-43-8-Attachment-Warning.txt"
Content-Transfer-Encoding: quoted-printable

Virus scanner report for Tue Dec 11 21:28:53 2007:
   MailScanner: Microsoft Exchange Shortcuts are dangerous in email (Drafts=
.xnk)

Quarantine location:  4-43-8 /var/spool/quarantine/20071211 (message lBC5Sm=
1J022982).

Thank you,

IPC Computing Services

------_=_NextPart_001_01C83C7F.DC06ECF5--

Date: Wed, 12 Dec 2007 11:45:47 +0800
From: [email-masked]
To: Eric Gray <[email-masked]>
Priority: normal
Cc: [email-masked]
Subject: Re: [rbridge] Critical bits for options
Status: RO
Content-Length: 8169

(using a "please limit your internet to 10 minutes" machine at the conference, so hopefully I've not misinterpreted
the email).

Eric -- I very much sympathize with your email. In an earlier version of the spec, Don had a couple of pages
defining options formats, and I thought it was just too complicated, since I didn't think we'd ever use options,
and I've never liked "critical" options.

However, he did tell me some examples of options. We could always not have options, and only allow them with
the next version header, but here are some examples:
a) a "customer ID" that you want transit RBridges to just ignore, but will be useful for ingress and egress RBridges.
b) a way of compressing the data packet, that you should be careful that your upstream guy knows how to do
before you send it, but it's safer to make it critical so in case you accidentally send it to him he won't misparse it
c) cryptographic protection (again, should be critical so someone doesn't try to interpret an encrypted packet).

So he won me over and convinced me that at some point we might want to allow all 4 types of options (critical/not,
EtE, ItE).

Radia

----- Original Message -----
From: Eric Gray <[email-masked]>
Date: Monday, December 10, 2007 11:44 pm
Subject: Re: [rbridge] Critical bits for options

> > [[email-masked]] On Behalf Of Radia Perlman
> > we don't really need for the receiving RBridge to discard the 
> packet.> . how bad would it be for an RBridge to ignore a critical 
> option?> 

Content-class: urn:content-classes:message
Date: Tue, 11 Dec 2007 16:26:51 -0500
From: "Eastlake III Donald-LDE008" <[email-masked]>
To: <[email-masked]>
Subject: Re: [rbridge] Critical bits for options
Status: RO
Content-Length: 2741

Hi John,

Thanks,
Donald 

-----Original Message-----

Eric,

Thanks,
John 

Content-class: urn:content-classes:message
Date: Tue, 11 Dec 2007 14:44:27 -0600
From: "Eric Gray" <[email-masked]>
To: "Eastlake III Donald-LDE008" <[email-masked]>, "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] Orphaned endnodes with partitioned VLANs on a cloud
Status: RO
Content-Length: 9784

Donald,

	Unfortunately, I have to pack my computer for a trip and
cannot go into too mych detail right now, but I would like to 
make just a few short comments on this thread.

	Please see a few comments in-line below...

--
Eric Gray
Principal Engineer
Ericsson  

> Sent: Monday, December 10, 2007 10:44 PM
> To: Developing a hybrid router/bridge.
> Subject: Re: [rbridge] Orphaned endnodes with partitioned 
> VLANs on a cloud
> 
> Hi Russ,
> 
> See below at @@@
> 
> [mailto:[email-masked]] On
> Behalf Of Russ White
> Sent: Sunday, December 09, 2007 2:27 PM
> To: [email-masked]
> Cc: Developing a hybrid router/bridge.
> Subject: Re: [rbridge] Orphaned endnodes with partitioned VLANs on a
> cloud
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> > Russ, I think a way of thinking about it that might be clearer is
> > first to pretend there are no VLANs.
> > We want there to be just a single RBridge that forwards traffic
> > to/from the link. 
> 
> What you're talking about here is edge ports, though, not links in the
> middle of the cloud--I think there's a radical difference between the
> two. The edge case can be solved more easily than what you describe
> below--I'm waiting on some validation from some other folks before
> sending out a list of ideas to the list.
> 
> As for the link in the cloud, I don't think this is a case that we
> should worry about.
> 
> @@@ First, I think Rbridges should work for general topologies. 
>	Second, our charter speaks of incrementally deployablity. 
>	You may be incrementally deploying Rbridges into what was a
>	bridged network. You could eventually end up with all Rbridges. 
>	But many intermediate states would have bridged LANs between
>	the Rbridges. Some phrases extracted from our charter: 
>	"... arbitrary topologies ... ensure that the solution can 
>	interwork with bridges in a flexible manner ... incremental
> 	deployment into LANs ...". 
>	So I think we do need to worry about that case, although I 
>	don't see anything wrong with being able to configure a link 
>	to be a point-to-point link between Rbridges, provided you also
>	include some reasonable sanity checks so if you receive frames
>	inconsistent with the link being a direct point-to-point 
>	connection between Rbridges you will notice and take appropriate

>	action.

Yes, ID is a goal.  The current specification is less than adequate
in this respect.  Significantly.

> 
> > But anyway, now let's look at VLANs on the link. Because of bridges,
> > any VLAN might be partitioned with respect to data traffic, for 
> > various reasons.  The WG discussed this at length, and it looked to
> > me, and I strongly agree with this -- that TRILL should consider
> > partitioned VLANs on a link as a misconfiguration, and should
> > make sure they are defensive against it (not creating loops), but
> > should not worry about healing all the partitions.

This is a departure from the intuitive (and common use) meaning of
the term "virtual LAN" in that this assumption does not hold true 
for the current specification if I replace VLAN with LAN.  In that
case, I would expect the fact that there may be multiple RBridges
with access to a LAN segment to "heal" a partition - simply because
they could no longer be neighbors with respect to that LAN and this
would trigger a DRB election and HEAL the LAN.

The same thing MUST be true for any VLAN.

> 
> The current proposal heals partitioned VLANs, from what I understand
> of it, intentionally--at least on the links in the cloud. This is what
> I specifically think we should avoid doing.
> 
> @@@ It's not that simple. Healing partitioned VLANs can mean 
>	two things:
>	partitioned on a link or 
>	partitioned between different links, where "link" may be a 
>	bridged LAN.
> 
> @@@ The current proposal does not heal a VLAN that is partitioned 
>	on a single link. As far as I know, that could only happen due 
>	to the link being a bridged LAN and the bridge or bridges within

>	it being configured to partition the VLAN. Since, for
simplicity, 
>	there is only one Rbridge forwarding on-to/off-of the link for 
>	any particular VLAN, such a partitioning is considered a 
>	misconfiguration and can result in orphaned nodes.

Wrong.  In the example I gave, partitioning occurs because of a bridge
failure.  One or more link failures would have the same effect.

> 
> @@@ The current proposal does heal a VLAN that is partitioned between
> 	different links.  That is, the incremental deployment of
Rbridges 
>	may cause what were separate islands of a VLAN in a bridged 
>	network to become connected. The original existence of such 
>	islands can also be considered a misconfiguration or at least a 
>	violation of the spirit of 802.1Q, although I'm sure you can
find 
>	those who would dispute this view. This island interconnection 
>	just happens automatically because of the global view Rbridges 
>	have through the link state database. It would require more 
>	complexity and configuration to keep such islands separate.
>	 Since Rbridges are routing on VLAN ID and MAC address, how
would 
>	they be supposed to know there are supposed to be two separate 
>	islands of VLAN X? Seems like you would need to extend the VLAN 
>	ID with an island ID or something. Given Rbridges are required
by 
>	our charter to be able to capable of operating with "Minimal or 
>	no configuration" the WG has thus far decided not to go with
such 
>	"VLAN island IDs" or any similar mechanism, which in any case 
>	would only work with extra configuration and be more complex.
> 
> @@@ If a bridged LAN link between Rbridges is misconfigured to 
>	partition a VLAN, it isn't healed because to do so would make 
>	things more complex and less safe. And if a VLAN is partitioned 
>	between separate links that connect to Rbridges, it is healed 
>	because to not do so would make things more complex and would 
>	require additional configuration.

This is because you assume a model for VLAN interactions that is 
different from the model that necessarily applies for LANs.

In fact, the ideal model would not differ and the realizable model
only differs by the fact that VLANs must be grouped to share a
spanning tree (because of the scalability limitation in MSTP).

> 
> @@@ None of these questions arise, of course, in an all Rbridge LAN 
>	or one where any remaining bridges are configured to provide
VLAN
>	connectivity.
> 
> Let's begin with this: rbridges don't care about the state of 
> the links between rbridges, they only care to solve possible loops 
> for edge ports.
> 
> @@@ As above, Rbridges must consider the case where the links between
> 	Rbridges are bridged LANs. Also, it is my impression that a
number 
>	of TRILL WG members consider loops to be so harmful that
Rbridges 
>	need to take reasonable precautions against them everywhere, not

>	just on "edge" ports, whatever you consider such ports to be. So
I 
>	don't see how we can begin where you suggest we begin.
> 
> > The RBridges have to stick some VLAN tag on packets when they
> > talk to each other.  
> 
> Actually, the don't, from what I understand. They could talk native on
> the media, or they could use a vlan, depend on how they're configured.
> 
> @@@ Well, they could emit untagged TRILL frames. Note that you are 
>	using the word "native" in a different way that it is used in 
>	the TRILL WG and protocol document. Here "native" currently
means 
>	any data frame that isn't encapsulated with the TRILL Ethertype,

>	as opposed to a TRILL frame which does have the TRILL Ethertype 
>	encapsulation. Whether or not the frame is VLAN tagged is 
>	orthogonal to whether or not it is native in this sense.
> 
> @@@ Also, assuming an 802.1Q sort of network, conformant with 
> 	Annex E of 802.1Q-2005, then I think it is reasonable to think
of 
>	all frames, whether they are VLAN tagged or not, as being in/on
a 
>	particular VLAN.
>	It is certainly the case that data frames inside an 802.1Q 
> 	bridge always have a VLAN ID associated with them. If the frame 
>	was untagged on the wire but was admitted, then the port through

>	which it was admitted associated a VLAN ID with that frame. And,

>	if the network is Annex E conformant, all ports attached to that

>	wire which will admit untagged frames are required to be 
>	configured so as to associate the same VLAN ID with the frame. 
>	So it might be reasonable to consider the frame to be in
> 	that VLAN even when it is transiting untagged on the wire.
> 
> ...
> 
> > Personally, I think we should leave the spec the way it is. It was a
> > careful balancing act between overhead and safety, plus supporting 
> > features such as load splitting based on VLANs.
> 
> The problems with the current mechanism are:
> 
> 1. It doesn't solve what it was intended to solve.
> 
> @@@ I think it does a reasonable job of solving the problem it was
> 	intended to solve: "... a solution for shortest-path frame
>	routing in multi-hop IEEE 802.1-compliant Ethernet networks with

>	arbitrary topology ..." I think that, when combined with the 
>	incremental deployment requirement, necessitates consideration 
>	of intervening bridges.
> 
> 2. When it does work, it has unintended side effects.
> 
> @@@ How is anyone supposed to know what side effects you are talking
>	about?
> 
> ...
> 
> @@@ Thanks,
> @@@ Donald
> 
> Russ
> 
> - --

Content-class: urn:content-classes:message
Date: Tue, 11 Dec 2007 14:09:49 -0600
From: "Eric Gray" <[email-masked]>
To: "Eastlake III Donald-LDE008" <[email-masked]>, "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] Orphaned endnodes with partitioned VLANs on a cloud
Status: RO
Content-Length: 3377

Donald,

	See some amplifcations below...

Thanks!

--
Eric Gray
Principal Engineer
Ericsson  

> Sent: Monday, December 10, 2007 10:58 PM
> To: Developing a hybrid router/bridge.
> Subject: Re: [rbridge] Orphaned endnodes with partitioned 
> VLANs on a cloud
> 
> 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.

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

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

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

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

Content-class: urn:content-classes:message
Date: Mon, 10 Dec 2007 22:57:56 -0500
From: "Eastlake III Donald-LDE008" <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] Orphaned endnodes with partitioned VLANs on a cloud
Status: RO
Content-Length: 1984

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

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

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

- --

Content-class: urn:content-classes:message
Date: Mon, 10 Dec 2007 22:44:15 -0500
From: "Eastlake III Donald-LDE008" <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] Orphaned endnodes with partitioned VLANs on a cloud
Status: RO
Content-Length: 7560

Hi Russ,

See below at @@@

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Russ White
Sent: Sunday, December 09, 2007 2:27 PM
To: [email-masked]
Cc: Developing a hybrid router/bridge.
Subject: Re: [rbridge] Orphaned endnodes with partitioned VLANs on a
cloud

> Russ, I think a way of thinking about it that might be clearer is
first to pretend there are no VLANs.
> We want there to be just a single RBridge that forwards traffic
to/from the link. 

What you're talking about here is edge ports, though, not links in the
middle of the cloud--I think there's a radical difference between the
two. The edge case can be solved more easily than what you describe
below--I'm waiting on some validation from some other folks before
sending out a list of ideas to the list.

As for the link in the cloud, I don't think this is a case that we
should worry about.

@@@ First, I think Rbridges should work for general topologies. Second,
our charter speaks of incrementally deployablity. You may be
incrementally deploying Rbridges into what was a bridged network. You
could eventually end up with all Rbridges. But many intermediate states
would have bridged LANs between the Rbridges. Some phrases extracted
from our charter: "... arbitrary topologies ... ensure that the solution
can interwork with bridges in a flexible manner ... incremental
deployment into LANs ...". So I think we do need to worry about that
case, although I don't see anything wrong with being able to configure a
link to be a point-to-point link between Rbridges, provided you also
include some reasonable sanity checks so if you receive frames
inconsistent with the link being a direct point-to-point connection
between Rbridges you will notice and take appropriate action.

> But anyway, now let's look at VLANs on the link. Because of bridges,
any VLAN might be partitioned with
> respect to data traffic, for various reasons.  The WG discussed this
at length, and it looked to me, and I strongly
> agree with this -- that TRILL should consider partitioned VLANs on a
link as a misconfiguration, and should
> make sure they are defensive against it (not creating loops), but
should not worry about healing
> all the partitions.

The current proposal heals partitioned VLANs, from what I understand of
it, intentionally--at least on the links in the cloud. This is what I
specifically think we should avoid doing.

@@@ It's not that simple. Healing partitioned VLANs can mean two things:
partitioned on a link or partitioned between different links, where
"link" may be a bridged LAN.

@@@ The current proposal does not heal a VLAN that is partitioned on a
single link. As far as I know, that could only happen due to the link
being a bridged LAN and the bridge or bridges within it being configured
to partition the VLAN. Since, for simplicity, there is only one Rbridge
forwarding on-to/off-of the link for any particular VLAN, such a
partitioning is considered a misconfiguration and can result in orphaned
nodes.

@@@ The current proposal does heal a VLAN that is partitioned between
different links.  That is, the incremental deployment of Rbridges may
cause what were separate islands of a VLAN in a bridged network to
become connected. The original existence of such islands can also be
considered a misconfiguration or at least a violation of the spirit of
802.1Q, although I'm sure you can find those who would dispute this
view. This island interconnection just happens automatically because of
the global view Rbridges have through the link state database. It would
require more complexity and configuration to keep such islands separate.
Since Rbridges are routing on VLAN ID and MAC address, how would they be
supposed to know there are supposed to be two separate islands of VLAN
X? Seems like you would need to extend the VLAN ID with an island ID or
something. Given Rbridges are required by our charter to be able to
capable of operating with "Minimal or no configuration" the WG has thus
far decided not to go with such "VLAN island IDs" or any similar
mechanism, which in any case would only work with extra configuration
and be more complex.

@@@ If a bridged LAN link between Rbridges is misconfigured to partition
a VLAN, it isn't healed because to do so would make things more complex
and less safe. And if a VLAN is partitioned between separate links that
connect to Rbridges, it is healed because to not do so would make things
more complex and would require additional configuration.

@@@ None of these questions arise, of course, in an all Rbridge LAN or
one where any remaining bridges are configured to provide VLAN
connectivity.

Let's begin with this: rbridges don't care about the state of the links
between rbridges, they only care to solve possible loops for edge ports.

@@@ As above, Rbridges must consider the case where the links between
Rbridges are bridged LANs. Also, it is my impression that a number of
TRILL WG members consider loops to be so harmful that Rbridges need to
take reasonable precautions against them everywhere, not just on "edge"
ports, whatever you consider such ports to be. So I don't see how we can
begin where you suggest we begin.

> The RBridges have to stick some VLAN tag on packets when they
> talk to each other.  

Actually, the don't, from what I understand. They could talk native on
the media, or they could use a vlan, depend on how they're configured.

@@@ Well, they could emit untagged TRILL frames. Note that you are using
the word "native" in a different way that it is used in the TRILL WG and
protocol document. Here "native" currently means any data frame that
isn't encapsulated with the TRILL Ethertype, as opposed to a TRILL frame
which does have the TRILL Ethertype encapsulation. Whether or not the
frame is VLAN tagged is orthogonal to whether or not it is native in
this sense.

@@@ Also, assuming an 802.1Q sort of network, conformant with Annex E of
802.1Q-2005, then I think it is reasonable to think of all frames,
whether they are VLAN tagged or not, as being in/on a particular VLAN.
It is certainly the case that data frames inside an 802.1Q bridge always
have a VLAN ID associated with them. If the frame was untagged on the
wire but was admitted, then the port through which it was admitted
associated a VLAN ID with that frame. And, if the network is Annex E
conformant, all ports attached to that wire which will admit untagged
frames are required to be configured so as to associate the same VLAN ID
with the frame. So it might be reasonable to consider the frame to be in
that VLAN even when it is transiting untagged on the wire.

...

> Personally, I think we should leave the spec the way it is. It was a
careful balancing act between overhead and
> safety, plus supporting features such as load splitting based on
VLANs.

The problems with the current mechanism are:

1. It doesn't solve what it was intended to solve.

@@@ I think it does a reasonable job of solving the problem it was
intended to solve: "... a solution for shortest-path frame routing in
multi-hop IEEE 802.1-compliant Ethernet networks with arbitrary topology
..." I think that, when combined with the incremental deployment
requirement, necessitates consideration of intervening bridges.

2. When it does work, it has unintended side effects.

@@@ How is anyone supposed to know what side effects you are talking
about?

...

@@@ Thanks,
@@@ Donald

Russ

- --

Content-class: urn:content-classes:message
Date: Mon, 10 Dec 2007 15:01:56 -0800
From: "Drake, John E" <[email-masked]>
To: <[email-masked]>
Subject: Re: [rbridge] Critical bits for options
Status: RO
Content-Length: 7159

Eric,

Thanks,

John 

>of issues come to mind in the absence of knowing why we need this...

Content-class: urn:content-classes:message
Date: Mon, 10 Dec 2007 09:44:50 -0600
From: "Eric Gray" <[email-masked]>
To: "Radia Perlman" <[email-masked]>, "Eastlake III Donald-LDE008" <[email-masked]>, <[email-masked]>
Subject: Re: [rbridge] Critical bits for options
Status: RO
Content-Length: 6381

Radia, Donald, et al,

--
Eric Gray
Principal Engineer
Ericsson  

> So...what do people think?

Date: Mon, 10 Dec 2007 07:14:17 -0800
From: Joe Touch <[email-masked]>
To: Eric Gray <[email-masked]>
Cc: "Developing a hybrid router/bridge." <[email-masked]>, Radia Perlman <[email-masked]>
Subject: Re: [rbridge] Orphaned endnodes with partitioned VLANs on a cloud
Status: RO
Content-Length: 15140

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enigA82B9F7AB26139323613B456
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

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=
=2E

Joe (list admin)

Eric Gray wrote:
> By the way, there is definitely something wrong with the mailing
> list.  The mail below was not received until 12 hours after it=20
> 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.
>=20
> Is it possible to determine what is causing the posting delay?
>=20
> --
> Eric Gray
> Principal Engineer
> Ericsson =20
>=20
>> From: [email-masked]=20
>> [mailto:[email-masked]] On Behalf Of Eric Gray
>> Sent: Thursday, December 06, 2007 9:53 PM
>> To: Anoop Ghanwani; Radia Perlman
>> Cc: Developing a hybrid router/bridge.
>> Subject: Re: [rbridge] Orphaned endnodes with partitioned=20
>> VLANs on a cloud
>>
>> 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,=20
>> 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=20
>> is that there are two VLANs (A and B) that are being routed in=20
>> some special way (shown in the diagram) and an arbitrary number=20
>> of VLANs (but necessarily at least 1 and not more than 4092) of=20
>> other VLANs that are also present in the network (as shown - and=20
>> described - in my diagram).
>>
>> --
>> Eric Gray
>> Principal Engineer
>> Ericsson =20
>>
>>> From: Anoop Ghanwani [mailto:[email-masked]]=20
>>> Sent: Thursday, December 06, 2007 9:33 PM
>>> To: Eric Gray; Radia Perlman
>>> Cc: Developing a hybrid router/bridge.
>>> Subject: RE: [rbridge] Orphaned endnodes with partitioned=20
>>> VLANs on a cloud
>>> Importance: High
>>>
>>>
>>> (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=20
>>> MVRP.
>>>
>>> Anoop=20
>>>
>>>> From: Eric Gray [mailto:[email-masked]]=20
>>>> Sent: Wednesday, December 05, 2007 2:25 PM
>>>> To: Anoop Ghanwani; Radia Perlman
>>>> Cc: Developing a hybrid router/bridge.
>>>> Subject: RE: [rbridge] Orphaned endnodes with partitioned=20
>>>> VLANs on a cloud
>>>>
>>>> Anoop/Radia,
>>>>
>>>> 	This is not exactly the note on which we left off in=20
>>>> the off-line discussion.  As I recall (isn't E-Mail great!),=20
>>>> I replied to this with the following:
>>>>
>>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>>>> 	If the RBridges were inserted to replace 802.1Q=20
>>>> bridges, and each was configured as I've described for access=20
>>>> to both VLAN A and B, then the bridge failure I described=20
>>>> would simply result in a different spanning tree for VLAN A. =20
>>>> VLAN A would not be broken, it would simply be (potentially)=20
>>>> less optimal.
>>>> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>>>>
>>>> 	This was specifically in response to your comment (to=20
>>>> the effect that this wouldn't have worked in an 802.1Q LAN -=20
>>>> so it would have been a misconfiguration there as well).
>>>>
>>>> 	In response to the above observation you said that you=20
>>>> agreed that this would not have been a misconfiguration error=20
>>>> in that case.  Aactually, what you said exactly was "Yes, you=20
>>>> are right."
>>>>
>>>> 	More on this in a separate mail message response to Radia...
>>>>
>>>> Thanks!
>>>>
>>>> --
>>>> Eric Gray
>>>> Principal Engineer
>>>> Ericsson =20
>>>>
>>>>> From: Anoop Ghanwani [mailto:[email-masked]]
>>>>> Sent: Tuesday, December 04, 2007 11:27 PM
>>>>> To: Radia Perlman; Eric Gray
>>>>> Cc: Developing a hybrid router/bridge.
>>>>> Subject: RE: [rbridge] Orphaned endnodes with partitioned=20
>>>> VLANs on a=20
>>>>> cloud
>>>>> Importance: High
>>>>>
>>>>>
>>>>> Radia,
>>>>>
>>>>> This is what I told Eric during the offline discussion as=20
>>>> well - that=20
>>>>> this is a misconfiguration and as long as bad things aren't=20
>>>> happening,=20
>>>>> it's up to the administrator to configure things so that=20
>>> they work=20
>>>>> correctly when such failures happen.
>>>>>
>>>>> It is no worse than what can happen in a misconfigured bridged=20
>>>>> network.
>>>>>
>>>>> Anoop
>>>>>
>>>>>> Sent: Tuesday, December 04, 2007 7:15 PM
>>>>>> To: Eric Gray
>>>>>> Cc: Developing a hybrid router/bridge.
>>>>>> Subject: [rbridge] Orphaned endnodes with partitioned VLANs
>>>>> on a cloud
>>>>>> Putting in a subject line since Eric didn't.
>>>>>>
>>>>>> To restate Eric's concern -- it is possible that VLAN A=20
>>> might be=20
>>>>>> partitioned on a link, and since the DRB selects only=20
>> a single=20
>>>>>> VLAN-A-forwarder, some VLAN A endnodes on the cloud might get=20
>>>>>> orphaned (since they are on the other side of the=20
>>>> partition from the=20
>>>>>> appointed VLAN A forwarder on the link).
>>>>>>
>>>>>> And that is correct.
>>>>>>
>>>>>> So, what is the alternative? Everything is an engineering=20
>>>> tradeoff.
>>>>>> We could run DRB elections on every possible VLAN, and with a=20
>>>>>> partitioned VLAN, wind up with multiple DRBs for that VLAN.
>>>>>> If there were n VLANs, we'd wind up with n DRBs (one=20
>>> per VLAN), n=20
>>>>>> pseudonodes, n times as many Hello messages, etc.
>>>>>>
>>>>>> We chose to consider a partiitoned VLAN, caused by bridges=20
>>>>>> configured to not pass data traffic for a particular=20
>> VLAN, as a=20
>>>>>> misonfiguration. This can happen with bridges anyway, if=20
>>>> you mark a=20
>>>>>> bunch of your potential through links as not being=20
>>>> allowed for VLAN=20
>>>>>> A transit. The solution in the current spec is low=20
>>>> overhead (at most=20
>>>>>> one pseudonode per link, one Hello per RBridge except for=20
>>>> the DRB)=20
>>>>>> and relatively simple.
>>>>>> Hopefully eventually more bridges will be replaced by=20
>>>> RBridges and=20
>>>>>> this sort of thing won't happen.
>>>>>>
>>>>>> Radia
>>>>>>
>>>>>>
>>>>>> Eric Gray wrote:
>>>>>>> Folks,
>>>>>>>
>>>>>>> 	Here is the problem that occurs when VLAN state is
>>>>>> inferred for one
>>>>>>> VLAN from connectivity provided by another.  This is=20
>>> a general=20
>>>>>>> problem, but has specific applicability to the=20
>> current set of=20
>>>>>>> assumptions used in the protocol specification.  This=20
>>>> came up in=20
>>>>>>> off-line discussions with Anoop Ghanwani (and others)=20
>>>> at an IEEE=20
>>>>>>> meeting a couple of weeks ago.
>>>>>>>
>>>>>>> 	A key thing to understand in looking at this=20
>>>> problem is it is a=20
>>>>>>> comparison between how a network works with 802.1Q
>>>>> bridges and the
>>>>>>> same network after some 802.1Q bridges have been=20
>>> replaced with=20
>>>>>>> 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 _)
>>>>>>>                       (_   _)
>>>>>>>                         (_)
>>>>>>> =20
>>>>>>> 	In this figure, B-1, B-2 and B-3 are=20
>>>> aggregation bridges with=20
>>>>>>> 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).
>>>>>>> =20
>>>>>>> 	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=20
>> 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.
>>>>>>> =20
>>>>>>> 	If bridge B-4 fails, then VLAN A would be=20
>>>> segmented, at least=20
>>>>>>> temporarily.  Hellos continue to work, however, so the 2
>>>>>> RBridges do
>>>>>>> not discover the partition and the DRB election remains=20
>>>> 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=20
>>>> be for the=20
>>>>>>> RBridges to discover the partition and redo the DRB
>>>>>> election - making
>>>>>>> RB-1 the DRB for one partition and RB-2 the DRB for=20
>> the other=20
>>>>>>> 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=20
>>> will have=20
>>>>>>> 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
>>>>>>>
>>>>>>>  =20
>=20

--------------enigA82B9F7AB26139323613B456
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

--------------enigA82B9F7AB26139323613B456--

Content-class: urn:content-classes:message
Date: Mon, 10 Dec 2007 08:42:08 -0600
From: "Eric Gray" <[email-masked]>
To: "Eric Gray" <[email-masked]>, "Anoop Ghanwani" <[email-masked]>, "Radia Perlman" <[email-masked]>
Cc: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] Orphaned endnodes with partitioned VLANs on a cloud
Status: RO
Content-Length: 14116

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
> To: Anoop Ghanwani; Radia Perlman
> Cc: Developing a hybrid router/bridge.
> Subject: Re: [rbridge] Orphaned endnodes with partitioned 
> VLANs on a cloud
> 
> 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
> > Cc: Developing a hybrid router/bridge.
> > Subject: RE: [rbridge] Orphaned endnodes with partitioned 
> > VLANs on a cloud
> > Importance: High
> > 
> > 
> > (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 
> > 
> > > Sent: Wednesday, December 05, 2007 2:25 PM
> > > To: Anoop Ghanwani; Radia Perlman
> > > Cc: Developing a hybrid router/bridge.
> > > Subject: RE: [rbridge] Orphaned endnodes with partitioned 
> > > VLANs on a cloud
> > > 
> > > 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
> > > > Cc: Developing a hybrid router/bridge.
> > > > 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
> > > > 
> > > > > Sent: Tuesday, December 04, 2007 7:15 PM
> > > > > To: Eric Gray
> > > > > Cc: Developing a hybrid router/bridge.
> > > > > Subject: [rbridge] Orphaned endnodes with partitioned VLANs
> > > > on a cloud
> > > > > 
> > > > > 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
> > > > > 
> > > > > 
> > > > > Eric Gray wrote:
> > > > > > 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
> > > > > >

Date: Sun, 09 Dec 2007 14:27:22 -0500
From: Russ White <[email-masked]>
To: [email-masked]
Cc: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] Orphaned endnodes with partitioned VLANs on a cloud
Status: RO
Content-Length: 3571

> Russ, I think a way of thinking about it that might be clearer is first to pretend there are no VLANs.
> We want there to be just a single RBridge that forwards traffic to/from the link. 

What you're talking about here is edge ports, though, not links in the
middle of the cloud--I think there's a radical difference between the
two. The edge case can be solved more easily than what you describe
below--I'm waiting on some validation from some other folks before
sending out a list of ideas to the list.

As for the link in the cloud, I don't think this is a case that we
should worry about.

> But anyway, now let's look at VLANs on the link. Because of bridges, any VLAN might be partitioned with
> respect to data traffic, for various reasons.  The WG discussed this at length, and it looked to me, and I strongly
> agree with this -- that TRILL should consider partitioned VLANs on a link as a misconfiguration, and should
> make sure they are defensive against it (not creating loops), but should not worry about healing
> all the partitions.

The current proposal heals partitioned VLANs, from what I understand of
it, intentionally--at least on the links in the cloud. This is what I
specifically think we should avoid doing.

Let's begin with this: rbridges don't care about the state of the links
between rbridges, they only care to solve possible loops for edge ports.

> The RBridges have to stick some VLAN tag on packets when they
> talk to each other.  

Actually, the don't, from what I understand. They could talk native on
the media, or they could use a vlan, depend on how they're configured.

> a) Hellos on every possible VLAN by every RBridge. DRB elections on each possible VLAN. Different pseudonodes per link for each
> possible VLAN (with some attempt to consolidate when possible). Not being able to be conservative about loops
> (since the "report the root bridge" will not work). Multicast traffic might traverse the traffic multiple times (because
> each pseudonode is logically a different node in the topology).

> b) DRB sends lots of Hellos (to be as robust as possible about preventing multiple forwarders within the cloud,
> although if that doesn't work, the next level of safety -- seeing the root bridge in the LSP), but all other RBridges
> just send a single Hello. Single pseudonode. Only downside -- if the cloud is configured to have a particular VLAN
> partitioned, then endnodes get orphaned.

There are a number of other options, but again, I'm waiting on someone
else to look at them before sending them to the list.

> Personally, I think we should leave the spec the way it is. It was a careful balancing act between overhead and
> safety, plus supporting features such as load splitting based on VLANs.

The problems with the current mechanism are:

1. It doesn't solve what it was intended to solve.
2. When it does work, it has unintended side effects.

Again, things are much too mixed up right now--solve one problem, and
one problem, only. Ignore links between rbridges that are designed to be
host free, or transit only. Only worry about edge ports. Don't worry
about misconfigurations, in terms of trying to find a path when
something is misconfigured, etc.

:-)

Russ

- --

Date: Sun, 09 Dec 2007 13:06:25 +0800
From: [email-masked]
To: Eastlake III Donald-LDE008 <[email-masked]>
Priority: normal
Cc: [email-masked]
Subject: Re: [rbridge] Critical Bits Text
Status: RO
Content-Length: 3315

I'm OK with that text. I'm not convinced about the text after =====, which is just a note in the email to the WG
I assume, and not proposed as going into the protocol spec.

I assume what you are thinking about is if the top bit of each option was
the "critical bit", then it would naturally appear as the first bit there anyway.
Howevder, I'd assume that we'd need first a "length of HbH options" header, and
the critical ItE bit would certainly not naturally appear as the 2nd bit if we were really to
define all the options at this point. It's a "summary" bit. So I can imagine some people arguing instead
to completely define the options at this point.

If we leave it as having the two bits where you said, then we might wind up ultimately with a different
format than if we really thought through EtE and ItE critical and noncritical options, but I'm fine with
having the summary bits upfront. It does certainly optimize processing for RBridges that support no options.

Radia

----- Original Message -----
From: Eastlake III Donald-LDE008 <[email-masked]>
Date: Sunday, December 9, 2007 6:59 am
Subject: [rbridge] Critical Bits Text

> Here is an example of some text on critical summary bits cut and 
> pastedfrom an internal version of the protocol document that was 
> never posted:
> 
> In the subpart of Section 3 on options:
> 
> 
> =======================================================================
>   To ensure backward compatible safe operation, when Op-Length is 
> non-
>   zero, indicating that options are present, the top two bits of the
>   first byte of the options area are specified as follows:
> 
>                      +-----+-----+---+---+---+---+---+---+
>                      | HbH | ItE |       Reserved        |
>                      +-----+-----+---+---+---+---+---+---+
> 
>                 Figure 6. Options Area Initial Flags Byte
> 
>   If the HbH bit is one, one or more critical hop-by-hop options are
>   present so, for example, transit RBridges that support no options
>   MUST drop the frame. If the HbH bit is zero, the frame is safe, 
> from   the point of view of options, for a transit RBridge. A transit
>   RBridge that supports no options and forwards a frame MUST
>   transparently forward the options present.
> 
>   If the ItE bit is a one, one or more critical ingress-to-egress
>   options are present. If it is zero, no such options are 
> present.  If
>   either HbH or ItE is non-zero, egress RBridges that support no
>   options MUST drop the frame.  If both HbH and ItE are zero, the 
> frame   is safe, from the point of view of options, for any egress 
> RBridge to
>   process.
> 
> 
> =======================================================================
> It is the case the if the options format is definite so that the 
> top bit
> of the first byte of the option indicates it is a critical hop-by-hop
> option and the options are ordered so that such options have to appear
> first, then at least transit Rbridges that support no options 
> would be
> checking exactly the same bit regardless of whether these summary bits
> were present or not.
> 
> Thanks,
> Donald
> 

Date: Sun, 09 Dec 2007 12:53:29 +0800
From: [email-masked]
To: Russ White <[email-masked]>
Priority: normal
Cc: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] Orphaned endnodes with partitioned VLANs on a cloud
Status: RO
Content-Length: 5736

Russ, I think a way of thinking about it that might be clearer is first to pretend there are no VLANs.
We want there to be just a single RBridge that forwards traffic to/from the link. 

Let's say that there are two RBridges, RB1, and RB2 that both think they should forward traffic to/from
the link, not realizing they are both connected to the same link (because bridges are blocking the data
traffic for some reason, or because there is so much congestion that they are not hearing each other's
IS-IS Hello messages).

RB1 encapsulates a multicast packet off the link. It arrives at all RBridges, including RB2. RB2 decapsulates it
(including losing the TTL), and forwards it on the link. RB1 sees it as a brand new packet, encapsulates it and
forwards it into the campus...and so forth.

The original design was a bit easier to understand -- where just the DRB forwarded traffic to/from the link
on behalf of all VLANs. The VLAN tag was only a way of keeping endnodes separated from each other, as
opposed to a policy decision on inter-RBridge links. The WG concluded that it is simpler and more robust
to assume that all inter-RBridge links are allowed to forward traffic on behalf of all VLANs, and if anyone
wants anything fancier than that, they can use all the traffic engineering that layer 3 people have years of
experience with, to move different types of traffic (whether it be based on VLAN, or deeper inspection into
the packet).

The extra thing -- load splitting -- seems to have been confusing some people, but it works if there is a single
RB forwarding traffic from a particular link on behalf of a VLAN.

But anyway, now let's look at VLANs on the link. Because of bridges, any VLAN might be partitioned with
respect to data traffic, for various reasons.  The WG discussed this at length, and it looked to me, and I strongly
agree with this -- that TRILL should consider partitioned VLANs on a link as a misconfiguration, and should
make sure they are defensive against it (not creating loops), but should not worry about healing
all the partitions.

The RBridges have to stick some VLAN tag on packets when they
talk to each other.  One possibility is to talk with every VLAN tag legal to transit that link.  That is certainly more
overhead than talking with a single VLAN.

And it's good to be really careful of temporary loops, even if they "can't happen". Having two RBs not see each other's
Hellos can happen due to congestion, due to RBridges that can't handle 4000 Hellos from each other RBridge
because they are tagging every Hello with every possible VLAN tag, and sending 4000 times as often, ...

If we attempt to heal a partition of VLAN A by having two forwarders off the link, it removes our ability to be very
cautious by reporting the root bridge, since although VLAN A is partitioned for data traffic, the spanning tree for
VLAN A is not necessarily partitioned, so the two RBridges will both see and report the same root bridge.

So, given the two possibilities:
a) Hellos on every possible VLAN by every RBridge. DRB elections on each possible VLAN. Different pseudonodes per link for each
possible VLAN (with some attempt to consolidate when possible). Not being able to be conservative about loops
(since the "report the root bridge" will not work). Multicast traffic might traverse the traffic multiple times (because
each pseudonode is logically a different node in the topology).
b) DRB sends lots of Hellos (to be as robust as possible about preventing multiple forwarders within the cloud,
although if that doesn't work, the next level of safety -- seeing the root bridge in the LSP), but all other RBridges
just send a single Hello. Single pseudonode. Only downside -- if the cloud is configured to have a particular VLAN
partitioned, then endnodes get orphaned.

I did suggest an enhancement to b) that I don't think is that expensive or complex, to at least detect if a VLAN is
partitioned. It will not work (nor would anything work) if there are endnodes that are not in a partition with an RBridge.
The proposal is that the VLAN-x appointed forwarder send Hellos tagged with VLAN x in addition to the common
VLAN announced by the DRB. Then an RBridge that is attached to VLAN x and which is not the designated forwarder,
can notice it is not receiving any VLAN x Hellos.

Personally, I think we should leave the spec the way it is. It was a careful balancing act between overhead and
safety, plus supporting features such as load splitting based on VLANs.

Radia

----- Original Message -----
From: Russ White <[email-masked]>
Date: Saturday, December 8, 2007 1:44 am
Subject: Re: [rbridge] Orphaned endnodes with partitioned VLANs on a cloud

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> 
> > 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.
> 
> 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
> 
> - --
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.6 (MingW32)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
> 
> iD8DBQFHWYZuER27sUhU9OQRAlj5AJ97kpulWWm57hvd9QkX69WrwWGAgQCfZpnb
> FlEWpN8YIhUQUo3DHYuo3TM=
> =Vvu1
> -----END PGP SIGNATURE-----
> 

Content-class: urn:content-classes:message
Date: Sat, 8 Dec 2007 17:59:08 -0500
From: "Eastlake III Donald-LDE008" <[email-masked]>
To: <[email-masked]>
Subject: [rbridge] Critical Bits Text
Status: RO
Content-Length: 1923

Here is an example of some text on critical summary bits cut and pasted
from an internal version of the protocol document that was never posted:

In the subpart of Section 3 on options:

 =======================================================================

   To ensure backward compatible safe operation, when Op-Length is non-
   zero, indicating that options are present, the top two bits of the
   first byte of the options area are specified as follows:

                      +-----+-----+---+---+---+---+---+---+
                      | HbH | ItE |       Reserved        |
                      +-----+-----+---+---+---+---+---+---+

                 Figure 6. Options Area Initial Flags Byte

   If the HbH bit is one, one or more critical hop-by-hop options are
   present so, for example, transit RBridges that support no options
   MUST drop the frame. If the HbH bit is zero, the frame is safe, from
   the point of view of options, for a transit RBridge. A transit
   RBridge that supports no options and forwards a frame MUST
   transparently forward the options present.

   If the ItE bit is a one, one or more critical ingress-to-egress
   options are present. If it is zero, no such options are present.  If
   either HbH or ItE is non-zero, egress RBridges that support no
   options MUST drop the frame.  If both HbH and ItE are zero, the frame
   is safe, from the point of view of options, for any egress RBridge to
   process.

 =======================================================================

It is the case the if the options format is definite so that the top bit
of the first byte of the option indicates it is a critical hop-by-hop
option and the options are ordered so that such options have to appear
first, then at least transit Rbridges that support no options would be
checking exactly the same bit regardless of whether these summary bits
were present or not.

Thanks,
Donald

Content-class: urn:content-classes:message
Date: Sat, 8 Dec 2007 17:52:58 -0500
From: "Eastlake III Donald-LDE008" <[email-masked]>
To: <[email-masked]>
Subject: Re: [rbridge] Critical bits for options
Status: RO
Content-Length: 5984

See below at @@@

-----Original Message-----

@@@ +1

@@@ Right

@@@ Thanks,
@@@ Donald

Date: Fri, 07 Dec 2007 12:44:15 -0500
From: Russ White <[email-masked]>
To: Radia Perlman <[email-masked]>
Cc: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] Orphaned endnodes with partitioned VLANs on a cloud
Status: RO
Content-Length: 967

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

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

- --

Date: Fri, 07 Dec 2007 09:18:46 -0800
From: Radia Perlman <[email-masked]>
To: Russ White <[email-masked]>
Cc: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] Orphaned endnodes with partitioned VLANs on a cloud
Status: RO
Content-Length: 1844

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:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
>
>   
>> If the world were really that simple we'd be done by
>> 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
>> 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.
>>     
>
> 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
>
> - --
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.6 (MingW32)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
>
> iD4DBQFHWTn5ER27sUhU9OQRArssAKCHCl7t0NMc7sOUVHhj0zwo22AFMACYkDgA
> ogzxbM5cHYvsYCtUay2QLA==
> =KlVU
> -----END PGP SIGNATURE-----
>   

Date: Fri, 07 Dec 2007 07:18:01 -0500
From: Russ White <[email-masked]>
To: Anoop Ghanwani <[email-masked]>
Cc: "Developing a hybrid router/bridge." <[email-masked]>, Radia Perlman <[email-masked]>
Subject: Re: [rbridge] Orphaned endnodes with partitioned VLANs on a cloud
Status: RO
Content-Length: 1473

> If the world were really that simple we'd be done by
> 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
> 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.

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

- --

Content-class: urn:content-classes:message
Date: Thu, 6 Dec 2007 19:46:30 -0800
From: "Anoop Ghanwani" <[email-masked]>
To: "Russ White" <[email-masked]>
Cc: "Developing a hybrid router/bridge." <[email-masked]>, Radia Perlman <[email-masked]>
Subject: Re: [rbridge] Orphaned endnodes with partitioned VLANs on a cloud
Status: RO
Content-Length: 1776

> From: Russ White [mailto:[email-masked]] 
> Sent: Thursday, December 06, 2007 10:42 PM
> To: Anoop Ghanwani
> Cc: Eric Gray; Radia Perlman; Developing a hybrid router/bridge.
> Subject: Re: [rbridge] Orphaned endnodes with partitioned 
> VLANs on a cloud
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> 
> >> 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.
> 
> 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.

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

Content-class: urn:content-classes:message
Date: Thu, 6 Dec 2007 19:43:07 -0800
From: "Anoop Ghanwani" <[email-masked]>
To: "Russ White" <[email-masked]>
Cc: "Developing a hybrid router/bridge." <[email-masked]>, Radia Perlman <[email-masked]>
Subject: Re: [rbridge] Orphaned endnodes with partitioned VLANs on a cloud
Status: RO
Content-Length: 1091

> From: Russ White [mailto:[email-masked]] 
> Sent: Thursday, December 06, 2007 10:37 PM
> To: Anoop Ghanwani
> Cc: Radia Perlman; Developing a hybrid router/bridge.
> Subject: Re: [rbridge] Orphaned endnodes with partitioned 
> VLANs on a cloud
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> 
> > 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? :-)

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

Date: Thu, 06 Dec 2007 22:41:41 -0500
From: Russ White <[email-masked]>
To: Anoop Ghanwani <[email-masked]>
Cc: "Developing a hybrid router/bridge." <[email-masked]>, Radia Perlman <[email-masked]>
Subject: Re: [rbridge] Orphaned endnodes with partitioned VLANs on a cloud
Status: RO
Content-Length: 1329

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

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

- --

Date: Thu, 06 Dec 2007 22:37:25 -0500
From: Russ White <[email-masked]>
To: Anoop Ghanwani <[email-masked]>
Cc: "Developing a hybrid router/bridge." <[email-masked]>, Radia Perlman <[email-masked]>
Subject: Re: [rbridge] Orphaned endnodes with partitioned VLANs on a cloud
Status: RO
Content-Length: 854

> 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

- --

Content-class: urn:content-classes:message
Date: Thu, 6 Dec 2007 19:29:35 -0800
From: "Anoop Ghanwani" <[email-masked]>
To: "Russ White" <[email-masked]>
Cc: "Developing a hybrid router/bridge." <[email-masked]>, Radia Perlman <[email-masked]>
Subject: Re: [rbridge] Orphaned endnodes with partitioned VLANs on a cloud
Status: RO
Content-Length: 687

> From: Russ White [mailto:[email-masked]] 
> Sent: Thursday, December 06, 2007 10:20 PM
> To: Anoop Ghanwani
> Cc: Eric Gray; Radia Perlman; Developing a hybrid router/bridge.
> Subject: Re: [rbridge] Orphaned endnodes with partitioned 
> VLANs on a cloud
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> 
> > 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

Content-class: urn:content-classes:message
Date: Thu, 6 Dec 2007 19:28:45 -0800
From: "Anoop Ghanwani" <[email-masked]>
To: "Russ White" <[email-masked]>
Cc: "Developing a hybrid router/bridge." <[email-masked]>, Radia Perlman <[email-masked]>
Subject: Re: [rbridge] Orphaned endnodes with partitioned VLANs on a cloud
Status: RO
Content-Length: 1473

> From: Russ White [mailto:[email-masked]] 
> Sent: Thursday, December 06, 2007 10:17 PM
> To: Anoop Ghanwani
> Cc: Radia Perlman; Developing a hybrid router/bridge.
> Subject: Re: [rbridge] Orphaned endnodes with partitioned 
> VLANs on a cloud
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> 
> > 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.

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.

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

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

Date: Thu, 06 Dec 2007 22:20:09 -0500
From: Russ White <[email-masked]>
To: Anoop Ghanwani <[email-masked]>
Cc: "Developing a hybrid router/bridge." <[email-masked]>, Radia Perlman <[email-masked]>
Subject: Re: [rbridge] Orphaned endnodes with partitioned VLANs on a cloud
Status: RO
Content-Length: 578

> 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

- --

Date: Thu, 06 Dec 2007 22:17:02 -0500
From: Russ White <[email-masked]>
To: Anoop Ghanwani <[email-masked]>
Cc: "Developing a hybrid router/bridge." <[email-masked]>, Radia Perlman <[email-masked]>
Subject: Re: [rbridge] Orphaned endnodes with partitioned VLANs on a cloud
Status: RO
Content-Length: 990

> 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

- --

Date: Thu, 06 Dec 2007 22:15:09 -0500
From: Russ White <[email-masked]>
To: Anoop Ghanwani <[email-masked]>
Cc: [email-masked]
Subject: Re: [rbridge] Orphaned endnodes with partitioned VLANs on a cloud(Example 1)
Status: RO
Content-Length: 3547

>> Suppose we have a simple network, where A, B, and C are all 
>> connected to a single link, a broadcast of some type:
>>
>> A--+
>>    |
>>    +--B
>>    |
>> C--+
>>
>> Now, assume all three are members of VLANs 1, 2, and 3 on 
>> this link. All three are properly configured to use VLAN 1 as 
>> the rbridge vlans. A is designated as the DRB.
>>
>> Now, things are running along fine, but, for some reason, A 
>> malfunctions, or some such, and can no longer send multicast 
>> packets on VLAN 1. The result is that B and C detect they've 
>> lost their connection to A, but they won't elect a new DRB at 
>> all. Why? Because they are still receiving hello's with A 
>> claiming to be the DRB, and with A's original priority and 
>> ID, on the other two VLANs.
> 
> I don't understand what kind of failure would prevent
> sending of multicast packets on VLAN 1.  And if a failure
> should happen, the correct thing is for the network
> operator to fix the failure. 

All routing protocols guard against this failure mode, because it is
known to happen. The correct action should be for the protocol to be
designed not to have unexpected state changes, and not to try and mend a
misconfiguration in the network. Full failure is always preferred over
unexpected secondary states.

> I'm almost certain I will find
> scenarios that break even if the hellos are sent per VLAN
> (once I see that proposal).  

It's the proposal this WG started with, and which was abandoned.

> One of the things oft mentioned
> on this list is partial connectivity on different VLANs
> and the handling of multicast traffic when that happens.
> There has been no good solution to that problem.

If there is partial connectivity on multiple VLANs, connectivity fails,
and rbridges shouldn't try and "work around" it in any way. Rbridges
should expect a layer two interconnect that connects them into the
rbridge cloud. Rbridges should not *care* what the underlying medium is,
how it's designed, or what it's doing, as long as that connectivity is
there.

>> The IS-IS hellos are there to find per link bidirectional 
>> reachability.
>> When you take that away, and assume reachability on one 
>> logical link because you have reachability on another logical 
>> link, you wind up in a mess that's harder to fix than the 
>> original problem you were trying to fix.
> 
> I totally understand the need for this, but we also
> have to concern ourselves with scalability, or nobody
> is going to be able to build this technology at
> a price that would make sense to deploy it.

Can you please back this up with something concrete? Can you give me a
price point? I hear a lot of numbers thrown around.

IMHO, the correct course of action is to take the simple path. If, when
these things are deployed, it's found that they won't scale, and they
can't scale to the numbers people want, and protocol changes are
required to make them scale, or that protocol changes are required to
make them work on "broken underlying Ethernet networks," then we can
address those problems then.

Until then, let's focus on the task at hand--emulating 802.1q over
what's assumed to be reliable and well configured underlying media.

:-)

Russ

- --

Content-class: urn:content-classes:message
Date: Thu, 6 Dec 2007 19:11:58 -0800
From: "Anoop Ghanwani" <[email-masked]>
To: "Russ White" <[email-masked]>
Cc: "Developing a hybrid router/bridge." <[email-masked]>, Radia Perlman <[email-masked]>
Subject: Re: [rbridge] Orphaned endnodes with partitioned VLANs on a cloud
Status: RO
Content-Length: 1223

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

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

Anoop 

> From: Russ White [mailto:[email-masked]] 
> Sent: Thursday, December 06, 2007 10:08 PM
> To: Anoop Ghanwani
> Cc: Eric Gray; Radia Perlman; Developing a hybrid router/bridge.
> Subject: Re: [rbridge] Orphaned endnodes with partitioned 
> VLANs on a cloud
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> 
> > 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
> 
> - --
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.6 (MingW32)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
> 
> iD8DBQFHWLj5ER27sUhU9OQRAsL/AJ96V7Y/V6c++7NUnt2MZJjAHbUIXQCg5j2V
> p9bUf8++WgztyaXeKVdo8S4=
> =KLib
> -----END PGP SIGNATURE-----
> 

Content-class: urn:content-classes:message
Date: Thu, 6 Dec 2007 19:10:29 -0800
From: "Anoop Ghanwani" <[email-masked]>
To: "Russ White" <[email-masked]>
Cc: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] (no subject)
Status: RO
Content-Length: 1521

> From: Russ White [mailto:[email-masked]] 
> Sent: Thursday, December 06, 2007 10:06 PM
> To: Anoop Ghanwani
> Cc: Dinesh G Dutt; Eric Gray; Developing a hybrid router/bridge.
> Subject: Re: [rbridge] (no subject)
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> 
> > 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

Content-class: urn:content-classes:message
Date: Thu, 6 Dec 2007 19:08:55 -0800
From: "Anoop Ghanwani" <[email-masked]>
To: "Russ White" <[email-masked]>
Cc: "Developing a hybrid router/bridge." <[email-masked]>, Radia Perlman <[email-masked]>
Subject: Re: [rbridge] Orphaned endnodes with partitioned VLANs on a cloud
Status: RO
Content-Length: 1666

> From: Russ White [mailto:[email-masked]] 
> Sent: Thursday, December 06, 2007 10:03 PM
> To: Anoop Ghanwani
> Cc: Radia Perlman; Developing a hybrid router/bridge.
> Subject: Re: [rbridge] Orphaned endnodes with partitioned 
> VLANs on a cloud
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> 
> > 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.

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

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

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.

Anoop

Date: Thu, 06 Dec 2007 22:07:37 -0500
From: Russ White <[email-masked]>
To: Anoop Ghanwani <[email-masked]>
Cc: "Developing a hybrid router/bridge." <[email-masked]>, Radia Perlman <[email-masked]>
Subject: Re: [rbridge] Orphaned endnodes with partitioned VLANs on a cloud
Status: RO
Content-Length: 644

> 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

- --

Date: Thu, 06 Dec 2007 22:06:29 -0500
From: Russ White <[email-masked]>
To: Anoop Ghanwani <[email-masked]>
Cc: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] (no subject)
Status: RO
Content-Length: 1400

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

- --

Content-class: urn:content-classes:message
Date: Thu, 6 Dec 2007 19:06:08 -0800
From: "Anoop Ghanwani" <[email-masked]>
To: "Russ White" <[email-masked]>
Cc: "Developing a hybrid router/bridge." <[email-masked]>, Radia Perlman <[email-masked]>
Subject: Re: [rbridge] Orphaned endnodes with partitioned VLANs on a cloud
Status: RO
Content-Length: 992

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

Anoop 

> From: Russ White [mailto:[email-masked]] 
> Sent: Thursday, December 06, 2007 10:00 PM
> To: Anoop Ghanwani
> Cc: Eric Gray; Radia Perlman; Developing a hybrid router/bridge.
> Subject: Re: [rbridge] Orphaned endnodes with partitioned 
> VLANs on a cloud
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> 
> > It is possible to misconfigure bridged LANs so that VLANs end up 
> > getting partitioned.
> > The automated way to avoid that is using MVRP.
> 
> Is MVRP, or emulation of MVRP, in scope for this WG?
> 
> :-)
> 
> Russ
> 
> - --
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.6 (MingW32)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
> 
> iD8DBQFHWLc4ER27sUhU9OQRAlF5AJ9KY9cL3vI3ARQNKLRTZNOauSbrwQCfXhjx
> LoSy2T6UAKwoxpnJtTHIDro=
> =EqjY
> -----END PGP SIGNATURE-----
> 

Date: Thu, 06 Dec 2007 22:03:23 -0500
From: Russ White <[email-masked]>
To: Anoop Ghanwani <[email-masked]>
Cc: "Developing a hybrid router/bridge." <[email-masked]>, Radia Perlman <[email-masked]>
Subject: Re: [rbridge] Orphaned endnodes with partitioned VLANs on a cloud
Status: RO
Content-Length: 1379

> 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

- --

Content-class: urn:content-classes:message
Date: Thu, 6 Dec 2007 19:01:35 -0800
From: "Anoop Ghanwani" <[email-masked]>
To: "Russ White" <[email-masked]>
Cc: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] (no subject)
Status: RO
Content-Length: 979

> 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.
> Subject: Re: [rbridge] (no subject)
> 
> -----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

Date: Thu, 06 Dec 2007 22:00:08 -0500
From: Russ White <[email-masked]>
To: Anoop Ghanwani <[email-masked]>
Cc: "Developing a hybrid router/bridge." <[email-masked]>, Radia Perlman <[email-masked]>
Subject: Re: [rbridge] Orphaned endnodes with partitioned VLANs on a cloud
Status: RO
Content-Length: 547

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

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

:-)

Russ

- --

Content-class: urn:content-classes:message
Date: Thu, 6 Dec 2007 18:59:58 -0800
From: "Anoop Ghanwani" <[email-masked]>
To: "Russ White" <[email-masked]>
Cc: "Developing a hybrid router/bridge." <[email-masked]>, Radia Perlman <[email-masked]>
Subject: Re: [rbridge] Orphaned endnodes with partitioned VLANs on a cloud
Status: RO
Content-Length: 1725

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.

Anoop

> From: Russ White [mailto:[email-masked]] 
> Sent: Thursday, December 06, 2007 9:54 PM
> To: Anoop Ghanwani
> Cc: Radia Perlman; Developing a hybrid router/bridge.
> Subject: Re: [rbridge] Orphaned endnodes with partitioned 
> VLANs on a cloud
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> 
> > 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
> 
> - --
> -----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-----
> 

Date: Thu, 06 Dec 2007 21:59:24 -0500
From: Russ White <[email-masked]>
To: Anoop Ghanwani <[email-masked]>
Cc: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] (no subject)
Status: RO
Content-Length: 1035

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

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

- --

Content-class: urn:content-classes:message
Date: Thu, 6 Dec 2007 18:55:58 -0800
From: "Anoop Ghanwani" <[email-masked]>
To: "Russ White" <[email-masked]>, <[email-masked]>
Subject: Re: [rbridge] Orphaned endnodes with partitioned VLANs on a cloud(Example 1)
Status: RO
Content-Length: 2277

> [mailto:[email-masked]] On Behalf Of Russ White
> Sent: Thursday, December 06, 2007 6:20 PM
> To: [email-masked]
> Subject: [rbridge] Orphaned endnodes with partitioned VLANs 
> on a cloud(Example 1)
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> 
> Suppose we have a simple network, where A, B, and C are all 
> connected to a single link, a broadcast of some type:
> 
> A--+
>    |
>    +--B
>    |
> C--+
> 
> Now, assume all three are members of VLANs 1, 2, and 3 on 
> this link. All three are properly configured to use VLAN 1 as 
> the rbridge vlans. A is designated as the DRB.
> 
> Now, things are running along fine, but, for some reason, A 
> malfunctions, or some such, and can no longer send multicast 
> packets on VLAN 1. The result is that B and C detect they've 
> lost their connection to A, but they won't elect a new DRB at 
> all. Why? Because they are still receiving hello's with A 
> claiming to be the DRB, and with A's original priority and 
> ID, on the other two VLANs.

I don't understand what kind of failure would prevent
sending of multicast packets on VLAN 1.  And if a failure
should happen, the correct thing is for the network
operator to fix the failure. 

> Now the link is completely out of the SPF tree, and not used 
> at all--because of a partial failure on the DRB. This is 
> broken, and unexpected behavior.

 I'm almost certain I will find
scenarios that break even if the hellos are sent per VLAN
(once I see that proposal).  One of the things oft mentioned
on this list is partial connectivity on different VLANs
and the handling of multicast traffic when that happens.
There has been no good solution to that problem.

> The IS-IS hellos are there to find per link bidirectional 
> reachability.
> When you take that away, and assume reachability on one 
> logical link because you have reachability on another logical 
> link, you wind up in a mess that's harder to fix than the 
> original problem you were trying to fix.

I totally understand the need for this, but we also
have to concern ourselves with scalability, or nobody
is going to be able to build this technology at
a price that would make sense to deploy it.

Anoop

Date: Thu, 06 Dec 2007 21:54:18 -0500
From: Russ White <[email-masked]>
To: Anoop Ghanwani <[email-masked]>
Cc: "Developing a hybrid router/bridge." <[email-masked]>, Radia Perlman <[email-masked]>
Subject: Re: [rbridge] Orphaned endnodes with partitioned VLANs on a cloud
Status: RO
Content-Length: 1035

> 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

- --

Content-class: urn:content-classes:message
Date: Thu, 6 Dec 2007 20:53:17 -0600
From: "Eric Gray" <[email-masked]>
To: "Anoop Ghanwani" <[email-masked]>, "Radia Perlman" <[email-masked]>
Cc: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] Orphaned endnodes with partitioned VLANs on a cloud
Status: RO
Content-Length: 12513

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
> Cc: Developing a hybrid router/bridge.
> Subject: RE: [rbridge] Orphaned endnodes with partitioned 
> VLANs on a cloud
> Importance: High
> 
> 
> (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 
> 
> > Sent: Wednesday, December 05, 2007 2:25 PM
> > To: Anoop Ghanwani; Radia Perlman
> > Cc: Developing a hybrid router/bridge.
> > Subject: RE: [rbridge] Orphaned endnodes with partitioned 
> > VLANs on a cloud
> > 
> > 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
> > > Cc: Developing a hybrid router/bridge.
> > > 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
> > > 
> > > > Sent: Tuesday, December 04, 2007 7:15 PM
> > > > To: Eric Gray
> > > > Cc: Developing a hybrid router/bridge.
> > > > Subject: [rbridge] Orphaned endnodes with partitioned VLANs
> > > on a cloud
> > > > 
> > > > 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
> > > > 
> > > > 
> > > > Eric Gray wrote:
> > > > > 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
> > > > >

Content-class: urn:content-classes:message
Date: Thu, 6 Dec 2007 18:49:32 -0800
From: "Anoop Ghanwani" <[email-masked]>
To: "Russ White" <[email-masked]>, "Radia Perlman" <[email-masked]>
Cc: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] Orphaned endnodes with partitioned VLANs on a cloud
Status: RO
Content-Length: 2702

> [mailto:[email-masked]] On Behalf Of Russ White
> Sent: Thursday, December 06, 2007 6:08 PM
> To: Radia Perlman
> Cc: Developing a hybrid router/bridge.
> Subject: Re: [rbridge] Orphaned endnodes with partitioned 
> VLANs on a cloud
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> 
> > 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'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.

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.

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

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

Passive interfaces won't work for RBridges because you
could get really nasty loops and duplication of traffic.
These devices are different than routers.
 
> > 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.
> 
> 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.
> 

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

Content-class: urn:content-classes:message
Date: Thu, 6 Dec 2007 18:42:59 -0800
From: "Anoop Ghanwani" <[email-masked]>
To: "Russ White" <[email-masked]>, "Dinesh G Dutt" <[email-masked]>
Cc: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] Fixing Broken Connections in the Middle
Status: RO
Content-Length: 867

> 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

Content-class: urn:content-classes:message
Date: Thu, 6 Dec 2007 18:38:36 -0800
From: "Anoop Ghanwani" <[email-masked]>
To: "Dinesh G Dutt" <[email-masked]>, "Eric Gray" <[email-masked]>
Cc: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] (no subject)
Status: RO
Content-Length: 6123

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
> Cc: Developing a hybrid router/bridge.
> 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,
> >
> > 	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
> >

Content-class: urn:content-classes:message
Date: Thu, 6 Dec 2007 18:32:37 -0800
From: "Anoop Ghanwani" <[email-masked]>
To: "Eric Gray" <[email-masked]>, "Radia Perlman" <[email-masked]>
Cc: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] Orphaned endnodes with partitioned VLANs on a cloud
Status: RO
Content-Length: 9749

(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 

> Sent: Wednesday, December 05, 2007 2:25 PM
> To: Anoop Ghanwani; Radia Perlman
> Cc: Developing a hybrid router/bridge.
> Subject: RE: [rbridge] Orphaned endnodes with partitioned 
> VLANs on a cloud
> 
> 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
> > Cc: Developing a hybrid router/bridge.
> > 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
> > 
> > > Sent: Tuesday, December 04, 2007 7:15 PM
> > > To: Eric Gray
> > > Cc: Developing a hybrid router/bridge.
> > > Subject: [rbridge] Orphaned endnodes with partitioned VLANs
> > on a cloud
> > > 
> > > 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
> > > 
> > > 
> > > Eric Gray wrote:
> > > > 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
> > > >

Date: Thu, 06 Dec 2007 18:28:24 -0500
From: Russ White <[email-masked]>
To: [email-masked]
Subject: Re: [rbridge] Orphaned endnodes with partitioned VLANs on a cloud (Example 2)
Status: RO
Content-Length: 1917

Suppose you have a simple network where A, B, and C are on the same
broadcast segment, but there are several possible VLANs on which rbridge
traffic could run:

A--+
   |
   +--B
   |
C--+

Now, A is able to talk on VLANs 1, 2, and 3, while B and C are able to
talk on VLANs 2, 3, and 4. The "correct" vlan for rbridge traffic to
flow across is 2, which A and C are configured for. B, however, is
configured to pass rbridge traffic across VLAN 4, which is a
misconfiguration.

Suppose C is chosen as the DRB in this case. It advertises VLAN 2 as the
correct rbridge VLAN, and hence, B's misconfiguration is "covered up."
The system works as designed. However, when C fails, B is chosen as the
DRB on this link. Since B is misconfigured, the link now falls off the
network.... Hmmm.... This isn't what we were after, was it? If there is
a large number of routers on the link, if the rbridge which happens to
be elected DRB is misconfigured, the entire link is tossed for transit
use, rather than just taking those misconfigured rbridges off the link.
That's an unexpected, and bad, side effect.

The problem here is that you're assuming that while all the other nodes
might be misconfigured, the node selected as the DRB won't be
misconfigured. That's a rather odd assumption--especially since the DRB
is elected, not manually configured. Most folks have to go look when you
ask them which router on their network is the DIS, I don't expect it
will be much different with rbridges.

There's at least one more failure mode in this scheme, I'll try and
cover it later.

:-)

Russ

- --

Date: Thu, 06 Dec 2007 18:20:23 -0500
From: Russ White <[email-masked]>
To: [email-masked]
Subject: [rbridge] Orphaned endnodes with partitioned VLANs on a cloud (Example 1)
Status: RO
Content-Length: 1494

Suppose we have a simple network, where A, B, and C are all connected to
a single link, a broadcast of some type:

A--+
   |
   +--B
   |
C--+

Now, assume all three are members of VLANs 1, 2, and 3 on this link. All
three are properly configured to use VLAN 1 as the rbridge vlans. A is
designated as the DRB.

Now, things are running along fine, but, for some reason, A
malfunctions, or some such, and can no longer send multicast packets on
VLAN 1. The result is that B and C detect they've lost their connection
to A, but they won't elect a new DRB at all. Why? Because they are still
receiving hello's with A claiming to be the DRB, and with A's original
priority and ID, on the other two VLANs.

Now the link is completely out of the SPF tree, and not used at
all--because of a partial failure on the DRB. This is broken, and
unexpected behavior.

The IS-IS hellos are there to find per link bidirectional reachability.
When you take that away, and assume reachability on one logical link
because you have reachability on another logical link, you wind up in a
mess that's harder to fix than the original problem you were trying to fix.

:-)

Russ

- --

Date: Thu, 6 Dec 2007 18:01:06 -0500
From: James Carlson <[email-masked]>
To: Radia Perlman <[email-masked]>
Cc: [email-masked]
Subject: Re: [rbridge] Critical bits for options
Status: RO
Content-Length: 1190

[a...d]

Date: Thu, 06 Dec 2007 18:07:53 -0500
From: Russ White <[email-masked]>
To: Radia Perlman <[email-masked]>
Cc: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] Orphaned endnodes with partitioned VLANs on a cloud
Status: RO
Content-Length: 2045

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

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

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

- --

Date: Thu, 6 Dec 2007 17:27:57 -0500
From: James Carlson <[email-masked]>
To: Russ White <[email-masked]>
Cc: [email-masked]
Subject: Re: [rbridge] Critical bits for options
Status: RO
Content-Length: 2581

Date: Thu, 06 Dec 2007 14:39:56 -0800
From: Radia Perlman <[email-masked]>
To: [email-masked]
Subject: Re: [rbridge] Critical bits for options
Status: RO
Content-Length: 1799

Radia

Date: Thu, 06 Dec 2007 13:57:34 -0800
From: Radia Perlman <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] Orphaned endnodes with partitioned VLANs on a cloud
Status: RO
Content-Length: 22439

This is a multi-part message in MIME format.

--Boundary_(ID_n8gVux0FrK1GlPqPBI+d6A)
Content-type: text/plain; charset=ISO-8859-1; format=flowed
Content-transfer-encoding: 7BIT

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

Dinesh said:

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

Radia Perlman wrote:
> 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
>
>
> Eric Gray wrote:
>   
>> 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 
>>

--Boundary_(ID_n8gVux0FrK1GlPqPBI+d6A)
Content-type: text/html; charset=ISO-8859-1
Content-transfer-encoding: 7BIT

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
The two possible designs people are thinking about are:<br>
<br>
a) separate DRB election per VLAN, possibly a different DRB per VLAN,
and a different pseudonode (visible outside that link) for<br>
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<br>
not decapslate something from ingress RB1 if RB1 reports the same root
bridge", because with a partitioned VLAN, both RB1 and RB2<br>
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<br>
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.<br>
<br>
b) one DRB, one pseudonode, tough luck for orphaned endnodes if a VLAN
is partitioned, except for endnodes in the same partition<br>
as the RBridge appointed forwarder for that VLAN.<br>
<br>
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<br>
send Hellos on, on that link? <br>
<br>
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<br>
if someone has configured bridges to refuse to pass certain VLANs, and
can be easily fixed through a number of ways (like, for instance,<br>
changing the configuration of the bridges). And note that orphaned
endnodes can happen no matter what TRILL does because it could happen
that<br>
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)<br>
<br>
Note that if TRILL is trying to exactly copy all bridge functionality,<br>
we are not doing that. Some people apparently configure partitioned
VLANs, I've heard, because they are reusing VLAN nmbers.<br>
TRILL is specifically not keeping different instances of VLAN A
separate, but making the assumption that VLAN A = VLAN A.<br>
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<br>
with a partitioned VLAN as a configuration mistake. It seems like a
better way of accomplishing whatever it is that the customers were<br>
attempting to accomplish with restricting certain VLANs from traversing
certain links, would be doing all the fancy traffic engineering<br>
stuff using layer 3 techniques that have been around for awhile.<br>
<br>
That being said---I'm always anxious to please everyone, here's a
potential compromise to solve the partitioned VLAN problem.<br>
<br>
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<br>
on VLAN A. If the DRB announces its VLAN forwarder assignments in its
Hello, then if RB2 attaches to VLAN A, and knows that<br>
RB1 is appointed VLAN A forwarder, then RB2, if it does not receive
some VLAN A tagged Hellos from RB1 knows there<br>
is a problem. <br>
<br>
What to do when you know there's a problem? Here are some suggestions:<br>
a) log a network management event<br>
b) do separate DRB elections on any VLANs that have been detected<br>
as being partiitoned. Wind up with a DRB, and pseudonode for each
partition.<br>
And get rid of the root bridge safety check because all the RBridges in
all VLAN A partitions will see the same root bridge<br>
anyway. Note: I find this scary (I like the safety check). It is more
scalable than do separate DRB elections for every VLAN,<br>
since except in the (hopefully very rare) case of a partitioned VLAN,
there will be just a single Hello election and single pseudonode.<br>
<br>
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<br>
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.&nbsp; I prefer just<br>
not worrying at all about endnodes orphaned by partitioned VLANs.
However, I think it's OK to attempt to detect partitioned VLANs<br>
by having the VLAN X forwarder send Hellos on VLAN X (in addition to
the common VLAN).<br>
<br>
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.<br>
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,<br>
will send an additional Hello tagged with x.<br>
<br>
Radia<br>
<br>
<br>
Dinesh said:<br>
<br>
<pre wrap="">&gt;&gt;This is another reason for me to be nervous about making these changes 
&gt;&gt;now. The old method where we did DRB per VLAN, a single pseudo-node for 
&gt;&gt;all VLANs that the Rbridge was DRB for seemed sufficient to me and 
&gt;&gt;avoided all these issues. We've gotten into this mess because someone 
&gt;&gt;decided that sending multiple Hellos (one per active VLAN) is a huge 
&gt;&gt;burden on the CPU. I disagree with that assumption and would like to 
&gt;&gt;avoid all these issues by falling back to what we had earlier.
</pre>
<br>
Radia Perlman wrote:
<blockquote cite="mid:[email-masked]" type="cite">
  <pre wrap="">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

Eric Gray wrote:
  </pre>
  <blockquote type="cite">
    <pre wrap="">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
<a class="moz-txt-link-abbreviated" href="mailto:[email-masked]">[email-masked]</a>
<a class="moz-txt-link-freetext" href="http://mailman.postel.org/mailman/listinfo/rbridge">http://mailman.postel.org/mailman/listinfo/rbridge</a>
  
    </pre>
  </blockquote>
  <pre wrap=""><!---->
_______________________________________________
rbridge mailing list
<a class="moz-txt-link-abbreviated" href="mailto:[email-masked]">[email-masked]</a>
<a class="moz-txt-link-freetext" href="http://mailman.postel.org/mailman/listinfo/rbridge">http://mailman.postel.org/mailman/listinfo/rbridge</a>
  </pre>
</blockquote>
<br>
</body>
</html>

--Boundary_(ID_n8gVux0FrK1GlPqPBI+d6A)--

Date: Thu, 06 Dec 2007 16:05:39 -0500
From: Russ White <[email-masked]>
To: [email-masked]
Subject: Re: [rbridge] Critical bits for options
Status: RO
Content-Length: 2326

Trying to sort this out:

:-)

Russ

- --

Date: Thu, 06 Dec 2007 15:20:06 -0500
From: Russ White <[email-masked]>
To: Dinesh G Dutt <[email-masked]>
Cc: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] Fixing Broken Connections in the Middle
Status: RO
Content-Length: 1923

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

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

- --

Date: Thu, 6 Dec 2007 14:39:44 -0500
From: James Carlson <[email-masked]>
To: Eastlake III Donald-LDE008 <[email-masked]>
Cc: [email-masked]
Subject: Re: [rbridge] Critical bits for options
Status: RO
Content-Length: 5189

Date: Thu, 06 Dec 2007 14:58:04 -0500
From: Russ White <[email-masked]>
To: Dinesh G Dutt <[email-masked]>
Cc: "Developing a hybrid router/bridge." <[email-masked]>
Subject: [rbridge] Fixing Broken Connections in the Middle
Status: RO
Content-Length: 1853

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

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

- --

Date: Thu, 06 Dec 2007 14:58:04 -0500
From: Russ White <[email-masked]>
To: Dinesh G Dutt <[email-masked]>
Cc: "Developing a hybrid router/bridge." <[email-masked]>
Subject: [rbridge] Fixing Broken Connections in the Middle
Status: RO
Content-Length: 1853

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

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

- --

Date: Thu, 06 Dec 2007 14:58:04 -0500
From: Russ White <[email-masked]>
To: Dinesh G Dutt <[email-masked]>
Cc: "Developing a hybrid router/bridge." <[email-masked]>
Subject: [rbridge] Fixing Broken Connections in the Middle
Status: RO
Content-Length: 1853

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

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

- --

Date: Thu, 06 Dec 2007 14:58:04 -0500
From: Russ White <[email-masked]>
To: Dinesh G Dutt <[email-masked]>
Cc: "Developing a hybrid router/bridge." <[email-masked]>
Subject: [rbridge] Fixing Broken Connections in the Middle
Status: RO
Content-Length: 1853

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

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

- --

Date: Thu, 06 Dec 2007 14:58:04 -0500
From: Russ White <[email-masked]>
To: Dinesh G Dutt <[email-masked]>
Cc: "Developing a hybrid router/bridge." <[email-masked]>
Subject: [rbridge] Fixing Broken Connections in the Middle
Status: RO
Content-Length: 1853

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

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

- --

Date: Thu, 6 Dec 2007 14:20:15 -0500
From: James Carlson <[email-masked]>
To: Dinesh G Dutt <[email-masked]>
Cc: [email-masked], Radia Perlman <[email-masked]>, Joe Touch <[email-masked]>
Subject: Re: [rbridge] Critical bits for options
Status: RO
Content-Length: 2186

   1. Critical hop-by-hop

Content-class: urn:content-classes:message
Date: Thu, 6 Dec 2007 14:17:19 -0500
From: "Eastlake III Donald-LDE008" <[email-masked]>
To: "James Carlson" <[email-masked]>
Cc: [email-masked]
Subject: Re: [rbridge] Critical bits for options
Status: RO
Content-Length: 3037

Hi James,

See below at @@@

-----Original Message-----

@@@ Thanks,
@@@ Donald

Date: Thu, 06 Dec 2007 11:03:38 -0800
From: Dinesh G Dutt <[email-masked]>
To: Joe Touch <[email-masked]>
Cc: [email-masked], Radia Perlman <[email-masked]>, James Carlson <[email-masked]>
Subject: Re: [rbridge] Critical bits for options
Status: RO
Content-Length: 3207

I agree with your logic.

Dinesh

Date: Thu, 06 Dec 2007 10:30:47 -0800
From: Joe Touch <[email-masked]>
To: Dinesh G Dutt <[email-masked]>
Cc: [email-masked], Radia Perlman <[email-masked]>, James Carlson <[email-masked]>
Subject: Re: [rbridge] Critical bits for options
Status: RO
Content-Length: 2872

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig282FE702DCFFF79AFB2A1C78
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Dinesh G Dutt wrote:
> v6 rules are more complicated than we need, aren't they ? All we need i=
s
> this frame has options which I understand are fine to ignore and so I'l=
l
> outgoing frame".=20

Joe
>=20
>>     - discard w/ICMP iff source !=3D multicast
>>
>> =20
>> ----------------------------------------------------------------------=
--
>>  =20
>=20

--------------enig282FE702DCFFF79AFB2A1C78
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

--------------enig282FE702DCFFF79AFB2A1C78--

Date: Thu, 06 Dec 2007 10:29:49 -0800
From: Dinesh G Dutt <[email-masked]>
To: Eric Gray <[email-masked]>
Cc: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] (no subject)
Status: RO
Content-Length: 4881

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

Date: Thu, 06 Dec 2007 10:25:50 -0800
From: Dinesh G Dutt <[email-masked]>
To: Joe Touch <[email-masked]>
Cc: [email-masked], Radia Perlman <[email-masked]>, James Carlson <[email-masked]>
Subject: Re: [rbridge] Critical bits for options
Status: RO
Content-Length: 1702

Dinesh

Date: Wed, 05 Dec 2007 23:45:19 -0800
From: Joe Touch <[email-masked]>
To: Eastlake III Donald-LDE008 <[email-masked]>
Cc: [email-masked]
Subject: Re: [rbridge] Critical bits for options
Status: RO
Content-Length: 7251

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enigA8818C1B0E44A3EF7F661C2A
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Eastlake III Donald-LDE008 wrote:
>=20
>=20
=2E..
>> If we define these bits, then an egress RBridge MUST look to see if=20
>=20
> I believe we're talking about a "summary" bit in each case. As a result=
,
>=20
> as the current protocol draft does, making it possible to avoid parsing=

>=20
>=20

Yes.

> frame priority from the inner VLAN tag. This is necessary even for know=
n
> easy since their length is given and, if you know there were no critica=
l
> options present, safe.=20

>=20
> parse the entire option set to find out WHICH options are listed, and t=
o
>=20

>> Though I suppose an RBridge that doesn't support ANY critical options =

>> option that it should drop the packet, without having to parse to find=

>=20
>=20

> summary bits are probably just a safety measure. That's because I would=

> all). Thus, by imposing requirements on the sender, you could claim tha=
t
> Rbridge that does not support it. However, in the real world, errors of=

> did receive a frame with a critical hop-by-hop option in it and you did=

> not have these summary bits (or they were set wrong), it will screw up.=

>=20
> @@@ An argument in favor of the bits is that you might have a case wher=
e
> from Rbridge Z and out one port there are three downstream Rbridges one=

> know from the link state database is supported by A and B but not C. It=

> might be nice, for some options, to be able to just multicast the frame=

> knowing that C will just discard it. This would be a decision by RBridg=
e

Joe

--------------enigA8818C1B0E44A3EF7F661C2A
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

--------------enigA8818C1B0E44A3EF7F661C2A--

Date: Wed, 05 Dec 2007 18:16:25 -0800
From: Erik Nordmark <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>
Subject: [rbridge] FYI: L2VPN presentation
Status: RO
Content-Length: 325

Since your charter says we should work with L2VPN Donald put together a 
few slides and I presented it. It was past the end of the time slot so 
there wasn't time for any feedback, but we'll pursue feedback with the 
L2VPN chairs.

The presentation is at
http://www3.ietf.org/proceedings/07dec/slides/l2vpn-4.ppt

    Erik

Content-class: urn:content-classes:message
Date: Wed, 5 Dec 2007 15:52:32 -0500
From: "Eastlake III Donald-LDE008" <[email-masked]>
To: "Joe Touch" <[email-masked]>
Cc: [email-masked]
Subject: Re: [rbridge] Critical bits for options
Status: RO
Content-Length: 5820

Hi Joe,

-----Original Message-----

> I'd like to make sure the decision about whether to define critical
bits 
> A "critical" option (some people call it "mandatory") is an option
that 

Joe

@@@ Thanks,
@@@ Donald

Content-class: urn:content-classes:message
Date: Wed, 5 Dec 2007 13:24:55 -0600
From: "Eric Gray" <[email-masked]>
To: "Anoop Ghanwani" <[email-masked]>, "Radia Perlman" <[email-masked]>
Cc: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] Orphaned endnodes with partitioned VLANs on a cloud
Status: RO
Content-Length: 8325

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
> Cc: Developing a hybrid router/bridge.
> 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 
> 
> > Sent: Tuesday, December 04, 2007 7:15 PM
> > To: Eric Gray
> > Cc: Developing a hybrid router/bridge.
> > Subject: [rbridge] Orphaned endnodes with partitioned VLANs 
> on a cloud
> > 
> > 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
> > 
> > 
> > Eric Gray wrote:
> > > 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
> > >

Content-class: urn:content-classes:message
Date: Wed, 5 Dec 2007 13:19:38 -0600
From: "Eric Gray" <[email-masked]>
To: "Radia Perlman" <[email-masked]>
Cc: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] Orphaned endnodes with partitioned VLANs on a cloud
Status: RO
Content-Length: 9890

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: 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
> 
> 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
> 
> 
> Eric Gray wrote:
> > 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 
> >

Content-class: urn:content-classes:message
Date: Wed, 5 Dec 2007 12:41:41 -0600
From: "Eric Gray" <[email-masked]>
To: "Radia Perlman" <[email-masked]>
Cc: "Developing a hybrid router/bridge." <[email-masked]>
Subject: Re: [rbridge] Orphaned endnodes with partitioned VLANs on a cloud
Status: RO
Content-Length: 6246

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  

> 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
> 
> 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
> 
> 
> Eric Gray wrote:
> > 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 
> >

Date: Wed, 05 Dec 2007 09:24:56 -0800
From: Joe Touch <[email-masked]>
To: James Carlson <[email-masked]>
Cc: [email-masked], Radia Perlman <[email-masked]>
Subject: Re: [rbridge] Critical bits for options
Status: RO
Content-Length: 1466

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig87C24805147E2A5C56262E9F
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

- unrecognized options have 4 variants indicated via flags:
	- silent pass (skip over silently)
	- silent discard
	- discard w/ICMP
	- discard w/ICMP iff source !=3D multicast

- unrecognized options
	- silent pass

Joe

--------------enig87C24805147E2A5C56262E9F
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

--------------enig87C24805147E2A5C56262E9F--

Date: Wed, 5 Dec 2007 09:14:23 -0500
From: James Carlson <[email-masked]>
To: Radia Perlman <[email-masked]>
Cc: [email-masked]
Subject: Re: [rbridge] Critical bits for options
Status: RO
Content-Length: 1096

Content-class: urn:content-classes:message
Date: Wed, 5 Dec 2007 02:58:30 -0500
From: "Eastlake III Donald-LDE008" <[email-masked]>
To: <[email-masked]>
Subject: [rbridge] Vancouver Presentations on line
Status: RO
Content-Length: 116

The as-presented versions of all the TRILL presentations have been
uploaded to the Meeting Materials site.

Donald

Date: Tue, 04 Dec 2007 20:23:20 -0800
From: Joe Touch <[email-masked]>
To: Radia Perlman <[email-masked]>
Cc: [email-masked]
Subject: Re: [rbridge] Critical bits for options
Status: RO
Content-Length: 2931

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig0A14B2D3F0CD89895F0F56AB
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Radia Perlman wrote:
> I'd like to make sure the decision about whether to define critical bit=
s=20
>=20
> Currently the TRILL spec says to ignore all options -- the only thing=20
>=20
> A "critical" option (some people call it "mandatory") is an option that=
=20
> the packet. A noncritical option is one that you are allowed to ignore =

> and skip over.
>=20
> The way the spec is now precludes critical options, because RBridges=20
>=20
> An alternative is for TRILL to define two bits at the beginning of the =

>=20
>=20
> If we define these bits, then an egress RBridge MUST look to see if=20

There is benefit ONLY for hop-by-hop bits, i.e., to accelerate
forwarding. Egress rbridges would need to parse the entire header anyway.=

> Though I suppose an RBridge that doesn't support ANY critical options=20
> option that it should drop the packet, without having to parse to find =

Joe

--------------enig0A14B2D3F0CD89895F0F56AB
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

--------------enig0A14B2D3F0CD89895F0F56AB--

Date: Tue, 04 Dec 2007 19:14:40 -0800
From: Radia Perlman <[email-masked]>
To: Eric Gray <[email-masked]>
Cc: "Developing a hybrid router/bridge." <[email-masked]>
Subject: [rbridge] Orphaned endnodes with partitioned VLANs on a cloud
Status: RO
Content-Length: 5451

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

Eric Gray wrote:
> 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 
>

Date: Tue, 04 Dec 2007 19:02:45 -0800
From: Radia Perlman <[email-masked]>
To: [email-masked]
Subject: [rbridge] Critical bits for options
Status: RO
Content-Length: 2766

The two bits are:

So, our choices as a WG:

Radia

Content-class: urn:content-classes:message
Date: Tue, 4 Dec 2007 12:57:50 -0600
From: "Eric Gray" <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>
Subject: [rbridge] (no subject)
Status: RO
Content-Length: 3899

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 

Content-class: urn:content-classes:message
Date: Mon, 3 Dec 2007 17:27:07 -0500
From: "Eastlake III Donald-LDE008" <[email-masked]>
To: <[email-masked]>
Subject: [rbridge] TRILL Meeting Tomorrow
Status: RO
Content-Length: 345

Hi,

An updated agenda and more, but not all, presentations have been
uploaded to the Meeting Materials site
https://datatracker.ietf.org/meeting/70/materials.html.

As usual, we will need a secretary to take notes from the meeting. I'm
asking in advance so that people will think about this and maybe we'll
have a volunteer...

Thanks,
Donald