Subject: [rbridge] Proposed compromise for short/long hellos

From: Radia Perlman <[email-masked]>
Date: Wed, 25 Mar 2009 09:57:41 -0700

After listening to the discussion at the meeting, and talking to some 
people in the hall, I hope
this might be palatable to everyone.

a) have only one type of Hello: the original type, but say in the spec 
that Hellos
MUST NOT be padded. Also mention a maximum size, and say that this might
limit really really really creative appointments of lots of appointed 
forwarders for lots
of VLANs.

b) have another type of mechanism, perhaps called "MTU discovery", which 
would
be a pairwise protocol between two RBridges R1 and R2, where R1 sends a 
padded
message, and R2 acks it if R2 received it. This would be an optional 
protocol specified
in a separate document

c) we'd add a bit to the Hello saying "I support the MTU discovery protocol"
_______________________________________________
rbridge mailing list
[email-masked]
http://mailman.postel.org/mailman/listinfo/rbridge

---

From: Dinesh G Dutt <[email-masked]>
Date: Wed, 25 Mar 2009 10:15:43 -0700

I like this proposal,

Dinesh

-- 
We make our world significant by the courage of our questions and by 
the depth of our answers.                               - Carl Sagan

---

From: "Don Fedyk" <[email-masked]>
Date: Wed, 25 Mar 2009 14:03:34 -0400

Hi Radia

I'm still not convinced you should be changing IS-IS.  

The root cause of the issue is RBridge forms adjacencies on links with
non direct neighbors. It also make forwarding assumptions when it does
not detect neighbors.  

This is different behavior from every other system that I know of.  

If RBridge defaulted to STP behavior as was pointed out by James then no
modification to IS-IS would be needed plus the issue of looping packets
would be nipped in the bud.  You solution below only detect the problem
you still need to assume an appropriate forwarding behavior and this is
STP as a default. 

Regards,
Don   

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Radia Perlman
Sent: Wednesday, March 25, 2009 12:58 PM
To: TRILL/RBridge Working Group
Subject: [rbridge] Proposed compromise for short/long hellos

would

c) we'd add a bit to the Hello saying "I support the MTU discovery
protocol"
_______________________________________________
rbridge mailing list
[email-masked]
http://mailman.postel.org/mailman/listinfo/rbridge

---

From: "Eric Gray" <[email-masked]>
Date: Wed, 25 Mar 2009 12:57:16 -0500

Radia,

	I like the outline of a compromise you propose, though I suspect
that this is pretty much the opposite of what the IS-IS folks are very
likely to find acceptable.

	Assuming we go with your proposal, I would suggest that we
should 
be more precise in mentioning a maximum size.  I would suggest something

along the lines of:

<hello PDUs> must be shorter than the lesser of the maximum <PDU length>
presumed for the <carrying technology>, or a configurable maximum value.

	The one reservation people may have is that what was discussed
in 
the meeting was more along the lines of -

1) let's have one type of (IS-IS based) hello.
2) let's define a separate message type - if necessary (as it seems
clear
   that it is) - to address this issue.

   (so far, consistent with your suggestion)

3) The hello message needs to ensure that the maximum packet size each
   end assumes is correct, since (one of) the purpose(s) of these PDUs
   (in IS-IS) is to determine whether an adjacency should be formed.
4) This means that the separate message type would need to address the
   issue with making sure that topologically adjacent RBridges are, in
   fact, discovered irrespective of the appropriateness of making them
   adjacent peers.

	All of that said, however, I think there was a clear sense that
the important objective in the RBridge case is to protect against loop
formation - which is unavoidable in the event that RBridge topological
adjacencies are not discovered.  Prevention of blackholing a subset of
forwarded data because of excessive size is much less of a concern in
this context.  Hence the important message to define first is the one
that allows this discovery of topologically adjacent RBridges.  Since
we have done all of this work to define how to do this using IS-IS,
and the problem that arises is the padding of IS-IS hello messages,
the simplest approach is to eliminate this padding.

	I agree with the proposal, otherwise, as you've proposed it.

--
Eric

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

would

---

From: Radia Perlman <[email-masked]>
Date: Wed, 25 Mar 2009 12:08:22 -0700

I assume what you mean by "changing IS-IS" is the phrase "MUST NOT" pad 
hellos?
Or are you talking about adding a bit "I support the (to be specified) 
MTU discovery protocol"?
(or both perhaps).

Anyway, when you say "as was pointed out by James", I don't remember 
what comment you are
referring to, not sure which "James" we are talking about (James 
Carlson?) and don't know what
it means to "default to STP behavior". So can you just be specific about 
the protocol behavior you
are proposing, without referring to other things?

One thing you might be referring to is a proposal that I liked, and was 
in some version of the spec, but
got shot down by the WG (not sure I remember why), which is that the DRB 
election be the
spanning tree election, and you are DRB if and only if you manage to 
become root of the bridge
spanning tree. But that got shot down, and there would have needed to be 
another type of hello
anyway in order to do the IS-IS stuff, like giving the pseudonode a name.

But mostly, I just didn't understand your message...

Thanks,

Radia

---

From: Dinesh G Dutt <[email-masked]>
Date: Wed, 25 Mar 2009 12:39:25 -0700

Don,

> This is different behavior from every other system that I know of.  
L3 routers work exactly this way i.e. form adj on links with non-direct 
neighbors.

Dinesh

---

From: "Don Fedyk" <[email-masked]>
Date: Wed, 25 Mar 2009 16:13:37 -0400

> From: Dinesh G Dutt [mailto:[email-masked]] 
> Sent: Wednesday, March 25, 2009 3:39 PM
> To: Fedyk, Don (BL60:1A00)
> Cc: Radia Perlman; TRILL/RBridge Working Group
> Subject: Re: [rbridge] Proposed compromise for short/long hellos
> 
> Don,
> 
> Don Fedyk wrote:
> > Hi Radia
> >

You are missing the point. They don't forward data packets without
knowing about their neighbors. 

Don

---

From: James Carlson <[email-masked]>
Date: Wed, 25 Mar 2009 15:51:38 -0400

> Or are you talking about adding a bit "I support the (to be specified) 

Yes, I think that's what was meant.

> are proposing, without referring to other things?

Just to be clear: I was only trying to brainstorm possible solutions
to the MTU-caused problem that I had seen, and running STP in parallel
with TRILL was one of the possible solutions.  I quickly backed away
from it when several helpful folks pointed out that it was at best
untenable and at worst didn't actually fix the problem.

I think that having protective Hello messages is the best answer we
can have here.

-- 
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: "Don Fedyk" <[email-masked]>
Date: Wed, 25 Mar 2009 16:31:33 -0400

Hi Radia 

> From: Radia Perlman [mailto:[email-masked]] 
> Sent: Wednesday, March 25, 2009 3:08 PM
> Cc: TRILL/RBridge Working Group

Don't change the behavior applies to all of the above.  The point is you
are only using IS-IS as an MTU mismatch detection mechanism and that
does not address the root cause of the problem.  IS-IS currently
protects its own MTU integrity and that is all that is required. 

> are proposing, without referring to other things?

On Tuesday February 12th 2009 James Carlson wrote:
Thread [rbridge] potential L2 forwarding loop issue in RBridges

http://www.postel.org/pipermail/rbridge/2009-February/003238.html
"

 B.  Require RBridge implementations to include STP as well.
      However, the STP portion in this solution has (by design) no
      effect on TRILL itself.  Instead, we use STP's link "forwarding"
      state to gate the AF behavior in the following ways:

	i.  When STP reports that the link is not in "forwarding"
	    state, we refuse to become AF for any VLAN.  We become AF
	    only if STP reports "forwarding" for the link *and* the
	    DRB appoints us to do it.

	ii. When encapsulating from or decapsulating to native format,
	    examine both the AF flag and the STP state.  Discard the
	    packet if not AF or if STP state is not "forwarding."
"

> anyway in order to do the IS-IS stuff, like giving the 

I think defaulting to STP behavior of some form when you are connected
to Bridges is a necessary operation from where I stand.  

> But mostly, I just didn't understand your message...

In summary:
Don't change IS-IS because it is not an IS-IS issue. It is an RBridge
forwarding behavior that needs to be addressed within RBridge design
itself. Once you address that issue IS-IS will work with padded MTUs
just fine. 

Regards,
Don 

> Radia
<Snip>

---

From: "Don Fedyk" <[email-masked]>
Date: Wed, 25 Mar 2009 16:49:28 -0400

Hi James.  

> From: James Carlson [mailto:[email-masked]] 
> Sent: Wednesday, March 25, 2009 3:52 PM
> To: Radia Perlman
> Cc: Fedyk, Don (BL60:1A00); TRILL/RBridge Working Group

Understood why you proposed it. Why does it not fix the problem?  STP
Bridge default behavior is the safe option and RBridge is promoted to
RBridge forwarding only when it detects other RBridges.

Regards,
Don

---

From: "Anoop Ghanwani" <[email-masked]>
Date: Wed, 25 Mar 2009 14:01:51 -0700

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Radia Perlman
> Sent: Wednesday, March 25, 2009 12:08 PM
> To: Don Fedyk

I think he's referring to one of the options
discussed which was to have a big spanning tree
that spanned the entire TRILL campus and all of the
bridge islands that might need to be interconnected
by TRILL.  

(Don, please clarify if I am misrepresenting
what you wanted to say.)

However, I disagree that that is a good approach
because we will be stuck with dealing with STP 
convergence times before we can do anything useful
in the TRILL network.  STP can be very fast when
the network is small and failures are fairly localized,
but it gets worse as the network gets bigger.

Anoop

---

From: Erik Nordmark <[email-masked]>
Date: Wed, 25 Mar 2009 17:27:57 -0700

> knowing about their neighbors. 

IP routers do that for the last hop since they do not have an adjencency 
with all the hosts. That is why IP routers need to elect a designated 
router for multicast traffic; only one IP router can forward multicast 
packets to and from an IP subnet.

The TRILL case seems quite analogous; we need to elect a DRB to avoid 
multi-destination frames being decapsulated by one RBridge onto the link 
being picked and encapsulated by another RBridge.

    Erik

---

From: Donald Eastlake <[email-masked]>
Date: Wed, 25 Mar 2009 21:42:50 -0400

The decision not to default to STP behavior was made by the working
group some time ago.

Are there others who want to post an opinion on Radia's proposal? We
would like to close this expeditiously.

Thanks,
Donald

-- 
=============================
 Donald E. Eastlake 3rd   +1-508-634-2066 (home)
 155 Beaver Street
 Milford, MA 01757 USA
 [email-masked]
_______________________________________________
rbridge mailing list
[email-masked]
http://mailman.postel.org/mailman/listinfo/rbridge

---

From: "Don Fedyk" <[email-masked]>
Date: Wed, 25 Mar 2009 22:31:35 -0400

Hi Erik 

> From: Erik Nordmark [mailto:[email-masked]] 
> Sent: Wednesday, March 25, 2009 8:28 PM
> Cc: Dinesh G Dutt; TRILL/RBridge Working Group; Radia Perlman

You may be right here.  Radia mentioned a similar thing. 

Don

---

From: "Don Fedyk" <[email-masked]>
Date: Wed, 25 Mar 2009 22:30:59 -0400

Hi Anoop 

> From: Anoop Ghanwani [mailto:[email-masked]] 
> 
<snip>
> (Don, please clarify if I am misrepresenting

First I want to point out this is supposed to be an exception. MTUs
don't change by themselves but you may find you plug in some equipment
where you have an MTU problem. 

I'm thinking that Shortest Path Bridging can handle this on a neighbor
basis so why can't RBridge? Perhaps we should list the cases this is an
issue. James' (Jim's) example was rather straight forward and I could
not see why RBridge would not behave like a bridge.  But then you have a
LAN with some RBridges and some Bridges and I can't say I know all the
permutations.

Does this create a big bridged network? That was not my intention but
RBridges do link multiple spanning trees and there is a perhaps a danger
defaulting to anything other than a stub on a link if there is a
problem. 

Aside speaking with Radia it occurred to me Radia's proposals were to
adapt to smaller MTU on a link.  I believe you may be able to engineer a
network to a lower (or larger) MTU size but my understanding is all
IS-IS routers are expected to have the same ReceiveLSPBufferSize which
must be lower or equal than MTU anywhere which means adapting on the fly
for a specific link is probably not a good idea. So I'm not comfortable
with changing the way MTUs 

I found this thread on the subject.    
http://www.ietf.org/mail-archive/web/isis-update/current/msg00072.html

Regards,
Don

---

From: Kris Price <[email-masked]>
Date: Thu, 26 Mar 2009 17:13:15 +1300

> limit really really really creative appointments of lots of appointed 

Seems the only real solution if you want to still form adjacencies on a 
link and transmit on them without forming loops. (As opposed to just 
detecting a problem and disabling transmission onto that link.)

Does it cause any problems with other IS-IS PDUs, i.e. do not all PDUs 
need to be set to the same "maximum" size if you assume the network 
doesn't support the IS-IS specified size..

> b) have another type of mechanism, perhaps called "MTU discovery", which
[snip]
> c) we'd add a bit to the Hello saying "I support the MTU discovery protocol"

I've missed the need for the MTU discovery in this sitation, if the PDU 
size must be network wide, then...

Cheers
Kris

---

From: Kris Price <[email-masked]>
Date: Thu, 26 Mar 2009 17:20:04 +1300

Anoop Ghanwani wrote:
[snip]
> but it gets worse as the network gets bigger.

I'm not sure the convergence time of RSTP should be considered a problem 
given the target for RBridges, as long as the result is safe, and simple 
to work with.

The argument I've heard is if you want provider features (e.g. very fast 
convergence, more scalability than .1Q) go MPLS. I didn't think faster 
convergence and increased scalability was an aim for TRILL, but perhaps 
it creeped in.

What Don suggests (or a variation on it) appears more elegant, it may 
have been rejected, but IMHO it's often worth reconsidering some things 
in light of new information or changing circumstances.

As an aside, two totally off the cuff thoughts that may or may not help 
spark other useful ideas:

1. What about using a new, dedicated, RBridge bootstap/hello/protection 
protocol when RBridges start up?

  - very basic, sends small Hello's
  - on receipt of a Hello for which you do not have accompanying IIHs,
    stop transmissions out that port, fire off an "MTU error" and let
    the administrator sort it out.
  - If all links must support the IS-IS recieve buffer size then this
    seems the only option without modifying IS-IS...

2. Seems BFD could be used to cover the situation where an MTU changes.

  - Once a neighbour is discovered via the usual IS-IS Hello protocol,
    bootstrap up BFD to that neighbour. From that point on if your Hello
    hold timer lapses, but BFD is still up, you know the MTU has changed,
    and can disable transmission on the port, fire off an MTU error, etc.
  - Using BFD also provides nice fast failure detection, so maybe it
    alleviates some requirements for monitoring the BPDUs etc and
    waiting 30 seconds during a change even if there's no problem...
    (but I'm probably mistaken)
  - Having enough info to bootstrap BFD in the first place when IIH's
    are not getting through is an issue of course.

Cheers
Kris

---

From: Dinesh G Dutt <[email-masked]>
Date: Thu, 26 Mar 2009 02:51:31 -0700

Hi,

> (Don, please clarify if I am misrepresenting
If this is the suggestion Don F is making, I strongly disagree with this 
approach as well. Customers are moving to TRILL to get out of spanning 
tree for multiple reasons. An Rbridge terminating the STP and not 
creating a giant spanning tree was expressly liked by many people that I 
spoke to. In light of customers moving to larger L2 networks, creating a 
single giant spanning tree is a very bad idea.

Dinesh

---

From: "Ali Sajassi (sajassi)" <[email-masked]>
Date: Thu, 26 Mar 2009 10:08:51 -0700

Don,

As we have discussed, there are two issues in here related to this
corner case (legacy hubs between Rbridges): a) possibility of loop when
hello get discarded by interim hubs and b) black holing of data when
there is no MTU negotiation. 

Both of these issues can be addressed by the initial proposal on this
thread using a single hello type and then have a MTU discovery exchange.
So, if it can be addressed easily like that, then one would wonder why
to make the life more complicated and talk about introducing STP bridge
protocol.

> 
> I'm thinking that Shortest Path Bridging can handle this on a 
> neighbor basis so why can't RBridge? Perhaps we should list 
> the cases this is an issue. James' (Jim's) example was rather 
> straight forward and I could not see why RBridge would not 
> behave like a bridge.  But then you have a LAN with some 
> RBridges and some Bridges and I can't say I know all the permutations.
> 

The difference is that in case of 802.1aq as you know, the .1aq bridges
don't need interoperate over legacy bridges/switches (for optimum
forwarding). So, they don't from adjacencies and don't forward traffic.
Whereas, in here, the interoperability over legacy LAN is of interest.

Cheers,
Ali

---

From: Radia Perlman <[email-masked]>
Date: Thu, 26 Mar 2009 10:12:13 -0700

> size must be network wide, then...

Good point.
If there were fragmentation/reassembly like in theory there is with IP, 
it might make sense to have a network
with heterogeneous link length capacity.

Obviously we won't ever have that for layer 2.

Perhaps what MTU discovery could be used for is to not report 
adjacencies to neighbors where, for
whatever reason, the "network-wide" link length doesn't work.

Your question leads to other possible tweaks:
a) having RBridges (or at least the one RBridge with highest 
priority...) report what they believe the
network-wide MTU size is, in their LSP. Perhaps other RBridges might 
adjust their buffer sizes accordingly,
or something.
b) (I'm sure we don't want to do this, but for completeness probably 
should mention it): report in an LSP,
regarding an adjacency, what the MTU is. Then, in theory, packets that 
are too large could be routed on
links that have the right capacity, if such paths exist.

Radia

---

From: Donald Eastlake <[email-masked]>
Date: Thu, 26 Mar 2009 13:06:57 -0400

I would like to point out that there were three polls on Hellos during
the TRILL WG meeting:

   1. Should we add a TLV to Hellos with what the sender believes the
link MTU is? The response at the meeting was overwhelmingly positive
on this. So it will happen (probably actually a sub-TLV) unless there
is substantial opposition on the mailing list.

   2. Should at least some Hellos be padded? The response at the
meeting was exactly equally divided on this.

   3. Should there be one or two types of Hello? The response at the
meeting was a small majority in favor of one type of Hello.

Radia's proposal seems to me to be consistent with the spirit of the
responses to these last two polls: that many people want their to be a
facility for a padded MTU test message but most would prefer one type
of Hello. Of course, response on the mailing list could affect
judgement as to what the opinion of the WG is.

Donald

---

From: mike shand <[email-masked]>
Date: Thu, 26 Mar 2009 17:51:33 +0000

Radia Perlman wrote:

Kris Price wrote:

Cheers
Kris

Good point.

But then if that Rbridge goes away and some other Rbridge has a
different idea of the buffer size everyone has to change their buffer
sizes. I don't like that. Its all very well to have automatic
mechanisms, but sometimes a manual method is safer.

No No No don't even go there :-)

Mike

Radia

---

From: "Don Fedyk" <[email-masked]>
Date: Thu, 26 Mar 2009 14:09:01 -0400

Hi Ali 

> From: Ali Sajassi (sajassi) [mailto:[email-masked]] 
> Sent: Thursday, March 26, 2009 1:09 PM
> To: Fedyk, Don (BL60:1A00); Anoop Ghanwani; Radia Perlman
> Subject: RE: [rbridge] Proposed compromise for short/long hellos
> 
> 
> 
> Don,
> 

IS-IS does not support MTU negotiation.  The MTU is set and is
essentially must be the same everywhere.  There is some tolerance to
accepting larger messages (less than MTU) but the recommendation is any
node that cannot support the MTU the adjacency is lost. 
See
http://www.ietf.org/mail-archive/web/isis-update/current/msg00072.html 

If you wish to learn of RBridges by some other protocol/means and then
use IS-IS with all the same MTU then that would be OK.  But the proposal
to change IS-IS Hello messages changes IS-IS to a behavior it does not
support.  The reason is other bridges with larger MTU may have sent LSP
that cannot be exchanged on a lower MTU link. This is not like your PC
where you just negotiate a lower MTU. You have to change the whole
network or get rid of the MTU restriction.   

And then you have the question of what do you do when you are and
RBridge that cannot talk to another RBridge using IS-IS because but you
know it is out there?     I say for this case you must fall back to a
bridge compatible mode of operation for the portion of the spanning tree
that connects the adjacency.  

So to be clear the least you can do is:
1) Detect a lower MTU by some means. (MTU lower than the globally set
IS-IS configuration.) 
2) You cannot adapt a single RBridge to a lower MTU. (Within the current
IS-IS design over layer 2) 
3) And you need to take some action because you have to ensure that the
RBridges that know about each other but cannot exchange topology do not
mess up what they send. <- This peice is essential IMO. 

Regards,
Don

> thread using a single hello type and then have a MTU 

No see above.
> to make the life more complicated and talk about introducing 

No see above.
> forwarding). So, they don't from adjacencies and don't 
What 802.1aq does is form a Shortest Path Tree region dynamically. The
Region does not include legacy bridges but it forwards over them like a
VLAN Bridge. Two SPT reqions will forward traffic over a legacy Bridge.

> Whereas, in here, the interoperability over legacy LAN is of interest.
The difference is that Trill performs its adjacency over the legacy LAN.
(BTW .1aq can do this as well if we include shared interfaces but the
difference would be that the data plane would use VLAN translation to
the STP (or B-VLAN translation to the STP) at the legacy interfaces.
Trill uses an encapsualtion that is the difference.

Regards,
Don

---

From: James Carlson <[email-masked]>
Date: Thu, 26 Mar 2009 16:27:49 -0400

> is substantial opposition on the mailing list.

In terms of configuration information for the RBridge nodes
themselves, it's really a network-wide parameter.  Everyone has to
have the same MTU configured, or we're sunk.

We can't define things such that if you see a "bad" Hello, you fail to
establish an adjacency.  Doing that alone risks potential forwarding
loops by allowing multiple independent TRILL clouds (segregated only
by configured MTU) to attach to the same bridged core network.

It would work if the system with the smaller configured MTU was
required to disable itself on that port (at least until it no longer
sees Hello messages with a larger MTU).

However, that doesn't cover the case I was really worried about, which
is hidden MTU restrictions in the bridged network.  You can't catch
those by any new TLV: you have to send big packets and see when they
fail.

And if you have such a mechanism, it also happens to solve the problem
that the proposed new TLV in the Hello message solves, so that doesn't
seem necessary to me.

> meeting was exactly equally divided on this.

Something needs to be padded if we're going to detect MTU restrictions
automatically.  If it's not the Hello messages (the simpler solution,
I think), then it could be some brand new type of message that's
required to be exchanged in order for the port to be enabled.

> judgement as to what the opinion of the WG is.

As long as there's a mechanism, I don't care much what it is.

---

From: Kris Price <[email-masked]>
Date: Fri, 27 Mar 2009 10:32:41 +1300

>> size must be network wide, then...

Maybe this is more down to me missing something with IS-IS, I've just 
downloaded the ISO spec and had a quick squizz with some tired eyes, it 
looks to me (and seems to be confirmed by what people have said in some 
other emails) that:

- The recieve buffer must accept 1492 bytes on all routers.

- But you can control the size of what you send, IIHs, LSPs, by setting 
a smaller originateL1LSPbuffer size, the IIH's are paded up to that 
size. Any LSP you send will be limited to that size.

- Problem is, you still have to recieve an LSP that another router might 
generate that is 1492 bytes, and send it out your links as part of flooding.

So one very simple solution, as you suggested, define a maximum size 
limit in the draft. Leave it to implementors to define how to do it in 
IS-IS, but one obvious way is to permanently configure all the RBridges 
to set originate LSP buffers to that maximum size. That way no RBridge 
will generate an LSP larger than the limit. And IS-IS isn't changed to 
achieve that. (It's just a configuration adjustment)

I didn't follow the part about what to do when you discover a neighbour 
via the small un-padded IIH and form an adjacency. When a larger LSP 
comes along into one of your other interfaces, you can't flood it across 
that small link. So some information wouldn't be getting through on 
parts of the network. Sounded undesirable to me, but possibly it doesn't 
matter. If it does matter than adjacencies can only form when all 
routers agree on this LSP size.

Otherwise, is it the suggestion that an adjacency formed via a small 
IIH, but over a link later discovered to be smaller than the 1492 MTU, 
is a special case of adjacency? It's just used for DRB election...so if 
you don't implement MTU discovery...you never know its a special case?

I'm reading 4.2.4.1, it seems to indicate that MTU padding in Hellos is: 
"For purposes of constructing the campus routing topology, RB1 and RB2 
should only be considered adjacent if the largest TRILL data and IS-IS 
frames occurring in the campus can make it through Dev."

Not sure why it relates to TRILL data frames...surely the largest might 
be 9000 bytes in some parts of a TRILL campus? And wouldn't the relation 
to IS-IS frames be covered by virtue of the fact that 1492 bytes is 
specified in the IS-IS spec, so is this section still telling us anything?

Cheers
Kris

---

From: "Ali Sajassi (sajassi)" <[email-masked]>
Date: Thu, 26 Mar 2009 16:35:07 -0700

Hi Don,

> 
> IS-IS does not support MTU negotiation.  The MTU is set and 
> is essentially must be the same everywhere.  There is some 
> tolerance to accepting larger messages (less than MTU) but 
> the recommendation is any node that cannot support the MTU 
> the adjacency is lost. 
> See

I see what you saying but my point is that if this issue can be resolved
with a simple tweak of IS-IS, then adding a completely separate protocol
such as STP, is overkill to say the least.

> If you wish to learn of RBridges by some other protocol/means 
> and then use IS-IS with all the same MTU then that would be 
> OK.  But the proposal to change IS-IS Hello messages changes 
> IS-IS to a behavior it does not support.  The reason is other 
> bridges with larger MTU may have sent LSP that cannot be 
> exchanged on a lower MTU link. This is not like your PC where 
> you just negotiate a lower MTU. You have to change the whole

I would assume when you impose MTU restrictions, it will not be just for
hello messages but for all IS-IS messages including LSPs. So, when you
change the hello to a given MTU size, this MTU size should apply to
everything.

Cheers,
Ali
 
> And then you have the question of what do you do when you are 
> and RBridge that cannot talk to another RBridge using IS-IS 
> because but you
> bridge compatible mode of operation for the portion of the 
> spanning tree that connects the adjacency.  
> 
> 1) Detect a lower MTU by some means. (MTU lower than the 
> globally set IS-IS configuration.)
> 2) You cannot adapt a single RBridge to a lower MTU. (Within 
> the current IS-IS design over layer 2)
> 3) And you need to take some action because you have to 
> ensure that the RBridges that know about each other but 
> cannot exchange topology do not mess up what they send. <- 
> This peice is essential IMO. 
> 
> Regards,
> Don
>  
> 
> > 
> > to make the life more complicated and talk about introducing STP 
> > bridge protocol.
> 
> No see above.
> > 
> >  
> > > 
> > > neighbor basis so why can't RBridge? Perhaps we should list the 
> > > cases this is an issue. James' (Jim's) example was rather 
> straight 
> > > forward and I could not see why RBridge would not behave like a 
> > > bridge.  But then you have a LAN with some RBridges and 
> some Bridges 
> > > and I can't say I know all the
> > permutations.
> > > 
> > 
> > The difference is that in case of 802.1aq as you know, the .1aq 
> > bridges don't need interoperate over legacy bridges/switches (for 
> > optimum forwarding). So, they don't from adjacencies and 
> don't forward 
> > traffic.
> What 802.1aq does is form a Shortest Path Tree region 
> dynamically. The Region does not include legacy bridges but 
> it forwards over them like a VLAN Bridge. Two SPT reqions 
> will forward traffic over a legacy Bridge.
> 
> 
> (BTW .1aq can do this as well if we include shared interfaces 
> but the difference would be that the data plane would use 
> VLAN translation to the STP (or B-VLAN translation to the 
> STP) at the legacy interfaces.

---

From: Donald Eastlake <[email-masked]>
Date: Fri, 27 Mar 2009 11:47:31 -0400

See below....

> have the same MTU configured, or we're sunk.

Well, if the MTU is low enough and IS-IS control frames are big enough
that some of them get lost, then I'd say we're probably sunk. If all
IS-IS control messages get through but some large data frames are
lost, it's bad, but not as bad. And keep in mind that IS-IS control
frames are limited because of their LSAP encoding. So without a
substantial change in the TRILL IS-IS frame encoding, you're not going
to see any jumbo IS-IS control frames.

> by configured MTU) to attach to the same bridged core network.

I don't think the danger relates to adjacencies, I think it's related
to being an uninhibited appointed forwarder.

> sees Hello messages with a larger MTU).

Yes, inhiibiting appointed forwarder status is what you need to do for safety.

> those by any new TLV: you have to send big packets and see when they

An advantage of Radia's proposal is that the MTU probe message is,
presumably, not an IS-IS frame so it can be as big as any existing
devices will handle, such as a 9K byte jumbo frame.

> that the proposed new TLV in the Hello message solves, so that doesn't

You are probably right.

> required to be exchanged in order for the port to be enabled.

As above, IS-IS Hellos can not be padded beyond the traditional
Ethernet limit, plus tags.

Thanks,
Donald

---

From: "Anoop Ghanwani" <[email-masked]>
Date: Fri, 27 Mar 2009 16:04:07 -0700

Just responding to the thread in general and not
any specific post...

I think it makes sense to use the non-padded
Hellos just because it is critical that they
be seen.  If they are not seen, what could
result is a loop which is very bad.

As a result of not padding the Hellos, we would
lose the MTU discovery/validation benefit of
L3 IS-IS.  For that, we can probably define
a new message.

If we continue to pad messages, we could 
get loops as observed by Jim.  We could define
a new message/protocol specifically to detect
such scenarios, but I personally think it is 
safer to prevent such a scenario by having it
built into the core of the protocol.

Anoop

---

From: Radia Perlman <[email-masked]>
Date: Sat, 28 Mar 2009 09:44:50 -0700

Yes. Simply not padding hellos seems like the simplest, safest thing for 
assuring the Hellos get through.
As someone else pointed out, though, bad things (other than
dropping large data packets) might happen if the MTU on the link was 
misconfigured,
and control messages like CSNPs and LSPs didn't get through. So it seems 
quite important that
we also define the "MTU discovery" protocol. That protocol should at 
least be a SHOULD rather
than a MAY". It should be a very simple protocol.

I also believe it is a good idea to have the highest priority router's 
LSP dictate the MTU size
on the campus, and RBridges attached to a link that can't meet that MTU 
requirement would
not report those links in their LSPs.

I think Don said that at the meeting there was "overwhelming support" 
for adding a TLV to the
hello saying what the MTU size was. I don't remember that, but I also 
think at the meeting some
people thought that including a TLV for what you think the MTU size is 
completely replaced
the padding of hellos mechanism. It doesn't. And since I believe we need 
a mechanism of
sending padded messages and seeing if they get through (the "MTU 
discovery protocol"), putting
a TLV for "I think the MTU size is x" doesn't really add anything.

So to summarize what I think we should do:
a) say Hellos MUST NOT be padded
b) add a flag for "I support the MTU discovery protocol" to the Hello
c) add a TLV in the LSP for "I think the campus-wide minimum MTU size 
for a link is x"
d) specify a simple MTU discovery protocol which would be a message that
is never forwarded by an RBridge, and which is padded to the size you want
to test, and includes the size in the data, and an RBridge R2 that receives
such a message from neighbor R1 (whether the message was unicast by R1
to R2, or multicast by R1 on the link) acknowledges with the size in the 
message:
"I received your MTU discovery message with size q"
e) if R1 doesn't receive an ack from R2 after sufficiently many MTU 
discovery
messages, R1 drops the adjacency to R2.

Radia

---

From: "Don Fedyk" <[email-masked]>
Date: Mon, 30 Mar 2009 09:52:40 -0400

Hi Radia

I'm having trouble understanding if this really fixes the problem or
just handles one case of IS-IS adjacency failure due to small MTU. 
What happens after point e) when the adjacency drops?  What is the
forwarding behavior of the RBridges that realizes they cannot form an
adjacency? 

I think what I'm hearing is the forwarding behavior/treatment of an
interface when there is an RBridge that knows they cannot form an
adjacency is different than when RBridges do not know any adjacency
exists and that seems problematic to me.  

Regards, 
Don

---

From: Radia Perlman <[email-masked]>
Date: Tue, 31 Mar 2009 03:25:13 -0700

I may have the terminology wrong -- but when I say "R1 drops the 
adjacency to R2" what I
mean is:

a) In R1's Hellos, R1 no longer lists R2 as a neighbor
b) In R1's LSP, R1 no longer lists a link to R2
c) If it's a pseudonode that connects R1 and R2, then as a consequence 
of R2 not appearing in
R1's Hellos, R2 does not report a link to the pseudnode in R2's LSP.
d) Because the LSPs do not indicate a link between R1 and R2, no paths 
will be computed
by any RBridges that go through R1-R2.

Radia

---

From: mike shand <[email-masked]>
Date: Tue, 31 Mar 2009 13:32:02 +0100

Radia,

I really don't see how this works. When R1 no longer lists R2 as a
neighbor, then the adjacency goes down. But if the adjacency goes down
the DRB election doesn't happen and we are back to the loop. So you
must somehow mean that the adjacency stays UP as far as DRB election is
concerned and DOWN as far as advertising in the LSPs is concerned.

So are you proposing changing the DRB election procedure so that it
doesn't require an adjacency?

i.e you elect it from among the hellos that you see on the LAN even if
they don't report mutual connectivity?

I really don't understand how these dual adjacency types are supposed
to work.

Mike

Radia Perlman wrote:

Radia

Don Fedyk wrote:

Hi Radia

Regards,
Don

So to summarize what I think we should do:
a) say Hellos MUST NOT be padded
b) add a flag for "I support the MTU discovery protocol" to the Hello
c) add a TLV in the LSP for "I think the campus-wide minimum MTU size
for a link is x"
d) specify a simple MTU discovery protocol which would be a
message that
is never forwarded by an RBridge, and which is padded to the
size you want
to test, and includes the size in the data, and an RBridge R2
that receives
such a message from neighbor R1 (whether the message was unicast by R1
to R2, or multicast by R1 on the link) acknowledges with the
size in the
message:
"I received your MTU discovery message with size q"
e) if R1 doesn't receive an ack from R2 after sufficiently many MTU
discovery
messages, R1 drops the adjacency to R2.

Radia

Anoop Ghanwani wrote:

Anoop

---

From: Radia Perlman <[email-masked]>
Date: Tue, 31 Mar 2009 08:45:32 -0700

I *do* mean that R2 defers to R1 for DRB even if R1 doesn't list R2 in 
its Hello.
This is the same behavior that has to work  in TRILL if, for instance, 
R2 cannot communicate on
the Designated VLAN.

If R2 can hear R1, and R1 has a better priority for being DRB, then R2 
does not
attempt to become DRB even if R1 is refusing to acknowledge R2's 
existence, and
therefore they don't form an adjacency.

I'd be somewhat surprised if (layer 3) IS-IS behaves differently. If R2 
hears
R1's Hellos, and R1 is most qualified as DRB, but for whatever reason 
does not
list R2 in R1's Hellos, I assume that R2 does not attempt to become a 
separate DRB.
But even if that's how IS-IS has evolved since DECnet (that was the 
behavior I always
assumed in that case), for TRILL it has to behave the way that I said. 
It is dangerous
to have two DRBs on a link, so if R2 knows that R1 is "more qualified" 
to be DRB, then
R2 has to defer to R1, even if it does not have "an adjacency" to R1.

Radia

mike shand wrote:
> must somehow mean that the adjacency stays UP as far as DRB election 
> is concerned and DOWN as far as advertising in the LSPs is concerned.
>
> ------------------------------------------------------------------------
>

---

From: Donald Eastlake <[email-masked]>
Date: Tue, 31 Mar 2009 16:27:17 -0400

See below...

2009/3/31 mike shand <[email-masked]>:
> neighbor, then the adjacency goes down. But if the adjacency goes down the
> DRB election doesn't happen and we are back to the loop. So you must somehow
> mean that the adjacency stays UP as far as DRB election is concerned and
> DOWN as far as advertising in the LSPs is concerned.
>
> So are you proposing changing the DRB election procedure so that it doesn't
> require an adjacency?

Why do you believe the DRB (aka DIS) election has anything to do with
whether or not an adjacency has been established? The "DRB election
procedure" is, logically, just that each RB keeps around the headers
of the LAN Hellos it has received from each other RB on the link,
compares fields in those headers, decides for itself whether or not it
is DRB, and acts accordingly. I don't see how this has anything to do
with whether or not IS-IS Neighbor TLVs were in those Hellos or
whether those Neighbor TLVs were been filled-in and exchanged in such
a way as to establish an adjacency.

Thanks,
Donald

> i.e you elect it from among the hellos that you see on the LAN even if they
> don't report mutual connectivity?
>
> I really don't understand how these dual adjacency types are supposed to
> work.
>
>     Mike
>
>
> Radia Perlman wrote:
>

---

From: Kris Price <[email-masked]>
Date: Wed, 01 Apr 2009 12:09:11 +1300

Radia,

> R1's Hellos, R2 does not report a link to the pseudnode in R2's LSP.

So in this case the network could partition? It considers itself not to 
have an adjacency and so therefore won't flood LSPs. This link won't be 
used to forward data frames either.

If I have intuited right an RBridge discovers the MTUs on its links, and 
reports the smallest in a new TLV. When an RBridge recieves one of these 
TLVs with a smaller MTU than it was using for its originated LSPs, it 
adopts this new smaller MTU. And this is to allow the network to heal 
any partitions. Is this what you mean?

If this isn't the case, or an RBridge gives up on forming an adjacency, 
networks may find themselves partitioned by these small MTU links. If a 
network is partitioned because of this, is that detected and reported?

And if we're not using the MTU discovery to ensure the network heals and 
partitions don't occur (as I thought I understood it), then why use it 
at all, and not simplify things. Better to fail explicitly and all that. 
Also.. do things end up being a bit shakey until the network has settled 
down to this minimum MTU..? LSPs dropped, not acknowledged, etc.

Regards
Kris