Subject: Re: [rbridge] [Isis-wg] Why is MTU discovery important?

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Tue, 7 Apr 2009 02:13:29 -0700

Radia -

The point of hello padding is not just to "discover the MTU" but to not
form adjacencies with neighbors who are incapable of receiving/flooding
the max size LSP any router in the area/domain might generate. 

I haven't caught up on the details of Jim's testing, but if the padded
hellos can't get through then similar sized LSPs won't either - and
routing is broken - so sending smaller hellos isn't going to help - and
in fact is likely to obfuscate things because routing may work at first,
but as additional information is added to an LSP it will become too
large to be flooded everywhere and things will break w/o any clear
indication of why.

    Les

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
Behalf
> Of Radia Perlman
> Sent: Monday, April 06, 2009 3:44 PM
> To: [email-masked]
> Subject: [Isis-wg] Why is MTU discovery important?
> 
> For those of you not monitoring the TRILL mailing list:
> 
> Jim Carlson, in testing his TRILL implementation, noticed that the
> padded Hellos caused RBridges not to discover each other.
> That's real bad in TRILL, though it's OK in layer 3 IS-IS.
> 
> So, we'd like to just say in TRILL "don't pad Hellos".
> 
> But that eliminates IS-IS's MTU discovery mechanism. We had a proposal
> for doing that, but some people said
> "why bother"?
> 
> The reasoning is that it's not clear what an RBridge would do if the
MTU
> isn't what it would expect, and that
> it seems like you'd need a campus-wide agreed-upon MTU size in order
to
> make sure LSPs would get through on
> every link. The solutions being proposed involved agreeing upon a
> campus-wide MTU size, testing MTU size on
> each adjacency through some as-yet-to-be-defined protocol, and not
> reporting links that don't meet
> that MTU size.
> 
> Obviously ignoring the MTU issue, and just making sure Hellos get
> through by not padding Hellos, is a nice simple proposal.
> 
> What would we be giving up if we ignored MTU discovery entirely?
> 
> Radia
> _______________________________________________
> Isis-wg mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/isis-wg

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

---

From: James Carlson <[email-masked]>
Date: Tue, 7 Apr 2009 10:56:45 -0400

> the max size LSP any router in the area/domain might generate. 

I suspect that for practical purposes, those work out to be the same
thing.  Regardless of how exactly it may happen in a given deployment,
there are scenarios in which packets larger than a certain arbitrary
size cannot make it through, and that problem must be detected.

The problem in this case is that with TRILL, failing to detect an
actual adjacency that exists on the wire means that (unlike IS-IS for
L3 networks), you will begin forwarding on *both* (or "all") nodes,
and inadvertently create L2 forwarding loops for all packets with size
less than that restriction.

With L3 routing, having Hello fail between connected nodes is safe and
obvious enough.  The peers are not considered adjacent, and no traffic
flows.  With L2 TRILL bridging, forwarding becomes enabled on both,
having the Hello fail is toxic and potentially fatal for all involved.

> large to be flooded everywhere and things will break w/o any clear

The proposal is actually two-fold:

  - Smaller Hellos to make sure that actual adjacencies are detected
    and L2 loops do not form.

  - Some other simple protocol (such as an echo request/response using
    MTU-padded messages) to validate MTU between known peers.

The first part fixes the forwarding path danger.  The second part
fixes the LSP size concerns.

-- 
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: Radia Perlman <[email-masked]>
Date: Tue, 07 Apr 2009 13:10:26 -0700

OK. It's clear we should NOT pad Hellos.

It also seems like enough people would feel uncomfortable with not doing 
MTU discovery that we should make
sure there is a mechanism for that also.

So can we focus for a minute on the following question, "whether to make 
MTU size a forever constant,
or configurable in a campus", as described below.

The simplest option is to pick some minimum size, say 1450 bytes, put 
that in the spec now, and forever
say that TRILL Hellos and LSPs cannot be bigger than that.
MTU discovery would be done to ensure that
every link can handle 1450 bytes, and not use (not report in LSPs) links 
that can't handle that.

However, my preference is to have an optional TLV in the LSP that says 
"campus-wide MTU size". This TLV
would only be relevant if:
a) it is larger than 1450, and
b) it is in the LSP of the highest priority RBridge in the campus.

If we put that in, then we would be enabling TRILL campuses that support 
jumbo frames.

The rule is that if the highest priority RBridge says MTU size should be 
10000 bytes, then all RBridges would adjust
their buffer sizes, and test their adjacencies to ensure they could 
handle 10000 bytes, and if they don't
then stop reporting those links (just like they would with the simpler 
proposal if the links
couldn't support 1450).

---

From: Dinesh G Dutt <[email-masked]>
Date: Tue, 07 Apr 2009 14:29:54 -0700

Radia,

What I don't understand is how L3 IS-IS solves this problem. Consider a 
trivial topology where three routers are connected thus:
             R1 --- R2 --- R3

Let's say the link between R1 and R2 has an MTU, M1, and the link 
between R2 and R3 has an MTU, M2. Let M1 > M2. Even with padded Hellos, 
how is the problem of R1 sending an LSP that exceeds M2 (but not M1) 
handled ?

Dinesh

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

---

From: Radia Perlman <[email-masked]>
Date: Tue, 07 Apr 2009 14:58:59 -0700

Dinesh,

In IS-IS there is a hard limit MTU size, say 1472 or whatever. MTU
discovery through padded Hellos is done to ensure that adjacencies that
can't support that size don't get established.
If M2 is too small, then R2-R3 would not form an adjacency, and
as a result data, LSPs, etc., would not be sent over the link.

So, likewise, in TRILL we'll enforce a minimum link size, and the 
question I was asking was whether
it should be a constant forever (say 1450 types), or whether we can 
allow a TRILL campus to be configured
to require all the links to have some higher-than-1450 link size?

Radia

Dinesh G Dutt wrote:
> Radia,
>
> What I don't understand is how L3 IS-IS solves this problem. Consider 
> a trivial topology where three routers are connected thus:
>             R1 --- R2 --- R3
>
> between R2 and R3 has an MTU, M2. Let M1 > M2. Even with padded 
> Hellos, how is the problem of R1 sending an LSP that exceeds M2 (but 
> not M1) handled ?
>
> Dinesh
> Radia Perlman wrote:
>> It also seems like enough people would feel uncomfortable with not 
>> doing MTU discovery that we should make
>> So can we focus for a minute on the following question, "whether to 
>> make MTU size a forever constant,
>> every link can handle 1450 bytes, and not use (not report in LSPs) 
>> links that can't handle that.
>>
>> However, my preference is to have an optional TLV in the LSP that 
>> says "campus-wide MTU size". This TLV
>> If we put that in, then we would be enabling TRILL campuses that 
>> support jumbo frames.
>>
>> The rule is that if the highest priority RBridge says MTU size should 
>> be 10000 bytes, then all RBridges would adjust
>> then stop reporting those links (just like they would with the 
>> simpler proposal if the links
>> couldn't support 1450).
>>
>>
>>
>>

---

From: Donald Eastlake <[email-masked]>
Date: Tue, 7 Apr 2009 18:01:17 -0400

Keep in mind that all IS-IS messages are LSAP encoded so they are
limited to the classic Ethernet MTU, possibly plus VLAN and/or other
tags. So if, for example, you wanted to be sure you could correctly
handle Fiber Channel over Ethernet frames, which are bigger than that,
there is no way for padded Hellos to help, since they can't be padded
up to FCoE frame size.

Donald

-- 
=============================
 Donald E. Eastlake 3rd   +1-508-634-2066 (home)
 155 Beaver Street
 Milford, MA 01757 USA
 [email-masked]

---

From: "Sina Mirtorabi (smirtora)" <[email-masked]>
Date: Tue, 7 Apr 2009 14:57:58 -0700

Radia,

The minimum size packet is what I proposed and I think it is the easiest
solution to go forward. We should also allow for higher size packet if
there is a mechanism to safely enable that.
Now it is not because somebody (the highest priority Rbridge) to tell
you what to do that you have to blindly follow, but if everybody
announce that jumbo value then you can safely move to that value.
So here what we can do:

Put an originatingLSPBufferSize in a TLV when generating LSP and (ISO
10589:2002) already recommend that. The default value would be 1450
otherwise it is set to the configured value.
An Rbridge can start generating a non-default size X LSP if all the
reachable Rbridge has announce at least a value >= X, in other word the
non-default size LSP is set to the minimum of all announced LSP size.

Note that for a non-default size LSP, we rely on the administrator's
configuration and we don't actually check the MTU path. If later there
is a mechanism to actually check the MTU of a Rbridge link, then
originatingLSPBufferSize could be set to the minimum MTU size of all
local Rbridge's link. This will guarantee that the LSP size will always
be set to the minimum MTU size of any link.

Thanks
Sina

> support
> be

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Tue, 7 Apr 2009 15:48:26 -0700

Dinesh -

This problem has been addressed in ISO 10589:2002 - though admittedly
the solution is not commonly implemented. 

The solution involves the advertisement of originatingL1LSPBufferSize/
originatingL2LSPBufferSize in LSP #0. Each system can then compare the
received value to its locally configured value and detect mismatches.

The TLV codepoint for this is: LSPBufferSize 14.

There is a good discussion of the issues about this - as well as hello
padding - RFC 3719 Sections 5 and 6.

   Les

> From: [email-masked] [mailto:[email-masked]]
On
> Behalf Of Dinesh G Dutt (ddutt)
> Sent: Tuesday, April 07, 2009 2:30 PM
> To: Radia Perlman
> Cc: TRILL/RBridge Working Group; [email-masked]
> Subject: Re: [rbridge] [Isis-wg] Why is MTU discovery important?
> 
> Radia,
> 
a
> between R2 and R3 has an MTU, M2. Let M1 > M2. Even with padded
Hellos,
> > It also seems like enough people would feel uncomfortable with not
doing
> > So can we focus for a minute on the following question, "whether to
make
> > every link can handle 1450 bytes, and not use (not report in LSPs)
links
> > However, my preference is to have an optional TLV in the LSP that
says
support
> > then stop reporting those links (just like they would with the
simpler

---

From: Donald Eastlake <[email-masked]>
Date: Tue, 7 Apr 2009 20:45:26 -0400

My point was that if you are using a network heavily for some protocol
where an MTU of X is the most efficient, if there was, say, one link
with MTU Y, Y<X, it might be better to just exclude that link than to
invoke whatever mechanism the protocol has to deal with a
less-than-most-efficient MTU.

Donald

On Tue, Apr 7, 2009 at 7:22 PM, sgai <[email-masked]> wrote:
> FCoE has its own MTU protection.
>
> -- Silvano
>
>
> On 4/7/09 3:01 PM, "Donald Eastlake" <[email-masked]> wrote:
>

---

From: David Ward <[email-masked]>
Date: Wed, 8 Apr 2009 12:09:38 -0500

All -

This discussion is rapidly defining !IS-IS as a solution given the  
changes to the protocol. At least enough of the protocol is being  
changed that we need to consider a new version designator as the  
direction is fundamentally changing adj formation, DIS election, LSP  
size, etc and compatibility with current ISIS doesn't seem a goal.   
I'd like to push the brakes just a bit to try and get us into better  
sync.

There are proposals that the Hellos should NOT be padded to  eliminate  
a cause of multiple rbridges on the same LAN "not seeing each other"  
and electing multiple forwarders. However, the idea in the discussion  
is to remove the required MTU checking and it is proposed (which I  
don't understand) to introduce another "MTU discovery" protocol  to  
restore this awareness.

As we know,  IS-IS requires that the DIS is elected from among the  
routers that have adjacencies  (that report the existence of each  
other in the IIHs, and it requires that the IIHs are padded to the  
maximum of the link MTU and the originating L1LSPBufferSize - in the  
case of L1). This ensures both that the link is capable of  
transferring data packets of link MTU size, and more  that it is  
capable of transferring LSPs of the appropriate network wide size. If  
this were not the case, then it is possible that a DIS could get  
elected which was not capable of operating the reliable update  
process, and could cause certain LSPs to fail to be propagated across  
the LAN.

The DRB is the TRILL equivalent of the DIS. This is elected from among  
the routers connected to the LAN and is responsible for:
       a) generating a pseudonode LSP, which claims connectivity to  
all the other routers it sees on the LAN. (and in the OSI case reports  
the ESs on the LAN)
       b) running the LAN reliable update process (i.e. periodically  
sending CSNPs etc)

So the padding is required in order to ensure that IS-IS operates  
correctly. The problem is that the roll of the DIS (aka DRB) is  
defined in terms of adjacency formation, and I don't understand how  
the two distinct roles for the DRB  can be combined into a single DRB.  
Again, I've followed and read the TRILL and ISIS  but, I am not seeing  
a way to combine the functions into a single DIS/DRB at this point.

My view (which others have stated earlier) is that the L2ISIS desired  
functionality  should not mess with the existing IS-IS DIS election  
mechanisms, but should have another set of "hellos" which can be used  
for the TRILL specific DRB elections, and have the appropriate rules  
for that. Or, we at least need to write down the rules and explore how  
to combine them.

There appears only one way out of this:

- TRILL WG should write down the specific requirements and  
functionality are and what the "rules" should be for them. We may find  
ISIS is suited to meet them or not.

Thanks

-DWard

Note that if the requirement is that TRILL needs to operate in  
environments with different or "variable" (though static) MTUs, we  
should not hack an easy solution but, create a generalized solution

On Apr 7, 2009, at 3:10 PM, Radia Perlman wrote:

> The simplest option is to pick some minimum size, say 1450 bytes,  
> put that in the spec now, and forever
> The rule is that if the highest priority RBridge says MTU size  
> should be 10000 bytes, then all RBridges would adjust

---

From: Radia Perlman <[email-masked]>
Date: Wed, 08 Apr 2009 11:36:09 -0700

Dave,

I think a lot of the controversy is due to overloaded terminology, and 
using words that people have preconceived notions for.
One term that seems to be confusing people is the term "Forming adjacency".

"Forming adjacency" is a term that implies a bunch of steps to
layer 3 IS-IS people that the TRILL people (including me) are
not implying all the steps of.
So it's possible that TRILL people should not use the term "forming 
adjacency"
in emails describing protocols, or perhaps the layer 3 IS-IS people could
try not to read too much into that phrase and instead just follow 
through all the described steps in the
protocol being proposed.

"Designated DRB" is two functions in TRILL, where it's only the second 
function in layer 3 IS-IS:

a) the one that serves specific TRILL purposes: deciding who should be 
the Designated Forwarder for each VLAN
so there are no loops, deciding on Designated VLAN for inter-RBridge 
communication, etc.
b) the IS-IS specific stuff: naming the pseudonode, sending CSNPs

In TRILL it is *essential* to get the first thing robust, i.e., never 
having multiple forwarders. In layer 3 IS-IS, it's
OK to have multiple DRs. In TRILL it is *fatal*.
So the first thing TRILL has to do is to get that right. The solution,
fortunately, is easy :

. Unpadded Hellos.
. Choosing DRB regardless of 2-way connectivity, MTU, etc.

This is (and *must* be) different from the way layer 3 IS-IS happens to 
work.
Regardless of philosophical discussions that we could carry on forever 
about whether this makes TRILL a
different protocol, different version of the protocol, whatever....it is 
clear that is what TRILL needs to do.
I have no objection to no longer calling the TRILL routing protocol 
"IS-IS" if that is considered "too big
a change" from layer 3 IS-IS. But we have to do the obvious correct 
technical thing for TRILL.

The other thing that seems to be confusing people is the term "Hello 
protocol".
The Hellos in layer 3 IS-IS have two purposes:
a) checking MTU size
b) finding neighbors, choosing DR

TRILL is just separating the two functions (choosing DRB, and testing 
MTU size), and calling it
two different protocols; the "Hello" and the "MTU probe protocol". Layer 
3 people could just think of
it as a terminology change. It seems cleaner to call it two different 
protocols, since they are
serving two very different functions. Having one protoocol that does 
both, the way it is today
in layer 3 IS-IS, DOES NOT WORK FOR TRILL. And it's much simpler to 
think about
the two problems individually, and make sure we get them both right. If 
you like, we can
call the MTU probe protocol "padded Hellos", but let's first make sure 
we are getting
both protocols correct. Even if we call the MTU probe protocol "padded 
Hellos", the
padded Hello protocol MUST NOT have any influence on the "choosing a 
Designated
DRB" (the thingy in TRILL that ensures there is only a single Designated 
Forwarder
per VLAN on the link).

The technical issues (ignoring terminology) that are being discussed for 
variants of the "MTU probe
protocol" are:
a) whether to ignore MTU probing entirely, because it's simpler to
just ignore it, and just ensure that
there is only one DRB on the link: and live with occasionally LSPs, 
CSNPs, data packets, not
getting through on some link (which in TRILL is FAR less serious than 
having multiple forwarders)
b) whether to make MTU probing just test that the link meets the 
criteria of the permanent
fixed minimum size of 1450, or whatever, or whether to allow campuses to 
have a different
campus-wide minimum link size S, and have RBridges test that their links 
can handle size "S"
in the probing protocol, rather than "1450". Regardless of what the size 
is, and how that
size is determined, it's clear what should happen if a link doesn't meet 
size S. The link
should not be considered part of the topology -- routes should not be 
computed that
traverse such a link.

Radia

David Ward wrote:
>       a) generating a pseudonode LSP, which claims connectivity to all 
> the other routers it sees on the LAN. (and in the OSI case reports the 
> ESs on the LAN)

---

From: David Ward <[email-masked]>
Date: Thu, 9 Apr 2009 10:53:46 -0500

Radia -

Thanks for the note.

It's best that we capture these requirements in more than the email  
thread and with a bit more detail and put it in some doc or another.  
What would be helpful is if there is a bit of state machine  
diagramming on how adj are formed, DRB election, finding neighbors,  
PSNP optimizations, LSP size/fragmentation, etc.

  Note that it is moderately interesting that 802.1.aq isn't asking   
for this functionality. Given the ISIS WG can be considered the  
stuckkey between the two technologies; we'll have to sort this all  
out.  My goal is for one solution for carrying L2 in IS-IS *if* IS-IS  
can meet the requirements.

-DWard

On Apr 8, 2009, at 1:36 PM, Radia Perlman wrote:

> Dave,
>
> I think a lot of the controversy is due to overloaded terminology,  
> and using words that people have preconceived notions for.
> "Designated DRB" is two functions in TRILL, where it's only the  
> second function in layer 3 IS-IS:
>
> a) the one that serves specific TRILL purposes: deciding who should  
> be the Designated Forwarder for each VLAN
> In TRILL it is *essential* to get the first thing robust, i.e.,  
> never having multiple forwarders. In layer 3 IS-IS, it's
> This is (and *must* be) different from the way layer 3 IS-IS happens  
> to work.
> Regardless of philosophical discussions that we could carry on  
> forever about whether this makes TRILL a
> different protocol, different version of the protocol,  
> whatever....it is clear that is what TRILL needs to do.
> TRILL is just separating the two functions (choosing DRB, and  
> testing MTU size), and calling it
> two different protocols; the "Hello" and the "MTU probe protocol".  
> Layer 3 people could just think of
> it as a terminology change. It seems cleaner to call it two  
> different protocols, since they are
> the two problems individually, and make sure we get them both right.  
> If you like, we can
> call the MTU probe protocol "padded Hellos", but let's first make  
> sure we are getting
> both protocols correct. Even if we call the MTU probe protocol  
> "padded Hellos", the
> DRB" (the thingy in TRILL that ensures there is only a single  
> Designated Forwarder
> per VLAN on the link).
>
> The technical issues (ignoring terminology) that are being discussed  
> for variants of the "MTU probe
> protocol" are:
> getting through on some link (which in TRILL is FAR less serious  
> than having multiple forwarders)
> fixed minimum size of 1450, or whatever, or whether to allow  
> campuses to have a different
> campus-wide minimum link size S, and have RBridges test that their  
> links can handle size "S"
> in the probing protocol, rather than "1450". Regardless of what the  
> size is, and how that
> size is determined, it's clear what should happen if a link doesn't  
> meet size S. The link
> should not be considered part of the topology -- routes should not  
> be computed that
> traverse such a link.
>
> Radia
>
>
>
>
>
>
> David Ward wrote:
>>
>>
>> All -
>>
>> direction is fundamentally changing adj formation, DIS election,  
>> LSP size, etc and compatibility with current ISIS doesn't seem a  
>> goal.  I'd like to push the brakes just a bit to try and get us  
>> into better sync.
>>
>> There are proposals that the Hellos should NOT be padded to   
>> eliminate a cause of multiple rbridges on the same LAN "not seeing  
>> each other" and electing multiple forwarders. However, the idea in  
>> the discussion is to remove the required MTU checking and it is  
>> proposed (which I don't understand) to introduce another "MTU  
>> discovery" protocol  to restore this awareness.
>>
>> maximum of the link MTU and the originating L1LSPBufferSize - in  
>> the case of L1). This ensures both that the link is capable of  
>> capable of transferring LSPs of the appropriate network wide size.  
>> If this were not the case, then it is possible that a DIS could get  
>> process, and could cause certain LSPs to fail to be propagated  
>> across the LAN.
>>
>> The DRB is the TRILL equivalent of the DIS. This is elected from  
>> among the routers connected to the LAN and is responsible for:
>> all the other routers it sees on the LAN. (and in the OSI case  
>> reports the ESs on the LAN)
>> the two distinct roles for the DRB  can be combined into a single  
>> DRB. Again, I've followed and read the TRILL and ISIS  but, I am  
>> not seeing a way to combine the functions into a single DIS/DRB at  
>> this point.
>>
>> My view (which others have stated earlier) is that the L2ISIS  
>> desired functionality  should not mess with the existing IS-IS DIS  
>> election mechanisms, but should have another set of "hellos" which  
>> can be used for the TRILL specific DRB elections, and have the  
>> appropriate rules for that. Or, we at least need to write down the  
>> rules and explore how to combine them.
>>
>> functionality are and what the "rules" should be for them. We may  
>> find ISIS is suited to meet them or not.
>>
>> Thanks
>>
>> -DWard
>>
>>> So can we focus for a minute on the following question, "whether  
>>> to make MTU size a forever constant,
>>> their buffer sizes, and test their adjacencies to ensure they  
>>> could handle 10000 bytes, and if they don't

---

From: Dinesh G Dutt <[email-masked]>
Date: Thu, 09 Apr 2009 15:40:38 -0700

Radia,

I'd like to reiterate that all we ought to really care about is 
non-padded Hellos. That fixes our problem of creating loops otherwise. 
Everything else is optional and nice-to-have.

David, if we restrict our request to just this, would it be more 
palatable to the IS-IS WG ?

Dinesh

---

From: Radia Perlman <[email-masked]>
Date: Thu, 09 Apr 2009 16:49:39 -0700

Yes, Dinesh, I agree. All we need to do is say that in TRILL Hellos MUST 
NOT be
padded.

Radia

---

From: Donald Eastlake <[email-masked]>
Date: Thu, 9 Apr 2009 20:05:04 -0400

This seems reasonable. What TRILL needs is for Hellos to be reasonably
short, that is, MUST NOT padded. In the interests of converging, I see
no problem in deferring any decisions as to what else to do about MTU.

Thanks,
Donald

On Thu, Apr 9, 2009 at 7:49 PM, Radia Perlman <[email-masked]> wrote:
> Yes, Dinesh, I agree. All we need to do is say that in TRILL Hellos MUST NOT
> be padded.
>
> Radia
>
> Dinesh G Dutt wrote:
>>
>> Radia,
>>
>> I'd like to reiterate that all we ought to really care about is non-padded
>> Hellos. That fixes our problem of creating loops otherwise. Everything else
>> is optional and nice-to-have.
>>
>> David, if we restrict our request to just this, would it be more palatable
>> to the IS-IS WG ?
>>
>> Dinesh
>> Radia Perlman wrote:
>>
>>>
>>> Dave,
>>>
>>> try not to read too much into that phrase and instead just follow through
>>> all the described steps in the
>>> protocol being proposed.
>>>
>>> TRILL is just separating the two functions (choosing DRB, and testing MTU
>>> size), and calling it
>>> in layer 3 IS-IS, DOES NOT WORK FOR TRILL. And it's much simpler to think
>>> about
>>> call the MTU probe protocol "padded Hellos", but let's first make sure we
>>> are getting
>>> b) whether to make MTU probing just test that the link meets the criteria
>>> of the permanent
>>>> changes to the protocol. At least enough of the protocol is being changed
>>>> that we need to consider a new version designator as the direction is
>>>> fundamentally changing adj formation, DIS election, LSP size, etc and
>>>> compatibility with current ISIS doesn't seem a goal.  I'd like to push the
>>>> brakes just a bit to try and get us into better sync.
>>>>
>>>> There are proposals that the Hellos should NOT be padded to  eliminate a
>>>> cause of multiple rbridges on the same LAN "not seeing each other" and
>>>> electing multiple forwarders. However, the idea in the discussion is to
>>>> remove the required MTU checking and it is proposed (which I don't
>>>> understand) to introduce another "MTU discovery" protocol  to restore this
>>>> awareness.
>>>>
>>>> routers that have adjacencies  (that report the existence of each other in
>>>> the IIHs, and it requires that the IIHs are padded to the maximum of the
>>>> link MTU and the originating L1LSPBufferSize - in the case of L1). This
>>>> ensures both that the link is capable of transferring data packets of link
>>>> MTU size, and more  that it is capable of transferring LSPs of the
>>>> appropriate network wide size. If this were not the case, then it is
>>>> possible that a DIS could get elected which was not capable of operating the
>>>> reliable update process, and could cause certain LSPs to fail to be
>>>> propagated across the LAN.
>>>>
>>>> the other routers it sees on the LAN. (and in the OSI case reports the ESs
>>>> on the LAN)
>>>> correctly. The problem is that the roll of the DIS (aka DRB) is defined in
>>>> terms of adjacency formation, and I don't understand how the two distinct
>>>> roles for the DRB  can be combined into a single DRB. Again, I've followed
>>>> and read the TRILL and ISIS  but, I am not seeing a way to combine the
>>>> functions into a single DIS/DRB at this point.
>>>>
>>>> mechanisms, but should have another set of "hellos" which can be used for
>>>> the TRILL specific DRB elections, and have the appropriate rules for that.
>>>> Or, we at least need to write down the rules and explore how to combine
>>>> them.
>>>>
>>>> - TRILL WG should write down the specific requirements and functionality
>>>> are and what the "rules" should be for them. We may find ISIS is suited to
>>>> meet them or not.
>>>>
>>>> Thanks
>>>>
>>>> -DWard
>>>>
>>>> environments with different or "variable" (though static) MTUs, we should
>>>> not hack an easy solution but, create a generalized solution
>>>>

---

From: "Thomas, Matthew R" <[email-masked]>
Date: Fri, 10 Apr 2009 10:15:43 +0100

+1
 
I am actually easy either way, If we do change the election process we (L2) really NEED to do the state diagrams Dave Ward wanted.
 
Matthew Thomas

________________________________

From: [email-masked] on behalf of Don Fedyk
Sent: Fri 10/04/2009 01:31
To: Donald Eastlake
Cc: TRILL/RBridge Working Group; Radia Perlman; [email-masked]; Dinesh G Dutt
Subject: Re: [Isis-wg] [rbridge] Why is MTU discovery important?

I have a different interpretation.   I think you just broke an IS-IS safeguard by not padding Hellos. 
 
The simplest thing you could do is fix the Maximum IS-IS Frame size at some lower value and continue to PAD Hellos. 
 
Don 

On Thu, Apr 9, 2009 at 8:05 PM, Donald Eastlake <[email-masked]> wrote:

	Thanks,
	Donald

---

From: James Carlson <[email-masked]>
Date: Fri, 10 Apr 2009 09:38:43 -0400

> lower value and continue to PAD Hellos.

I disagree.  In the context of TRILL, it's *not* a safeguard at all.
It is in fact a problem.

Failing to get Hello messages through (because the "safeguard" can
stop them when there's a restriction) means that your entire network
goes down.

This is the crucial difference.  I realize that the padded Hello is
protecting against an inability to get LSPs through between peers.
However, the TRILL failure mode we're talking about is far worse, and
destroys everything in its path, including innocent bystanders.

To simplify, let's consider two cases:

  1. This new, smaller padded Hello is always small enough to fit on
     all of the networks anyone ever uses.

  2. The new smaller padded Hello fails to get through on some
     network.

In case (1), everything works fine, but it's also true that unpadded
Hellos would work fine as well.  It's a no-op.

In case (2), the "protection" offered by the padded Hello has now made
two RBridges invisible to each other.  They will both become DRBs.
They will both begin forwarding L2 frames.  The network now has an L2
forwarding loop, and it goes down hard.

Unless we make this new padding requirement absurdly low (say, 64
octets), such that it's not really useful in any sense but also just
never does any harm, I think we're making a mistake.

---

From: David Ward <[email-masked]>
Date: Fri, 10 Apr 2009 10:58:27 -0500

Dinesh -

This is a much better place to start and gives us something concrete  
to work on. Let's consider this as the only work item.

-DWard

On Apr 9, 2009, at 5:40 PM, Dinesh G Dutt wrote:

> Radia,
>
> I'd like to reiterate that all we ought to really care about is non- 
> padded Hellos. That fixes our problem of creating loops otherwise.  
>> so there are no loops, deciding on Designated VLAN for inter- 
>> RBridge communication, etc.
>> This is (and *must* be) different from the way layer 3 IS-IS  
>> happens to work.
>> The other thing that seems to be confusing people is the term  
>> "Hello protocol".
>> serving two very different functions. Having one protoocol that  
>> does both, the way it is today
>> the two problems individually, and make sure we get them both  
>> right. If you like, we can
>> padded Hello protocol MUST NOT have any influence on the "choosing  
>> a Designated
>> The technical issues (ignoring terminology) that are being  
>> discussed for variants of the "MTU probe
>> protocol" are:
>>> If this were not the case, then it is possible that a DIS could  
>>> get elected which was not capable of operating the reliable update  
>>> defined in terms of adjacency formation, and I don't understand  
>>> how the two distinct roles for the DRB  can be combined into a  
>>> single DRB. Again, I've followed and read the TRILL and ISIS  but,  
>>> I am not seeing a way to combine the functions into a single DIS/ 
>>> DRB at this point.
>>>
>>>> It also seems like enough people would feel uncomfortable with  
>>>> not doing MTU discovery that we should make
>>>> every link can handle 1450 bytes, and not use (not report in  
>>>> LSPs) links that can't handle that.
>>>>

---

From: Radia Perlman <[email-masked]>
Date: Fri, 10 Apr 2009 09:21:13 -0700

No, Vishwas -- merely stating the MTU is not sufficient, because there could
be components between two RBridges (like, for instance, bridges), that 
wind up causing
a big packet not to get through. So to really test the MTU requires a 
padded packet,
(but it need not be (and MUST NOT be, for TRILL) the same, simultaneous 
mechanism
as finding neighbors, such as layer 3 IS-IS which does not see neighbors 
that can't
be reached using the largest packets.)

Radia

Vishwas Manral wrote:
> Hi,
>
> Though the MTU padding of Hello's is one way of getting the MTU right in all
> the machines, a simpler and more efficient way would be to actually exchange
> MTU values in a TLV.
>
> The reason padding of Hellos was done in a layer 3 network, instead of a TLV
> was because if between 2 - Layer 3 peers there was a switched network (not
> just a single link), and the MTU in the links somewhere in between was
> lesser, there would be no way to figure that out. 
>
> For trying to work IS-IS for layer 2 the reason no longer holds good.
>  
> Thanks,
> Vishwas
>
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Tony Li
> Sent: Thursday, April 09, 2009 9:55 PM
> To: Don Fedyk
> Don Fedyk wrote:
> Tony

---

From: Radia Perlman <[email-masked]>
Date: Fri, 10 Apr 2009 09:16:10 -0700

Like Jim said, and as numerous people have said in many previous emails 
on this thread,
padded Hellos do not work for TRILL, because it results in two RBridges not
seeing each other, and both forwarding to/from the link. Which causes loops
not protected by the TTL, and is therefore fatal. Layer 3 is different in
this case than layer 2. Again, as explained numerous times before, so it 
probably
won't help for me to explain it once more.

Not padding hellos does not "break IS-IS". The only thing it does is not
do the extra thing that the IS-IS Hello mechanism is doing at the same time
as finding neighbors, which is to test the MTU size.

In TRILL, although weird things may happen if the topology includes
a link that can't handle the MTU size, it's far less bad than
to have two neighbors not see each other.

So, repeating for the nth time....
Keeping the Hello mechanism exactly as it is in IS-IS today will not 
work for TRILL.
That should be the end of discussion. Not padding the Hellos obviously
works for robustly finding neighbors, and is a trivial change. The
only thing that gets lost is MTU discovery.

The only feasible choices at this point are:
a) only do unpadded Hellos, and live with weirdnesses due to not
testing MTU size, deferring MTU discovery to the future
b) do unpadded Hellos, and come up with a mechanism for MTU discovery now.
It would be easy to do so.

I'm happy either way. If we pick a conservative MTU size (and perhaps 
the value
that's already in IS-IS is conservative enough) and say in
the spec that LSPs MUST NOT be bigger than that, the probability of
weirdness as a result of not testing MTU size will be very small, probably
even zero.

Radia

---

From: Donald Eastlake <[email-masked]>
Date: Fri, 10 Apr 2009 14:31:32 -0400

Hi Robert,

See below...

On Fri, Apr 10, 2009 at 1:36 PM, Robert Raszuk <[email-masked]> wrote:
> Hi Radia,
>
>> Keeping the Hello mechanism exactly as it is in IS-IS today will not work
>> for TRILL.
> +
>> So to really test the MTU requires a padded packet,
> So how about option c) which would leave current L3 ISIS Hellos as is today
> and define a new TRILL ISIS Hello mechanism ? Seems to me like quite simple
> and trivial solution to accomplish without any compromises.

The short message, whatever it is called, has to have most if not all
the Hello header information. It also has to have in its body (in some
TLV or otherwise) at least the Designated VLAN for link and a copy of
the VLAN ID with which it was tagged on transmission as well as a flag
indicating whether it thinks it is Appointed Forwarder for that VLAN.
Furthermore, the option must be available to authenticate this
message, so it sure seems convenient to be able to include the IS-IS
Security TLV. Furthermore, it needs to participate in DRB
determination in essentially the same way that Hellos need to. By the
time you are through with all that (and maybe I missed something else
that needs to be added), what is the point of not having this short
message be a Hello? Or are you just saying that you favor the two
kinds of Hello solution which is in
draft-ietf-trill-rbridge-protocol-12.txt? You have studied that draft,
haven't you?

> Of course if we down the road find that minor changes like this will be
> required to other functions of today's ISIS it will be also easier to
> separate L3 ISIS from ISIS twicked for TRILL and perhaps even run it fully
> independently.
>
> Cheers,
> R.

Thanks,
Donald

---

From: Suresh Boddapati <[email-masked]>
Date: Fri, 10 Apr 2009 15:22:22 -0700 (PDT)

--- On Fri, 4/10/09, Radia Perlman <[email-masked]> wrote:

> 
> Not padding hellos does not "break IS-IS". 

I am not completely sure. Please correct me if I am wrong.
Let me see if I can construct an example.
    
     1
 A--------B
 \       /
1 \     / 5
   \ C /

The numbers are the respective cost on the links.

Now suppose A has a smaller MTU such that it can see B's and C's hellos and form adjacencies with them. Now B's LSP that describes the link to A happens to be larger than the MTU that A uses on its links. This LSP does not get through to A from either B or C. Consider that the LSP that B uses to describe the link to C is within the MTU limits and does get through.
Since A does not see B's LSP describing the link to A, it will compute a path to B through C.

C sees both A's and B's LSPs and determines that the shortest path to B is through A (note A and B have both advertised their link in their respective LSPs, so the bidirectionality check would pass, it's just that A does not have B's LSP, so it cannot compute the path correctly). You have basically prevented A from being able to get to all destinations that can be reached through B and you have a loop of a different kind. This loop will not go away. The fix in IS-IS for this is to use padded hellos. If you pad, adjacencies wont form between A and B and everything will be fine. 

In TRILL, if you eliminate the padding, you have a TRILL forwarding loop and every frame sent by A to B or anything reachable through B will die in this loop once the hop count reaches zero. I recognize the fact that this is not as bad as the case when RBridges do not see each other, but is this the "weirdness" you say we could live with? IMO, we should make every effort to not have this situation. Debugging this could be real fun. And this is just one example of things going wrong. CSNPs may not get through. Or it is possible they do get through, but the LSPs dont, resulting in constant flooding of those LSPs on those links.

> It would be easy to do so.
I would prefer to go with an option that ensures that no LSPs get lost silently due to MTU issues. 

Thanks,

Suresh

---

From: Radia Perlman <[email-masked]>
Date: Fri, 10 Apr 2009 15:52:49 -0700

Suresh,

I agree that it would be good to solve both problems:

a) ensure that RBridges see each other (unpadded Hellos is the the solution
that has been proposed), and

b) some mechanism to assure there is agreement about what the 
campus-wide MTU size should be,
and assure that the paths computed only include links that meet that MTU 
size.

It would not be difficult (technically) to solve b) but a) is more 
important, so I can live with
deferring b) and shipping the spec.

If people would like solve b) now, then fine, I'm sure we can come up with
a mechanism to do that. But we have to ensure that that mechanism does 
not interfere in
any way with a).

The problem is that discussing both problems at the same time seems to 
be confusing people.

I think we should agree on this thread that we need to do unpadded 
Hellos to solve problem a), and
start a second thread about what to do about problem b), e.g., "ignore 
it", "defer it until
later", or "here's a candidate solution".

Radia

---

From: Don Fedyk <[email-masked]>
Date: Fri, 10 Apr 2009 21:51:15 -0400

Hi Radia

b) is a not side issue.    Problem b) is characterized by ensuring the 
minimum MTU for IS-IS is met or removing the IS-IS adjacency. 
IS-IS fills LSP up to the minimum MTU as part of its operation.  
Initially when there is not much information to exchange the frame size 
is small, but as information gets added the LSPs grows to the minimum 
MTU size then IS-IS fragments them.  So if you are not sure the minimum 
MTU limit is supported everywhere and continuously monitored then the 
probability increases there will be missing LSPs.  Missing LSPs is a big 
problem.  b) is therefore a problem for proper operation of Trill too.

In IS-IS where b) is the problem,  padding Hellos is the current 
solution and it safeguards IS-IS.  Missing Hellos take down the 
adjacency (ie become unaware of any other IS-IS capable systems on the 
link)  if the minimum MTU is not supported (cut off the link to save the 
rest of the network network).   It is also a good thing to have the 
initial packet you send fail the minimum MTU check if it is going to 
fail. It makes little sense to exchange messages further for IS-IS 
operation.

Problem a) Is a problem characterized by knowing all RBridges attached 
to a common LAN for correct operation of  the LAN and the RBridges.  
IS-IS between the RBridges on the LAN does not need to be operational in 
order to solve this  problem.

So to summarize:

    * In IS-IS padded hellos is the current solution to b) 
    * And you are proposing in Trill  unpadded hellos is the solution to a)
    * Both a) and b) must be solved in Trill

So we have deadlock.

That is why some of us suggested a while ago that another solution to 
a)  outside using IS-IS Hellos is preferable.   I know that makes it 
inconvenient because IS-IS has a really easy way to announce itself over 
a LAN using Hellos. It is oh so close. It works most of the time.  But 
re-engineering IS-IS hellos to solve a) means you now need a solution 
for b) where you already had one..

To break the deadlock the solution in a) and b) must be decoupled and I 
have seen little evidence that IS-IS people are clamoring to change the 
current solution for b).  So the sooner we agree that a) should be 
solved outside of IS-IS Hellos (and I'm not saying how just why), then I 
think we could make progress.

Regards,
Don

Radia Perlman wrote:
> and assure that the paths computed only include links that meet that 
> MTU size.
>
>> Now suppose A has a smaller MTU such that it can see B's and C's 
>> hellos and form adjacencies with them. Now B's LSP that describes the 
>> link to A happens to be larger than the MTU that A uses on its links. 
>> This LSP does not get through to A from either B or C. Consider that 
>> the LSP that B uses to describe the link to C is within the MTU 
>> limits and does get through.
>> C sees both A's and B's LSPs and determines that the shortest path to 
>> B is through A (note A and B have both advertised their link in their 
>> respective LSPs, so the bidirectionality check would pass, it's just 
>> that A does not have B's LSP, so it cannot compute the path 
>> correctly). You have basically prevented A from being able to get to 
>> all destinations that can be reached through B and you have a loop of 
>> a different kind. This loop will not go away. The fix in IS-IS for 
>> this is to use padded hellos. If you pad, adjacencies wont form 
>> between A and B and everything will be fine.
>> In TRILL, if you eliminate the padding, you have a TRILL forwarding 
>> loop and every frame sent by A to B or anything reachable through B 
>> will die in this loop once the hop count reaches zero. I recognize 
>> the fact that this is not as bad as the case when RBridges do not see 
>> each other, but is this the "weirdness" you say we could live with? 
>> IMO, we should make every effort to not have this situation. 
>> Debugging this could be real fun. And this is just one example of 
>> things going wrong. CSNPs may not get through. Or it is possible they 
>> do get through, but the LSPs dont, resulting in constant flooding of 
>> those LSPs on those links.
>>
>>  
>>> Keeping the Hello mechanism exactly as it is in IS-IS today
>>> will not work for TRILL.

---

From: Donald Eastlake <[email-masked]>
Date: Fri, 10 Apr 2009 22:43:29 -0400

Hi Don,

The way I would characterize the problem is as follows:
     There have to be two different messages. (Actually, it's at least
two, since you can always come up with even more complex schemes.)
Consider the follows two possible pairs of messages:
     (1) Use padded Hellos for MTU. Now you have to add a short
message for safety. Unfortunately, this short message has to be a
fairly complex short message with many fields that are the same as a
Hello and has to participate in various Hello mechanisms.
     (2) Use unpadded Hellos for safety. Now you have to add a padded
message for MTU but MTU message can be a simple ping like message.

Alternative 1 sure sounds more complex to me.

Donald

On Fri, Apr 10, 2009 at 9:51 PM, Don Fedyk <[email-masked]> wrote:
> minimum MTU for IS-IS is met or removing the IS-IS adjacency. IS-IS fills
> LSP up to the minimum MTU as part of its operation.  Initially when there is
> not much information to exchange the frame size is small, but as information
> gets added the LSPs grows to the minimum MTU size then IS-IS fragments them.
>  So if you are not sure the minimum MTU limit is supported everywhere and
> continuously monitored then the probability increases there will be missing
> LSPs.  Missing LSPs is a big problem.  b) is therefore a problem for proper
> operation of Trill too.
>
> In IS-IS where b) is the problem,  padding Hellos is the current solution
> and it safeguards IS-IS.  Missing Hellos take down the adjacency (ie become
> unaware of any other IS-IS capable systems on the link)  if the minimum MTU
> is not supported (cut off the link to save the rest of the network network).
>   It is also a good thing to have the initial packet you send fail the
> minimum MTU check if it is going to fail. It makes little sense to exchange
> messages further for IS-IS operation.
>
> Problem a) Is a problem characterized by knowing all RBridges attached to a
> common LAN for correct operation of  the LAN and the RBridges.  IS-IS
> between the RBridges on the LAN does not need to be operational in order to
> solve this  problem.
>
> So to summarize:
>
>   * In IS-IS padded hellos is the current solution to b)   * And you are
> proposing in Trill  unpadded hellos is the solution to a)
> That is why some of us suggested a while ago that another solution to a)
>  outside using IS-IS Hellos is preferable.   I know that makes it
> inconvenient because IS-IS has a really easy way to announce itself over a
> LAN using Hellos. It is oh so close. It works most of the time.  But
> re-engineering IS-IS hellos to solve a) means you now need a solution for b)
> where you already had one..
>
> To break the deadlock the solution in a) and b) must be decoupled and I have
> seen little evidence that IS-IS people are clamoring to change the current
> solution for b).  So the sooner we agree that a) should be solved outside of
> IS-IS Hellos (and I'm not saying how just why), then I think we could make
> progress.
>
> Regards,
> Don
>
> Radia Perlman wrote:
>>
>> Suresh,
>>
>> b) some mechanism to assure there is agreement about what the campus-wide
>> MTU size should be,
>> a mechanism to do that. But we have to ensure that that mechanism does not
>> interfere in
>> any way with a).
>>
>> The problem is that discussing both problems at the same time seems to be
>> confusing people.
>>
>> I think we should agree on this thread that we need to do unpadded Hellos
>> to solve problem a), and
>>> Now suppose A has a smaller MTU such that it can see B's and C's hellos
>>> and form adjacencies with them. Now B's LSP that describes the link to A
>>> happens to be larger than the MTU that A uses on its links. This LSP does
>>> not get through to A from either B or C. Consider that the LSP that B uses
>>> to describe the link to C is within the MTU limits and does get through.
>>> C sees both A's and B's LSPs and determines that the shortest path to B
>>> is through A (note A and B have both advertised their link in their
>>> respective LSPs, so the bidirectionality check would pass, it's just that A
>>> does not have B's LSP, so it cannot compute the path correctly). You have
>>> basically prevented A from being able to get to all destinations that can be
>>> reached through B and you have a loop of a different kind. This loop will
>>> not go away. The fix in IS-IS for this is to use padded hellos. If you pad,
>>> adjacencies wont form between A and B and everything will be fine.
>>> In TRILL, if you eliminate the padding, you have a TRILL forwarding loop
>>> and every frame sent by A to B or anything reachable through B will die in
>>> this loop once the hop count reaches zero. I recognize the fact that this is
>>> not as bad as the case when RBridges do not see each other, but is this the
>>> "weirdness" you say we could live with? IMO, we should make every effort to
>>> not have this situation. Debugging this could be real fun. And this is just
>>> one example of things going wrong. CSNPs may not get through. Or it is
>>> possible they do get through, but the LSPs dont, resulting in constant
>>> flooding of those LSPs on those links.
>>>
>>>
>>>>

---

From: Radia Perlman <[email-masked]>
Date: Fri, 10 Apr 2009 22:23:01 -0700

Yes, what Donald Eastlake said is right.

I think there are several things confusing people:

a) the subject line of this thread, which is a discussion having little 
to do with the subject line

b) calling both "neighbor discovery" messages and "MTU probes" "Hellos".
Frankly, "Hello" is not a particularly descriptive name for either 
thing, and it was probably my fault for
calling it that 30 years ago. I suggest we call neither one of them 
"Hello"s.

c) discussing both mechanisms (neighbor discovery, and MTU probing) in 
the same thread.
Layer 3 IS-IS happened to solve both problems (nbr discovery
and MTU discovery) with the same message type, and one
mechanism that somehow did them both. We've established that TRILL can't
get away with that. So we need one protocol for neighbor discovery and 
one for MTU discovery.
As I said, using the nondescriptive term "Hello" is confusing people, so 
I suggest we
use the terms "neighbor discovery message" and "MTU probe/ack" for the 
message names.

Nobody has claimed that unpadded Hellos does not safely and simply 
accomplish neighbor
discovery. I think we should put "neighbor discovery" to bed at this 
point, perhaps renaming
the message in the spec from "Hello" to "neighbor discovery message", 
which would
be bit-wise identical to the thing we were calling an "unpadded Hello" 
or a "protective Hello".

And start up a new thread for MTU discovery. I suspect people really are 
not happy with
"ignore the problem" or even "defer the problem". If the chairs think 
that is not necessarily
true, and the WG might prefer "ignore" or "defer" MTU discovery, I 
suggest we
have a different thread with a subject line "should we bother doing MTU 
discovery".

Assuming the WG does want to solve MTU discovery, we should do so.
It will not be technically difficult.
It will involve some simple pinging thing with padded messages. I propose we
not call those messages "padded Hellos", but instead call them "MTU probe".

Radia

---

From: "Eric Gray" <[email-masked]>
Date: Sat, 11 Apr 2009 02:06:46 -0500

Donald,

	First of all, you're not characterizing the problem; you're
characterizing possible solution choices to the problem.

	And, I don't think you've characterized the choice correctly,
or perhaps it is more accurate to say that you've chosen a specific
characterization that is not necessarily the most appropriate one
in light of the many aspects of the current discussion.

	I would characterize the choices as follows:

1) Use padded Hellos for consistency with currently specified IS-IS.
   With this choice, you also need to add a short message for loop
   (and duplicate delivery) protection.  This short message might be
   fairly complex (with many fields the same as a hello PDU, and the
   need to process this message consistent with hello processing) or
   as simple as a message that says "I am a version 1 TRILL Rbridge."
   In the latter case, the protocol specification needs to describe
   how DRB election takes place if a device is detected that says it
   is a version 1 RBridge but no hello messages are received.
2) Use unpadded Hello messages for safety.  Now you might add a simple
   padded message for MTU, provided that you can do so and still end
   up with the protection for control plane message relaying that has
   previously been afforded IS-IS via padding of hello PDUs.  This
   could and up being as complex as re-invention of IS-IS protocol.

In this characterization, it is signficantly less clear that choice 1
is the more complex choice.  Yet, if you think it through, you should
realize that this is a more accurate characterization of the choices.

--
Eric

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Donald Eastlake
Sent: Friday, April 10, 2009 10:43 PM
To: Don Fedyk
Cc: TRILL/RBridge Working Group; Radia Perlman; [email-masked]
Subject: Re: [rbridge] [Isis-wg] Why is MTU discovery important?

Hi Don,

Donald

---

From: "Eric Gray" <[email-masked]>
Date: Sat, 11 Apr 2009 02:11:34 -0500

Radia,

No, what Donald Eastlake said is not "right"; it is one possible 
view of the choices for dealing with the problem, but that does 
not make it necessarily the "right" view.

--
Eric 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Radia Perlman
Sent: Saturday, April 11, 2009 1:23 AM
To: Donald Eastlake
Cc: TRILL/RBridge Working Group; [email-masked]
Subject: Re: [rbridge] [Isis-wg] Why is MTU discovery important?

I suggest we

not happy with

Assuming the WG does want to solve MTU discovery, we should do so.
It will not be technically difficult.
It will involve some simple pinging thing with padded messages. I
propose we
not call those messages "padded Hellos", but instead call them "MTU
probe".

Radia

>> In IS-IS where b) is the problem,  padding Hellos is the current
solution
>> That is why some of us suggested a while ago that another solution to
a)
>> re-engineering IS-IS hellos to solve a) means you now need a solution
for b)
>>> b) some mechanism to assure there is agreement about what the
campus-wide
MTU
>>> I think we should agree on this thread that we need to do unpadded
Hellos
>>>> Now suppose A has a smaller MTU such that it can see B's and C's
hellos
>>>> Since A does not see B's LSP describing the link to A, it will
compute a
>>>> path to B through C.
loop
>>>> I would prefer to go with an option that ensures that no LSPs get
lost
>>>> silently due to MTU issues.
>>>> Thanks,
>>>>
>>>> Suresh
>>>>
>>>>

---

From: "Thomas, Matthew R" <[email-masked]>
Date: Sat, 11 Apr 2009 09:59:07 +0100

Radia,
 
Like I said, we need some state diagrams. ISIS has specific states and actions that move the 'neighbor, adjacency, foo from one state to another. These actions are also quite specific; like receiving a valid hello, missing various messages etc. Is an invalid hello even considered a hello? The states are well defined and inter-connected. Adjacency and neighbor are specific terms and as you point out in this thread we have probably not used them consistently and from some of the comments I expect we might not have used them accurately? 
 
With each new 'packet' / 'mechanism' there may be changes to these mechanisms and states. I think we need to display an understanding of the existing mechanisms, and the condition they leave the router in in each case.
 
Each change to this system is considered a large change.
 
MT

From: [email-masked] on behalf of Radia Perlman
Sent: Sat 11/04/2009 06:23
To: Donald Eastlake
Cc: TRILL/RBridge Working Group; [email-masked]
Subject: Re: [Isis-wg] [rbridge] Why is MTU discovery important?

Radia

---

From: Don Fedyk <[email-masked]>
Date: Sat, 11 Apr 2009 11:01:07 -0400

Hi Radia

Well you are correct that some of the terminology is imprecise.  I don't
agree with some of the characterization. I would agree we should use more
precise terminology.   I was actually being very precise my last couple of
emails. (I hope people are still reading them.)

We are dealing with two worlds here.  Sorry it is not a level playing
field:

   1. IS-IS design and working system.
   2. Trill proposals which leverage 1.

In my books 1. current operation takes precedence because it is both problem
and solution. It is deployed and working.  So we can't just go in and change
things and expect it to work with out careful analysis. But accurately
describing what it is doing is a good idea.

For 2. we have a problem that needs to be described.  Let stick to the
problem description.  Define an "ideal" solution mechanism outside of IS-IS
mecjhanisms and describe it with the same accuracy.  Only then can we look
at 1. and see what portions are applicable if any.

Terms we need to agree on:
"minimum MTU" or  "The too small MTU Problem for IS-IS"
"Neighbor Discovery"
"IS-IS Adjacency"
"RBridge Adjacency"
"Number of RBridges that attached on a LAN"  <- There is no equivalent for
this in IS-IS
"IS-IS Hello"
"minimum MTU probing"
"MTU discovery" <- Should not be used.  IP does MTU discovery. IS-IS does
not. Unfortunately _is_ the title of this thread!

Regards,
Don

On Sat, Apr 11, 2009 at 1:23 AM, Radia Perlman <[email-masked]>wrote:

> a) the subject line of this thread, which is a discussion having little to
> do with the subject line
>
> Frankly, "Hello" is not a particularly descriptive name for either thing,
> and it was probably my fault for
> c) discussing both mechanisms (neighbor discovery, and MTU probing) in the
> same thread.
> get away with that. So we need one protocol for neighbor discovery and one
> for MTU discovery.
> As I said, using the nondescriptive term "Hello" is confusing people, so I
> suggest we
> discovery. I think we should put "neighbor discovery" to bed at this point,
> perhaps renaming
> the message in the spec from "Hello" to "neighbor discovery message", which
> would
> be bit-wise identical to the thing we were calling an "unpadded Hello" or a
> "protective Hello".
>
> "ignore the problem" or even "defer the problem". If the chairs think that
> is not necessarily
> true, and the WG might prefer "ignore" or "defer" MTU discovery, I suggest
> we
>>> have
>>>> not
>>>>> Since A does not see B's LSP describing the link to A, it will compute
>>>>> a
>>>>> path to B through C.
>>>>>
>>>>> that A

---

From: David Ward <[email-masked]>
Date: Sat, 11 Apr 2009 16:39:11 -0500

Dave -

At this point the primary extensions for TRILL are:

- a new mcast PDU

- a  separate Hello on a new demux (at worst)

These fit into the definition that you describe below.  The other  
functions were agreed to be dropped and I hope that it remains the  
case or a new NLPID seems in order. I also prefer to keep this  
functionality as close to "IS-IS" as possible.

-DWard

On Apr 11, 2009, at 11:56 AM, Dave Katz wrote:

> As someone who as been designing and coding this stuff since before  
> most of our current crop of engineers were born, I'll throw in some  
> practicalities:
>
> 1)  The thing we call "IS-IS" that has a NLPID of 0x83 (IIRC) can  
> only be changed in an upward-compatible manner.  So any proposal to  
> change anything in the existing L3 IS-IS beyond the addition of a  
> new PDU type is a non-starter (and even that is likely to break some  
> dubious implementations, which may or may not be a bad thing).
>
> 2)  If TRILL ends up as a distinct protocol (by NLPID or some other  
> mechanism) it can do things any which way it pleases.  It is best  
> from an implementation perspective to keep it as close to IS-IS as  
> possible so that a single implementation with a few checks here and  
> there can do both.  This has the added advantage that foolish  
> implementors will cut-and-paste the code and create themselves  
> maintenance problems and allow Darwinian selection to occur, like  
> back in the NLSP days.  ;-)  But it is entirely possible to share  
> 99% of the code while maintaining protocol "distinctness."  And  
> having it distinct from IS-IS avoids having to be forced to make  
> compromises to avoid breaking IS-IS (at the cost of less common code).
>
> Just my 112 ZMK.
>
> --Dave
>
> On Apr 11, 2009, at 10:01 AM, Don Fedyk wrote:
>
>> Hi Radia
>>
>> Well you are correct that some of the terminology is imprecise.  I  
>> don't agree with some of the characterization. I would agree we  
>> should use more precise terminology.   I was actually being very  
>> precise my last couple of emails. (I hope people are still reading  
>> them.)
>>
>> We are dealing with two worlds here.  Sorry it is not a level  
>> playing field:
>> IS-IS design and working system.
>> Trill proposals which leverage 1.
>> In my books 1. current operation takes precedence because it is  
>> both problem and solution. It is deployed and working.  So we can't  
>> just go in and change things and expect it to work with out careful  
>> analysis. But accurately describing what it is doing is a good idea.
>>
>> For 2. we have a problem that needs to be described.  Let stick to  
>> the problem description.  Define an "ideal" solution mechanism  
>> outside of IS-IS mecjhanisms and describe it with the same  
>> accuracy.  Only then can we look at 1. and see what portions are  
>> applicable if any.
>>
>> "Number of RBridges that attached on a LAN"  <- There is no  
>> equivalent for this in IS-IS
>> "IS-IS Hello"
>> "minimum MTU probing"
>> "MTU discovery" <- Should not be used.  IP does MTU discovery. IS- 
>> IS does not. Unfortunately _is_ the title of this thread!
>>
>> Regards,
>> Don
>>
>> On Sat, Apr 11, 2009 at 1:23 AM, Radia Perlman  
>> <[email-masked]> wrote:
>> a) the subject line of this thread, which is a discussion having  
>> little to do with the subject line
>>
>> c) discussing both mechanisms (neighbor discovery, and MTU probing)  
>> in the same thread.
>> get away with that. So we need one protocol for neighbor discovery  
>> and one for MTU discovery.
>> As I said, using the nondescriptive term "Hello" is confusing  
>> people, so I suggest we
>> use the terms "neighbor discovery message" and "MTU probe/ack" for  
>> the message names.
>>
>> discovery. I think we should put "neighbor discovery" to bed at  
>> this point, perhaps renaming
>> the message in the spec from "Hello" to "neighbor discovery  
>> message", which would
>> be bit-wise identical to the thing we were calling an "unpadded  
>> Hello" or a "protective Hello".
>>
>> And start up a new thread for MTU discovery. I suspect people  
>> really are not happy with
>> "ignore the problem" or even "defer the problem". If the chairs  
>> think that is not necessarily
>> have a different thread with a subject line "should we bother doing  
>> MTU discovery".
>>

---

From: Kris Price <[email-masked]>
Date: Sun, 12 Apr 2009 16:08:46 +1200

OK. Defining the problem and the general courses of action, and then the 
eliminating them.

In normal layer-3 operation, the failure of IS-IS to discover a 
neighbouring router is of minor consequence.

For TRILL the failure of IS-IS to discover a neighbouring RBridge is a 
problem. TRILL defines a special RBridge role, known as the designated 
forwarder, and uses IS-IS to elect which RBridge on each link will 
perform this role.

When an RBridge does not recieve the IS-IS Hellos of its neighbours it 
will assume it is alone on the link, and therefore elect itself the 
designated forwarder.

The designated forwarder role elevates an RBridge from merely forwarding 
TRILL data frames between the TRILL speakers in a TRILL cloud, to 
encapsulating and decapsulating Ethernet frames onto and off of LANs.

This is where the danger arises. When more than one RBridge performs 
this role, a loop forms. There is no bad news in regards to forwarding 
TRILL data frames.

So the *split* comes at this elevation of "bridging" between the TRILL 
data frames and the Ethernet frames. In elevating a router from being a 
forwarder of Layer 2.5+ frames, to being an encapsulator/decapsulator 
from the routed layer into the LAN layer.

You could leave IS-IS as is if an RBridge had some other mechanism to 
know if it should elevate itself into this position.

Option 0:

Use some kind of involvement in the STP to trick it into breaking loops. 
But this has been completely rejected by the WG several times, and will 
never (by the looks) be given a lifeline. So it's not worth considering.

Option 1:

Could you use a repurposed configuration BPDU or similar to announce 
your presense as an RBridge onto a link? You wait for a period of X 
seconds, and if you do not see any announcements, proceed as normal, 
elevating yourself (or someone else) into the designated forwarder role.

Maybe you could have some new TRILL OUI that RBridges map their 
nicknames and priority into for the Bridge IDs, and then they transmit 
these. Perhaps it can even carry more useful info in some MST like way.

How this is achieved is beyond my current level of STP knowledge, so 
someone more educated on STP would need to explore that avenue if they 
found it interesting.

Option 2:

If you cannot use STP in some way like this, you need a new protocol, 
but it will not be simple because it becomes constrained by the VLAN 
topology. It does not see a physical bridged LAN as one link, like a 
BPDU does, it sees it as many links.

So you have solve those problems and to do something similar to what 
TRILL does with the IS-IS hellos, protection hellos, etc. In that case 
you might as well move all that protection hellos etc. into this new 
protocol, and leave IS-IS as untouched as possible.

So I think this option is about leave IS-IS as is and create an all new 
"TRILL Discovery and Election Protocol for All Link Types(tm)," and 
running the two protocols together.

Pros: TRILL doesn't have to modify IS-IS and become responsible for 
porting IS-IS enhancements, etc.

Option 3:

Modify IS-IS for TRILL's needs but call it something different, maybe 
"RB-RB". RB-RB would share 99% of the code with IS-IS, but is customised 
for TRILL's specific needs. Solve the problems in an appropriate way, as 
has been suggested, or maybe a variation of.

Pros: Already undergone some customisation for TRILL's needs. It seems 
to be what you would naturally come up with if IS-IS didn't exist, one 
protocol to rule them all, rather than multiple.

Moving forward:

1. Someone who knows STP and BPDUs would need to come up with a working 
suggestion for Option 1, or it's out the window. Put a timer on it, say 
a week.

2. It looks like people are split between Option 2 and Option 3. So 
would the WG even accept moving some existing customisation into an 
external protocol as per Option 2?

3. If not, those opposed to Option 3 should ask themselves if it is 
worth pursuing, given it would end up as a split between half of Option 
2 and half Option 3.

4. If so, we're still stuck at coming up with two competing protocols, 
but perhaps, given how key it is, it is worth developing and comparing 
two proposals in that case. (So long as the effort isn't wasted, see 1, 
2, and 3 above.)

For me Option 1 is slightly preferable. Otherwise I can go either way on 
Option 2 or 3. But I wouldn't like to see a split between half an Option 
2 and half an Option 3.

Hope you all found your chocolate eggs.

Cheers
Kris

---

From: Don Fedyk <[email-masked]>
Date: Sun, 12 Apr 2009 09:01:05 -0400

Hi Kris

I think you have enumerated a number of options but in general we could
summarize most of the them all as:

Separating Neighbor discovery out from IS-IS and running vanilla IS-IS.

What I would recommend is:
Run a protocol that does Neighbor Discovery and handshake (Might look
like IS-IS Short Hello frames, and minimum handshake logic but it is not
IS-IS)  Call it the Trill discovery protocol.
If Trill Neighbor discovery aspect only works in one direction for some
obscure reason the handshake won't complete but at least it should prevent
multiple RBridges assuming they are the DRB.
If the handshake completes then this protocol is happy and all it does is
trigger vanilla IS-IS (which may use a different NLPID or whatever) and
Trill discovery continues in the background.

If IS-IS ever restarts, breaks down or looses adjacency the Trill discovery
would be there as a safety net continuing the neighbor discovery at a
minimum.

In this design of a solution: Clear separation of  function from IS-IS would
satisfy the requirements and allow IS-IS to remain in tact.

Yes there is a little duplication of Neighbor discovery and handshaking
functions but I think the separation is worth the cost of reusing the IS-IS
logic in tact.

Cheers,
Don (The best I can do in the spirit of the Easter egg hunt [?] )

On Sun, Apr 12, 2009 at 12:08 AM, Kris Price <[email-masked]> wrote:

> forwarder, and uses IS-IS to elect which RBridge on each link will perform
> this role.
>
> When an RBridge does not recieve the IS-IS Hellos of its neighbours it will
> assume it is alone on the link, and therefore elect itself the designated
> forwarder.
>
> This is where the danger arises. When more than one RBridge performs this
> role, a loop forms. There is no bad news in regards to forwarding TRILL data
> frames.
>
> So the *split* comes at this elevation of "bridging" between the TRILL data
> frames and the Ethernet frames. In elevating a router from being a forwarder
> of Layer 2.5+ frames, to being an encapsulator/decapsulator from the routed
> layer into the LAN layer.
>
> You could leave IS-IS as is if an RBridge had some other mechanism to know
> if it should elevate itself into this position.
>
>
> Option 0:
>
> Could you use a repurposed configuration BPDU or similar to announce your
> presense as an RBridge onto a link? You wait for a period of X seconds, and
> if you do not see any announcements, proceed as normal, elevating yourself
> (or someone else) into the designated forwarder role.
>
> Maybe you could have some new TRILL OUI that RBridges map their nicknames
> and priority into for the Bridge IDs, and then they transmit these. Perhaps
> it can even carry more useful info in some MST like way.
>
> someone more educated on STP would need to explore that avenue if they found
> it interesting.
>
>
> Option 2:
>
> If you cannot use STP in some way like this, you need a new protocol, but
> it will not be simple because it becomes constrained by the VLAN topology.
> It does not see a physical bridged LAN as one link, like a BPDU does, it
> sees it as many links.
>
> So you have solve those problems and to do something similar to what TRILL
> does with the IS-IS hellos, protection hellos, etc. In that case you might
> as well move all that protection hellos etc. into this new protocol, and
> leave IS-IS as untouched as possible.
>
> "TRILL Discovery and Election Protocol for All Link Types(tm)," and running
> the two protocols together.
>
> Pros: TRILL doesn't have to modify IS-IS and become responsible for porting
> IS-IS enhancements, etc.
>
>
> Option 3:
>
> "RB-RB". RB-RB would share 99% of the code with IS-IS, but is customised for
> TRILL's specific needs. Solve the problems in an appropriate way, as has
> been suggested, or maybe a variation of.
>
> Pros: Already undergone some customisation for TRILL's needs. It seems to
> be what you would naturally come up with if IS-IS didn't exist, one protocol
> to rule them all, rather than multiple.
>
>
>
> Moving forward:
>
> suggestion for Option 1, or it's out the window. Put a timer on it, say a
> week.
>
> 2. It looks like people are split between Option 2 and Option 3. So would
> the WG even accept moving some existing customisation into an external
> protocol as per Option 2?
>
> 3. If not, those opposed to Option 3 should ask themselves if it is worth
> pursuing, given it would end up as a split between half of Option 2 and half
> Option 3.
>
> 4. If so, we're still stuck at coming up with two competing protocols, but
> perhaps, given how key it is, it is worth developing and comparing two
> proposals in that case. (So long as the effort isn't wasted, see 1, 2, and 3
> above.)
>
>
>
> Option 2 or 3. But I wouldn't like to see a split between half an Option 2
> and half an Option 3.
>
>
>

---

From: Radia Perlman <[email-masked]>
Date: Sun, 12 Apr 2009 16:17:57 -0700

Another reason I think people are getting confused is the use of the 
term "use vanilla IS-IS".
"Vanilla IS-IS",
where MTU discovery is all interlinked with choosing DRs, and where the 
result can be
multiple DRs, will not work, as has been said many times on this thread, 
and people don't
know what "just use vanilla IS-IS" means.

So, do not use the phrase "use vanilla IS-IS" as a shorthand for
any part of the solution. It only confuses people. Certainly
*I* have no idea what anyone means when they use that phrase, especially 
since
it's clear that we can't "just use vanilla IS-IS".

Now, to try to get us back on track:

There are three problems TRILL needs to solve, (given that
it's pretty clear people don't want to defer or ignore the MTU issue),
and the discussion should
be around how to solve each problem.

The three problems that must be solved:

a) on a link, choosing one and only one DRB, who will be assigning 
designated
forwarders, dictating which VLAN is the designated VLAN, naming the 
pseudonode, etc.

b) having all RBridges agree on what the campus-wide MTU size should be, 
say S.

c) having all RBridges test, for each link and each neighbor, which ones 
can handle
size S, and removing those that don't from the topology, so routes are
not calculated through links that can't handle size S.

The solution to a) is what is in the TRILL spec today. It uses unpadded 
IS-IS Hellos,
and has a lot of explanation of what VLANs to send unpadded Hellos on, and
unlike IS-IS, has slightly different logic to ensure there are not 
multiple DRBs
in the face of one-way connectivity, MTU mismatches, etc.

The solution to b) is with adding a TLV into the LSP, where not 
including the
TLV is the same as specifying "1450", and the TLV, if specified must 
have S > 1450.
There are only three plausible ways of using this TLV, I think:
1) look through all the LSPs in your database, and choose the largest 
size S any RBridge specifies, as the
campus-wide S
2) choose the smallest size S any RBridge specifies as the campus-wide S
3) look at the LSP of the highest priority RBridge in the campus, and 
use the S specified in its LSP as
the campus-wide S. (by the way, I prefer this one -- seems simplest and 
most stable)

The solution to c) (testing MTU size), has to be done with padded 
packets of some sort.
It could certainly be done using the same format as padded IS-IS Hellos, 
though
I'd prefer some clear distinction between the MTU-testing packets and 
the DRB election/
VLAN specifying, etc., packets so that the logic of solving problems a) 
and c) don't
get intermingled.

The MTU-testing packet should include a TLV specifying "S", the size 
being tested, and should
be padded to S. We could have unicast acks to this padded packet, or do 
the same sort
of IS-IS-like two-way connectivity announcements, by having R2, in its 
S-padded packet,
list all RBridge neighbors on the link from which it has (recently 
enough) received packets of at least
size S. It would be nice to have some careful thoughtful discussion on 
the mailing list about
what the best way to solve this would be. (e.g., optional, mandatory, 
periodic, once and
assume things won't change, unicast acks vs listing "I heard size S from 
this list"). But
whatever it is would have nothing to do with choosing a DRB, naming the 
pseudonode,
or any mechanisms usually associated with "Hellos".

Radia

---

From: Kris Price <[email-masked]>
Date: Mon, 13 Apr 2009 14:52:05 +1200

Radia Perlman wrote:
[snip]
> b) having all RBridges agree on what the campus-wide MTU size should be, 

Radia, could you please elaborate a little on why this point b) is a 
problem to be solved so we're all on the same page? I thought I 
understood but I've forgotten after reading this long thread. Does it 
cause a loop or any problems other than partitioned networks? Or is it 
to ease administrative burdon, e.g. configure in one place rather than 
on all routers (this introduces other problems)?

I've been a bit confused (and perhaps others have also) about the 
purpose of the padding in an IIH. I may still be confused. To clear 
things up:

An IIH is padded up to the maximum of dataLinkBlocksize (MTU) or
originatingL1LSPBufferSize.

Because each IS may send LSP PDUs up to its originatingL1LSPBufferSize
they do this padding to prevent creating an adjacency with a neighbour
for which they may not be able to send an LSP to.

The purpose of the padding is *only* to prevent an adjacency forming 
between any pair of ISs which would not be able to exchange LSPs locally 
with each other. It does nothing to ensure that RecieveLSPBufferSize, or 
some network wide consistent originatingL1LSPBufferSize is met on all 
links, and does not ensure that LSPs created by any IS can be sent 
across all links.

When an IS recieves, on one link, an LSP bigger than the
dataLinkBlocksize of another link, it cannot flood it, and it reports 
and error. The spec also includes means for detection of inconsistent 
originatingL1LSPBufferSize by including a new TLV 
originatingLSPBufferSize for it. This is what is defined in IS-IS. It is 
considered an administrative issue by the looks to ensure that (if you 
want your LSPs to get through) you configure a consistent 
originatingL1LSPBufferSize on all routers in your network.

So it seems (to me) there are three general options for this point:

Option 1.

Provided there is no danger to LSPs not getting through on some links. 
Do nothing, leave it as an administrative alert as per existing ISIS. It 
is the responsibility of the administrator to ensure the 
originatingL1LSPBufferSize is configured appropriately throughout the 
network.

And in this option, perhaps leave it for the IS-IS group to one day solve.

Option 2.

Take the approach of automatically healing the network to the smallest 
MTU to include all links.

Option 3.

Take the approach of the priority router dictating the MTU size and 
other routers exclude links which do not meet that MTU.

I'd like to understand why Option 3 is better than the other options.

Cheers
Kris

---

From: "Thomas, Matthew R" <[email-masked]>
Date: Mon, 13 Apr 2009 10:11:16 +0100

Radia, Kris,
 
There may be something to salvage here or may not as the case may be. ( This is just my port 8899 ) but in 2007 I callled this idea promiscuous hellos. It was to try to automatically fix encapsulation failure on NBMA networks which seems to be what you are having (via MTU). The IETF fix was P2P network type (not surprisingly) which of couse is manual configuration. This idea here would improve the situation somewhat but not fix fireproof. It is always possible to break pseudonodes if you really try (although they do improve safety somewhat) This would improve the situation somewhat.
 
Imagine R1 and R2 cannot communicate, and they share a media with R3 which R2 can communicate with:
 
Problem identification:
 
R3 sends a hello to R1. R1 sees itself (R1) listed in the hello and so R3 and R1 are generally ok. BUT It also sees R2 listed in the hello from R1. R2 is there in the hello from R3 even though the neighbor relationship between R1 and R2 is broken and the hellos from R2 to R1 never got through. this is because R3 is in communication with R2. R1 is confused. R2 is also confused but clearly something is wrong. As no hello has formally appeared from R2 to R1, R1 would normally not even consider R2 to exist. R2 would be considered a rumour and no neighbor state would exist for R2 in R1.
 
Normally (in my understanding) this would result in R1 and R2 completely ignoring each other and this will lead to problems in general, resulting in duplicate DR's which is bad.
 
FIX in this case:
 
SO... 1.) R1 wonders who R2 is (even though R2 is not officially there in anyway): No hello has been received from R2 and acording to the normal operation of the unfixed protcol no state exists for this router. BUT R2 was listed in a valid hello from R3 and so will now not be ignored. R1 instead puts R2 on a special list and tries to contact R2 with special options. In my ospf-lite R1 reverted to unicast. (you could dynamically drop the MTU here).
 
This fixes: some blind neighbors, not all.
 
This doesnt fix: 2 pairs of incorrectly configured RB's completely blind to each other, and endorsing each other if they (the pairs) miss ALL packets from the other RB's. I couldnt find a fix for this and called it experience.

Matthew

From: [email-masked] on behalf of Kris Price
Sent: Mon 13/04/2009 03:52
To: TRILL/RBridge Working Group; Radia Perlman
Subject: Re: [rbridge] [Isis-wg] Why is MTU discovery important?

Radia Perlman wrote:
[snip]

Option 1.

Option 2.

Option 3.

Cheers
Kris

---

From: "Thomas, Matthew R" <[email-masked]>
Date: Mon, 13 Apr 2009 10:29:46 +0100

Could we send both types? Padded and unpadded and revert to whichever is responded to? 
 
MT

From: Thomas, Matthew R
Sent: Mon 13/04/2009 10:11
To: Kris Price; [email-masked]
Cc: [email-masked]
Subject: RE: [rbridge] [Isis-wg] Why is MTU discovery important?

Radia, Kris,

 
Problem identification:

 
FIX in this case:

 

Matthew

Radia Perlman wrote:
[snip]

Option 1.

Option 2.

Option 3.

Cheers
Kris

---

From: James Carlson <[email-masked]>
Date: Mon, 13 Apr 2009 08:26:18 -0400

> I'd like to understand why Option 3 is better than the other options.

The messages that an RBridge will be forwarding are layer two 802
packets.  This means there's no fragmentation possible.

The implication of that is that all of the bridges and links connected
to a single subnetwork must be configured with exactly the same MTU,
not larger and not smaller.

---

From: James Carlson <[email-masked]>
Date: Mon, 13 Apr 2009 08:44:57 -0400

>    is a version 1 RBridge but no hello messages are received.

I believe that the DRB election could not take place in that event.
If the protective discovery message is simple, and the rest of the
Hello information is missing, then the only safe thing left to do is
to avoid forwarding on that interface at all, because we know that
some nodes are screened from us, but we can't tell what L2 forwarding
they might attempt to do or what loops may exist in the topology, and
we cannot elect a unique DRB without Hello messages passing through.

I suspect this proposal _also_ changes IS-IS.  We would have to define
what happens if a node receives an IS-IS Hello message without having
previously received the loop protection message, and what to do if we
stop receiving the protective messages from a node (due to an
underlying reconfiguration).  The latter means tearing down existing
adjacencies when we miss those packets, and disabling all forwarding
as above.  (Again, the key difference is that this "simple" discovery
mechanism lacks the ability to guarantee that we have at most one DRB
on the network, which is a requirement of TRILL.)

On the other hand, if the message is complex, it's hard to see how we
don't just end up with unpadded Hellos.  At that point, we've
converged on solution (2), and all we're talking about is the
complexity of the MTU probing mechanism -- whether it is indeed a
padded Hello or a simpler message.

(One of the discarded proposals was to send both padded and unpadded
Hellos.  You would need to receive both to become fully adjacent.)

---

From: Donald Eastlake <[email-masked]>
Date: Mon, 13 Apr 2009 09:57:56 -0400

Sending two types of Hellos is what is in the current RBridge base
protocol draft. I haven't heard anyone claim that does not work, just
many people say they don't like it.

Donald

---

From: Kris Price <[email-masked]>
Date: Tue, 14 Apr 2009 16:28:35 +1200

> not larger and not smaller.

Thanks James,

I just want to be clear then... This is about preventing data frames 
from being discarded because they arrive at a link with an MTU that is 
too small? Just as happens today in Ethernet? It is not about preventing 
bad (abnormal) things from happening or making sure the control plane is 
working properly? And it's range is what, from 512 bytes to 9216 bytes?

If so, in a way it is really a kind of traffic engineering isn't it? 
Saying, "I only want you to compute paths that fit this constraint."

If it is this (traffic engineering) then I think it should be left to a 
separate extension to TRILL. Perhaps including other TE-like additions.

And it should be separated out from the functionality of the control 
plane, i.e. the control plane shouldn't form a special new type of 
adjacency to make this happen. IS-IS or RB-RB or whatever forms all its 
adjacencies as normal. They all report their TE info in new TLVs as per 
existing TE extensions, and then each RB computes the constrained paths 
based on that info. You can still have a priority router or something 
dictate that TE policy that every router should compute their paths to.

Some possible badness with this priority router dictating the MTU:

- Priority router goes down. Now what happens? Do they use the new MTU 
defined by the second priority router? What about the third? Etc. Do 
they maintain some kind of state about what a higher priority router 
once said? For how long? What if they all differ?

- A higher priority router comes online later in the game and has a 
higher MTU. Unfortunately it is too late, an older router already was 
priority for a period and sent out an MTU size, that has caused the 
network to be partitioned and on this partitioned link there is this new 
"aware-but-not-adjacent" adjacency because the link didn't meet the MTU. 
Now one side recieves the new larger MTU, but it can't transmit any LSPs 
to the other side, so you have a whole new cycle of states that need to 
transition through for this adjacency.

I'm all for healing the network to ensure there are no partitions, i.e. 
settling down to the lowest MTU to make sure LSPs get through. And then 
having a separate TE extension to handle neat TE things that TRILL can 
do (that'd be great).

Unless it is there for some non-TE reason...? (which again, I thought I 
recognised at some point a need for that non-TE reason, but I've lost 
track of it, and it would be down the track of this healing business...)

Cheers
Kris

---

From: mike shand <[email-masked]>
Date: Tue, 14 Apr 2009 13:41:13 +0100

Yes, the piece which seems to be consistently missed out of this
discussion is that it is NOT as simple as using unpadded IS-IS hellos
and associated elements of procedure as the TRILL neighbor discovery
mechanism. As I understand things from this discussion, TRILL requires
a number of changes to the adjacency formation state tables, which at
the least require changes from an existing IS-IS implementation, and
probably make it a lot harder to have a single implementation (with
tweaks).

The changes I have seen so far are

1) allow DRBs to be elected even if the adjacency hasn't been
bidirectionally confirmed.

2) allow DRB election even when there are no other adjacencies.

Are there any other changes which would be required, which have not yet
surfaced?

Mike

Thomas, Matthew R wrote:

Radia,

MT

Radia

Donald Eastlake wrote:

Hi Don,

Donald

Hi Radia

So to summarize:

So we have deadlock.

Regards,
Don

Radia Perlman wrote:

Suresh,

a) ensure that RBridges see each other (unpadded Hellos is the the
solution
that has been proposed), and

Radia

Suresh Boddapati wrote:

Since A does not see B's LSP describing the link to A, it will compute a
path to B through C.

So, repeating for the nth time....
Keeping the Hello mechanism exactly as it is in IS-IS today
will not work for TRILL.
That should be the end of discussion. Not padding the
Hellos obviously
works for robustly finding neighbors, and is a trivial
change. The
only thing that gets lost is MTU discovery.

The only feasible choices at this point are:
a) only do unpadded Hellos, and live with weirdnesses due
to not
testing MTU size, deferring MTU discovery to the future
b) do unpadded Hellos, and come up with a mechanism for MTU
discovery now.
It would be easy to do so.

I would prefer to go with an option that ensures that no LSPs get lost
silently due to MTU issues.
Thanks,

Suresh

---

From: James Carlson <[email-masked]>
Date: Tue, 14 Apr 2009 09:10:43 -0400

> working properly? And it's range is what, from 512 bytes to 9216 bytes?

Yes; the single network-wide MTU (and the mechanism for picking and/or
enforcing it) are all about that issue.

However, that's not really the important issue that we've been talking
about in this thread, but rather the padded Hello problem, which is
separate.

I think we should start a new thread if we're going to discuss the
network-wide MTU problem.

> separate extension to TRILL. Perhaps including other TE-like additions.

Possibly.  It is inherent, though, in an 802 bridged network, so it'd
be nice if there were some thought put into it and not just made
optional.

> track of it, and it would be down the track of this healing business...)

It's not really TE, at least from my point of view.  The network is
just plain non-functional from an 802 standpoint if there are multiple
MTUs involved.  But, again, separate thread.

---

From: "Drake, John E" <[email-masked]>
Date: Tue, 14 Apr 2009 10:33:02 -0700

Snipped 

> 
> if we want to further walk down that road, we should name the 
> beast TRILL-something and drop the isis-wg groups 
> involvement, since this is not IS-IS any more.

JD:  Now there's an idea.

> /hannes

---

From: Donald Eastlake <[email-masked]>
Date: Tue, 14 Apr 2009 16:13:24 -0400

See below...

On Tue, Apr 14, 2009 at 2:55 PM, Hannes Gredler <[email-masked]> wrote:
> Robert Raszuk wrote:
>>
>> As Dave points out there is "significant amounts of shared code" between
>> L3 ISIS & TRILL-ISIS and IMHO it does make sense to keep isis-wg in the
>> loop.

The Quagga IS-IS implementation supports both.

> hehe, i was playing devils advocate here ;-) ... i'll find it worry some
> that
> the "significant" portion is shrinking for no good reason ...
>
> i am terribly sorry but i need to bring up an old question again:
>
> why are there separate PDUs for multicast LSPs and SNPs ? -

Answers to that question have been posted several times to the ISIS WG
mailing list. I gather the answers do not satisfy you...

> most implementation keep all sort of internal databases,
> so practically there is a already a separation between unicast
> and multi cast - why do we need to change the on-wire representation
> of multi-ast data (= new PDU) while the same stuff can be carried in
> vanilla LSPs as well. the latest version of the draft does not contain
> answers on that matter, although being promised ...

Which draft are you talking about? As far as I know, the additional
PDUs first showed up in draft-ward-l2isis. Because they were there, I
put them in draft-eastlake-trill-rbridge-isis and they are now in
draft-ietf-isis-layer2. But I don't think they have ever been
mentioned in any TRILL WG draft and I don't off hand recall much
discussion of them in the TRILL WG.

Thanks,
Donald

> why do we think that app. 375KB of LSP space to store multicast
> information is not enough, and if so why don't we reuse the LSP-ext
> draft for adding more space.
>
> /hannes

>>> Robert Raszuk wrote:
>>>>
>>>> It seems to me just like section 4.2.4.3 Hello Contents of the above
>>>> draft says there is sufficiently large number of optional information usable
>>>> for TRILL which could be added to today's ISIS header that perhaps it may
>>>> make sense to just define it as separate TRILL-Hello msg.
>>>> My point was that in the same time the padding issue would be solved yet
>>>> a lot of already available code for L3 ISIS could be reused.
>>>
>>> so we have now separate L2-encaps, separate IIH, separate LSP and
>>> separate SNP PDUs
>>> - all of that with changed semantics ...
>>>
>>> sounds to me much more like a new protocol, than something vendors can
>>> integrate
>>> in their existing IS-IS implementation.
>>>
>>> if we want to further walk down that road, we should name the beast
>>> TRILL-something
>>> and drop the isis-wg groups involvement, since this is not IS-IS any
>>> more.
>>>
>>> /hannes

---

From: James Carlson <[email-masked]>
Date: Tue, 14 Apr 2009 16:25:01 -0400

> The Quagga IS-IS implementation supports both.

Minor refinement to that: we (Sun) have an experimental branch of the
Quagga IS-IS code that currently supports both, available through
opensolaris.org.  We're doing active development on the TRILL portion
now, and will certainly have to retest and verify the regular L3 IS-IS
when we're done.

---

From: Kris Price <[email-masked]>
Date: Wed, 15 Apr 2009 14:46:53 +1200

> network-wide MTU problem.

Ok.

I didn't really think it was a separate topic since it always shows up 
in conjunction with Radia's MTU discovery proposal, and affects how that 
proposed MTU discovery happens (or even if it happens).

Since there's an apparent split and lack of public progresson on that 
issue, I thought move on tackle something that should be easier to have 
consensus on. Low hanging fruit, etc. I'll give it another shot...

As you suggest, here's a new thread then. There has been no doubt that a 
more robust mechanism for electing DRBs must exist, whether it is 
unpadded hellos or a separate protocol is still up for debate. So 
ignoring that for now.

What do people want out of the network-wide MTU problem?

a) Some mechanism to ensure adjacencies always form, and to then adjust 
  the originatingLxLSPBufferSizes to ensure LSPs always flood throughout 
the whole network. I.e. preventing partitioned networks automatically. 
(See my previous couple of emails for backstory on this.)

This one is safe to ignore if you don't mind partitioned networks. It 
may be a problem solved in the future by the IS-IS WG as it affects IP 
networks as well.

b) Some mechanism to easily administratively set a network-wide MTU to 
control what links do or do not show up in paths. I.e. so an 
administrator can say my network MTU should always support 1500 byte 
frames, if you find a link less than that exclude it.

This one seems like an optional enhancement to me, not really TRILL's 
core business. But things like this would be nice to haves.

c) Both.

No point in expending more energy on MTU discovery unless there is 
consensus on one of those. So is it there?

Then move onto the how..

Regards

Kris

---

From: James Carlson <[email-masked]>
Date: Wed, 15 Apr 2009 09:07:27 -0400

Sadler, Jonathan B. writes:
> So why did James Carlson's implementation break when an 802.1ad Ethernet bridge (i.e. without .1Q extensions) was put between two RBridges?  Thats what started this whole discussion...

It's because slapping an extra header on top of a 1500 octet message
tends to make it somewhat larger than 1500 octets.  :-/

Right now, TRILL headers are effectively part of the payload, as far
as ordinary bridges are concerned, and are subject to the MTU
restrictions.  (Unlike "overhead" information between bridges, like
VLAN tags.)  If we could have access ports agree to use 1478 instead,
we'd be able to meet a 1500 restriction between RBridges.

Of course, that answer is just infeasible.

In testing, I've found that some devices limit to 1500 strictly.  Some
are lax up to about 1536.  Despite what standards may say about it,
there's a lot of odd stuff out in the field.

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Wed, 15 Apr 2009 09:34:50 -0700

> From: James Carlson [mailto:[email-masked]]
> Sent: Wednesday, April 15, 2009 6:07 AM
> To: Sadler, Jonathan B.
> Cc: Silvano Gai (sgai); Les Ginsberg (ginsberg); Radia Perlman; isis-
> [email-masked]; TRILL/RBridge Working Group
> > So why did James Carlson's implementation break when an 802.1ad
Ethernet
> bridge (i.e. without .1Q extensions) was put between two RBridges?
Thats
> what started this whole discussion...
> 

Indeed - the point being that whatever bad things that happen to large
size L2IS-IS PDUs will also happen to large size data PDUs that are
TRILL encapsulated.

So the question I would like folks to consider is whether there is a
point in trying to utilize a LAN on which only small data packets can be
guaranteed to be forwarded successfully? If the answer is "no" then I
think the problem that needs to be solved is constrained and the set of
appropriate solutions becomes more easily defined.

   Les

---

From: Don Fedyk <[email-masked]>
Date: Wed, 15 Apr 2009 13:58:56 -0400

Hi Kris, James

Framing the problem (and eventual solution) correctly is the whole issue
here.

The first and main problem is that minimum MTU may on rare occasions on
specific links fall below 1492, and if this happens Trill current design
which is essentially embedded in IS-IS has an issue.
I think this problem should be solved outside of the current IS-IS protocol
and state machine.

The second and not so simple problem is to make IS-IS adjust in some form
for operation when there is a smaller minimum MTU. This is a hard
problem. In my opinion this topic should be punted to some research group or
dropped altogether.

There are small modifications needed to IS-IS for Trill.  Yes there are new
TLVs, Yes there is some new SPF algorithms for the new TLVs.  But changing
"minimum MTU" logic has caused endless churn as we relive the design
decisions of IS-IS.

A simple Trill discovery protocol that can navigate links with smaller
minimum MTU is all that is required.   When Trill discovery problem is
studied separately I could argue this is a more data efficient and a
more robust solution for RBridge discovery than IS-IS could give you.  This
happens outside of IS-IS and then you can use existing IS-IS + Trill TLVs
when this is successful.

Regards,
Don

---

From: "Jeff Pickering" <[email-masked]>
Date: Wed, 15 Apr 2009 13:22:38 -0700

Yes, I remember this too. But I also seem to remember that something called
TCP had more to do with NLSP's issues. Not that Im promoting NLSP's particular
"solution".

- Jeff 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Dave Katz
Sent: Wednesday, April 15, 2009 3:13 PM
To: Sadler, Jonathan B.
Cc: TRILL/RBridge Working Group; Les Ginsberg (ginsberg); sgai; [email-masked]; James Carlson; Radia Perlman
Subject: Re: [Isis-wg] [rbridge] Why is MTU discovery important?

This is exactly the same problem that NLSP ran into 15 years ago  
(multiple encaps with different MTUs on Ethernet media.)  NLSP punted  
by requiring configuration of the max LSP size (IIRC), and there is  
existence proof <cough> that this is a non-starter.

--Dave

On Apr 15, 2009, at 8:21 AM, Sadler, Jonathan B. wrote:

> Exactly my point.  The "payload guaranteed" is different depending  
> on if you are looking at 802.1d or 802.1ad.  A 802.1ad "1500 byte  
> payload" will not make it through an 802.1d switch as the 802.1d  
> switch considers the 802.1Q shim as part of the payload - making the  
> overall frame size larger than the 1500 byte max it is required to  
> support.
>
> I agree there are "lax" devices out there.  Needless to say, the  
> need for "MTU discovery" comes from those that limit MTU to the 1500  
> byte definition found in 802.1d.
>
> Jonathan Sadler

---

From: "Ali Sajassi (sajassi)" <[email-masked]>
Date: Wed, 15 Apr 2009 15:05:43 -0700

The whole loop issue that we are talking in here can also happen in IEEE
bridged network !!

In 802.1ah, the Back Bone Core (BCB) bridges are of type S-VLAN which
means they can be limited to support max frame size of 1522 (1500 bytes
of payload + 22 bytes of header). However, if the original customer
payload is 1500 bytes, then with additional 802.1ah header, the total
frame size becomes more than 1522 and thus can get dropped by BCBs. This
drop of customer frames can include BPDUs which means if the customer
network is multi-homed to the service provider network (PBN/PBBN), then
it would put its multi-homed ports in the forwarding state and thus
causing a loop over the provider network.

The way IEEE is addressing this MTU issue is via 802.3as amendment (to
802.3 spec) which increases the frame size to 2000 byte (with 1500 bytes
for payload) - e.g., there can by 500 bytes of header and overhead. 

So, a simple fix to this problem is to put a simple text in the TRILL
spec mandating that all Ethernet links to support 802.3as
maxEnvelopeFrameSize. This way, you don't need to do any fiddling with
IS-IS protocol.

Furthermore, as Les mentioned, if the link can send some small sized
frames but not some other larger frames, then besides control plane
issues, you will have dropped frames in customer data which is not
acceptable - e.g., a service that can work for some frame size but not
some other ones !! 

So to have a simple solution with a consistent and deterministic
behavior, we should expect that all Ethernet links behave the same
(e.g., they all support 802.3as). 

Cheers,
Ali

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Les Ginsberg 
> (ginsberg)
> Sent: Wednesday, April 15, 2009 9:35 AM
> To: James Carlson; Sadler, Jonathan B.
> Cc: TRILL/RBridge Working Group; Silvano Gai (sgai); Radia 
> Perlman; [email-masked]
> Indeed - the point being that whatever bad things that happen 
> to large size L2IS-IS PDUs will also happen to large size 
> data PDUs that are TRILL encapsulated.
> 
> So the question I would like folks to consider is whether 
> there is a point in trying to utilize a LAN on which only 
> small data packets can be guaranteed to be forwarded 
> successfully? If the answer is "no" then I think the problem 
> that needs to be solved is constrained and the set of

---

From: Don Fedyk <[email-masked]>
Date: Wed, 15 Apr 2009 20:52:44 -0400

Ali
A few points in line. (this time cc the list)

> The whole loop issue that we are talking in here can also happen in IEEE

Not exactly. Yes 802.1ah frames can be dropped but this does not mean a
loop. It means certain frames will be dropped. If the frames were Bridge
Protocol Data Units (BDPUs) yes things would get ugly.  However BDPUs are
not padded to my knowledge so they are unlikely to be dropped for this
particular reason.

So to be precise here minimum MTU is affected by larger encapsulation
agreed,  but bridges don't have the designated forwarding mode of RBridges.
Please be precise because this behaviour is unique to RBridges as far as I
can tell.  802.1aq Shortest path bridging would use the normal mechanism for
IS-IS MTU too small. SPB would use the usual response if an IS-IS adjacency
does not come because of MTU or other issues up that particular link is
disabled.

> maxEnvelopeFrameSize. This way, you don't need to do any fiddling with

Agreed this would reduce the likelihood but like I said before that Trill
discovery should be outside IS-IS.

> (e.g., they all support 802.3as).

I believe 802.3as will take some time to deploy.  However I agree with your
point in that there is always a minimum MTU that Trill could use
consistently in a network. It could use 1492 if 802.3as is implemented if
not it could probably use 1450.  But  that is separate from the Trill
Discovery issue.

Regards,
Don

---

From: "Ali Sajassi (sajassi)" <[email-masked]>
Date: Wed, 15 Apr 2009 19:42:15 -0700

Don,

	From: Don Fedyk [mailto:[email-masked]] 
	Sent: Wednesday, April 15, 2009 5:53 PM
	To: Ali Sajassi (sajassi)
	Cc: Les Ginsberg (ginsberg); James Carlson; Sadler, Jonathan B.;
TRILL/RBridge Working Group; Silvano Gai (sgai); Radia Perlman;
[email-masked]
	Subject: Re: [Isis-wg] [rbridge] Why is MTU discovery important?

	Ali

	On Wed, Apr 15, 2009 at 6:05 PM, Ali Sajassi (sajassi)
<[email-masked]> wrote:

		The whole loop issue that we are talking in here can
also happen in IEEE
		bridged network !!

	Not exactly. Yes 802.1ah frames can be dropped but this does not
mean a loop. It means certain frames will be dropped. If the frames were
Bridge Protocol Data Units (BDPUs) yes things would get ugly.  However
BDPUs are not padded to my knowledge so they are unlikely to be dropped
for this particular reason.  
	 
	With max BPDU size and other overheads (mac-sec/nested level of
mac-sec and/or nested level of .1ad/.1ah), it can get to or exceed that
magical 1500 bytes !! 

	So to be precise here minimum MTU is affected by larger
encapsulation agreed,  but bridges don't have the designated forwarding
mode of RBridges.  Please be precise because this behaviour is unique to
RBridges as far as I can tell.  802.1aq Shortest path bridging would use
the normal mechanism for IS-IS MTU too small. SPB would use the usual
response if an IS-IS adjacency does not come because of MTU or other
issues up that particular link is disabled.  

	I think  the loop scneario is in common to both TRILL and IEEE.
If case of TRILL,  the c-bridged network is dual-homed to an Rbridged
network and the Rbridge network via IS-IS DRB mechanism wants to only
have a single port per VLAN in forwarding mode. In case of IEEE, the
c-bridged network is dual-homed to a 802.1ad/802.1ah network and in
port-mode the .1ad/.1ah network tunnels c-bridged network BPDU and the
blocking is done by the c-bridged network. However, the loss of BPDUs
causes the c-bridge network to activate its multi-homed ports and thus
causing loop. The difference is that in case of IEEE scenario, the
blocking is performed by c-bridged network and its BPDUs is tunneled by
.1ad/.1ah network; whereas, in case of TRILL scenario, the blocking is
performed by the Rbridged network and its is-is hello is tunneled by the
c-bridged network. In either case, the loss of hellos or BPDUs causes
loop. 

		
		In 802.1ah, the Back Bone Core (BCB) bridges are of type
S-VLAN which
		means they can be limited to support max frame size of
1522 (1500 bytes
		of payload + 22 bytes of header). However, if the
original customer
		payload is 1500 bytes, then with additional 802.1ah
header, the total
		frame size becomes more than 1522 and thus can get
dropped by BCBs. This
		drop of customer frames can include BPDUs which means if
the customer
		network is multi-homed to the service provider network
(PBN/PBBN), then
		it would put its multi-homed ports in the forwarding
state and thus
		causing a loop over the provider network.
		
		The way IEEE is addressing this MTU issue is via 802.3as
amendment (to
		802.3 spec) which increases the frame size to 2000 byte
(with 1500 bytes
		for payload) - e.g., there can by 500 bytes of header
and overhead.
		
		So, a simple fix to this problem is to put a simple text
in the TRILL
		spec mandating that all Ethernet links to support
802.3as
		maxEnvelopeFrameSize. This way, you don't need to do any
fiddling with
		IS-IS protocol.

	Agreed this would reduce the likelihood but like I said before
that Trill discovery should be outside IS-IS.  
	 
	I am not talking about TRILL discovery. I am saying that TRILL
should simply mandate the use of 802.3as which is now part of 802.3 base
spec on all its Ethernet link to avoid this type of MTU issue and have a
clean solution w/o fiddling w/ is-is. Otherwise, you can run into this
type of issue when you turn on mac-sec on a link or some other features
w/ additional header bytes. 

		
		Furthermore, as Les mentioned, if the link can send some
small sized
		frames but not some other larger frames, then besides
control plane
		issues, you will have dropped frames in customer data
which is not
		acceptable - e.g., a service that can work for some
frame size but not
		some other ones !!
		
		So to have a simple solution with a consistent and
deterministic
		behavior, we should expect that all Ethernet links
behave the same
		(e.g., they all support 802.3as).

	I believe 802.3as will take some time to deploy.  However I
agree with your point in that there is always a minimum MTU that Trill
could use consistently in a network. It could use 1492 if 802.3as is
implemented if not it could probably use 1450.  But  that is separate
from the Trill Discovery issue. 
	 
	With 802.3as, TRILL can use payload of 1500 bytes and so no
changes is required. Without it, then it should set the max MTU size to
1498 (1522-24) or 1494 (1518-24).
	 
	Cheers,
	Ali

	Regards,
	Don 

		Cheers,
		Ali

		
		> > Cc: Silvano Gai (sgai); Les Ginsberg (ginsberg);
Radia
		> Perlman; isis-
		> > It's because slapping an extra header on top of a
1500
		> octet message
		> > VLAN tags.)  If we could have access ports agree to
use
		> 1478 instead,
		> > In testing, I've found that some devices limit to
1500
		> strictly.  Some
		> > 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

---

From: Kris Price <[email-masked]>
Date: Thu, 16 Apr 2009 18:58:51 +1200

> appropriate solutions becomes more easily defined.

I was split on this. If TRILL just targetted the LAN then no. But TRILL 
seems to target the WAN in some cases, which is where MTU issues become 
more common and aren't solved by just saying "replace that old hub". In 
some respects I still think it will be less of a problem in the future 
when TRILL is common, but since it shouldn't be so difficult to solve, I 
don't see why not.

And lets be honest, if TRILL is a success (as it should be) then it will 
be used in all kinds of situations that could be considered whacky and 
were never envisioned. So now I'm a yes.

Whether data frames are dropped is not a problem IMO. People expect that 
L2 frames will be silently dropped in this case, and that maybe they 
have to take administrative action of some sort or use an L3 protocol 
that does MTU discovery, and they should be understanding of the fact 
that TRILL adds overhead.

So TRILL needs to be capable of working over low MTU links, either 
through automatic discovery/healing, or at least through administrative 
configuration (which worst case can be done by configuring the MTU and 
originatingLxLSPBufferSize on all your hosts).

---

From: James Carlson <[email-masked]>
Date: Thu, 16 Apr 2009 08:15:00 -0400

> maxEnvelopeFrameSize. This way, you don't need to do any fiddling with

That simple fix assumes that every equipment vendor of every box
located _between_ the RBridges is somehow compelled to comply with the
new specification.

That's perhaps fine as a matter of specification, but in the real
world, it doesn't work like that.  Writing a new requirement on paper
doesn't cause the firmware or hardware in those boxes to get updated,
which means that it *is* necessary to detect and cope with failures.

> acceptable - e.g., a service that can work for some frame size but not

Yes, that's why MTU discovery is itself also important.  Detecting and
avoiding loops is *MORE* important, but as you rightly note, it's not
sufficient.

> (e.g., they all support 802.3as). 

I can't build a deployable system like that.  The first obvious
question for any user or design reviewer is, "so, what happens if your
expectation is not met?"  The answer can't possibly be that the target
network goes down in a hail of replicated packets.

We're building systems, not just specifications.

---

From: James Carlson <[email-masked]>
Date: Thu, 16 Apr 2009 12:46:43 -0400

Ali Sajassi (sajassi) writes:
> B) lower the default MTU size originatingLxLSPBufferSize to accommodate
> for the 24 bytes of TRILL overhead
[...]
> The advantage of option (B) is that it works with existing deployed
> gears but it only works for is-is control messages and not data, right? 

No, I don't believe that's true.  If it works for the IS-IS control
messages, then this means we have sufficient information to make the
right decisions for the forwarding system as well.

In TRILL, IS-IS isn't just a black box off to one side.  It's an
integral part of how TRILL (and RBridges) operate, so crucial
information (such as enabling and disabling forwarding and detecting
failure modes) is derived directly from IS-IS control information.

> If the objective is to use TRILL control protocol to enable a single
> designated forwarder per VLAN on the multi-homed c-bridged network and
> only send/receive .1Q frames to/from c-bridged network (e.g., w/o TRILL
> encap), then option (B) should be sufficient.

There are multiple issues here, one of which is that the IS-IS MTU and
the data MTU are (quite unfortunately) different by a constant factor
on Ethernet alone, due to encapsulation changes in the -10 draft.
Things would be much simpler indeed (both to document and to
implement) if it were reverted back.  :-<

Yes, (B) plus some additional language in the TRILL documents
explaining the rules for enabling and disabling forwarding on a
network in light of the MTU would do the job.

---

From: "Ali Sajassi (sajassi)" <[email-masked]>
Date: Thu, 16 Apr 2009 09:35:44 -0700

James,

The point that I was making in my last email, was to have a uniform MTU
size on all Ethernet links in the network (both TRILL & c-bridged net)
in order to avoid fiddling with is-is hello/mtu discovery procedures and
the two options are:

A) require bridges (both Rbridges and c-bridges) to support
maxEnvelopeFrameSize of 2000 as in 802.3 spec.

The advantage of option (A) is that, it works for both control & data;
however, its disadvantage is that it requires all gears to support this
max MTU size which is easier said than done as you rightly pointed out.

Cheers,
Ali 

> Sent: Thursday, April 16, 2009 5:15 AM
> Cc: Les Ginsberg (ginsberg); Sadler, Jonathan B.; 
> TRILL/RBridge Working Group; Silvano Gai (sgai); Radia 
> That simple fix assumes that every equipment vendor of every 
> box located _between_ the RBridges is somehow compelled to 
> comply with the new specification.
> 
> That's perhaps fine as a matter of specification, but in the 
> real world, it doesn't work like that.  Writing a new 
> requirement on paper doesn't cause the firmware or hardware 
> in those boxes to get updated, which means that it *is* 
> necessary to detect and cope with failures.
> 
> Yes, that's why MTU discovery is itself also important.  
> Detecting and avoiding loops is *MORE* important, but as you 
> rightly note, it's not sufficient.
> 
> I can't build a deployable system like that.  The first 
> obvious question for any user or design reviewer is, "so, 
> what happens if your expectation is not met?"  The answer 
> can't possibly be that the target network goes down in a hail 
> of replicated packets.
>

---

From: Donald Eastlake <[email-masked]>
Date: Thu, 16 Apr 2009 21:18:37 -0400

Eric,

Sorry if my message wasn't clear. See below...

> characterizing possible solution choices to the problem.

My characterization of the problem was as follows: "There have to be
two different messages. (Actually, it's at least two, since you can
always come up with even more complex schemes.)". I continue to
believe that is a correct, if limited, characterization of the
problem.

> in light of the many aspects of the current discussion.

I said "Consider the follows two possible pairs of messages:" and
discussed two possible pairs. I didn't claim these were the only
choices. Sorry you disagree with my opinions on these messages.

>   is a version 1 RBridge but no hello messages are received.

No, there is no way a simple message will work. It has to include the
priority and holding time for DRB determination (unless you want to
add one or more additonal kinds of message to the mix which would also
have to be short). It has to include the Designated VLAN for proper
exchange of IS-IS Neighbor TLVs and adjacency  formation to occur. It
has to include other fields and flags as I've discussed before in this
thread. It has to be securable, so you have to invent a new security
mechanism or support the IS-IS Security TLV.

As has been pointed out by Jim Carlson, the only person that I know
has running code, a padded Hello plus a small simple ping will fail.

>   could and up being as complex as re-invention of IS-IS protocol.

I do not believe that adding a padded ping and coupling it to the
adjacency mechanism would be as complex as re-inventing the entire
IS-IS protocol. However, it is possible to oversimplify what would be
involved in a padded ping. For example, it would also need to be
securable...

> realize that this is a more accurate characterization of the choices.

I have thought about and I still think that a padded Hello plus a
simple unpadded ping will fail. You clearly need two messages (or
more) but thinking about it, I'm dubious that either of the two can be
made really simple.

Donald

---

From: Donald Eastlake <[email-masked]>
Date: Thu, 16 Apr 2009 21:42:32 -0400

2009/4/11 Dave Katz <[email-masked]>:
> As someone who as been designing and coding this stuff since before most of
> our current crop of engineers were born, I'll throw in some practicalities:
> 1)  The thing we call "IS-IS" that has a NLPID of 0x83 (IIRC) can only be
> changed in an upward-compatible manner.  So any proposal to change anything
> in the existing L3 IS-IS beyond the addition of a new PDU type is a
> non-starter (and even that is likely to break some dubious implementations,
> which may or may not be a bad thing).

Yes, the IS-IS NLPID is 0x83. I believe changes beyond the addition of
PDU / TLV / aub-TLV will be needed.

> mechanism) it can do things any which way it pleases.  It is best from an
> implementation perspective to keep it as close to IS-IS as possible so that
> a single implementation with a few checks here and there can do both.  This
> has the added advantage that foolish implementors will cut-and-paste the
> code and create themselves maintenance problems and allow Darwinian
> selection to occur, like back in the NLSP days.  ;-)  But it is entirely
> possible to share 99% of the code while maintaining protocol "distinctness."
>  And having it distinct from IS-IS avoids having to be forced to make

I think it is probably a good idea for TRILL IS-IS to have a different NLPID.

Donald

>> ...

---

From: Don Fedyk <[email-masked]>
Date: Thu, 16 Apr 2009 22:24:22 -0400

Ali

You are adding unnecessary confusion to this thread.

On the IEEE 802.1 Bridge Protocol Data Units (BDPU) point. BDPUs do not grow
to any where near 1500 bytes at this point in time.  Therefore loss of BDPUs
or looping due to loss of BDPUs is not an 802.1 issue.

Possible Loss of Frames due to too small MTU is purely a TRILL & IS-IS
combination issue.

802.as is not a bad idea.  802.3as helps applications that use Ethernet
maintain the 1500 byte minimum MTU limit by increasing the headroom of
Ethernet.

Regards,
Don

On Wed, Apr 15, 2009 at 10:42 PM, Ali Sajassi (sajassi)
<[email-masked]>wrote:

>  Don,
>
>  ------------------------------
> *From:* Don Fedyk [mailto:[email-masked]]
> *Sent:* Wednesday, April 15, 2009 5:53 PM
> *To:* Ali Sajassi (sajassi)
> *Cc:* Les Ginsberg (ginsberg); James Carlson; Sadler, Jonathan B.;
> *Subject:* Re: [Isis-wg] [rbridge] Why is MTU discovery important?
>
>
> Ali
> With max BPDU size and other overheads (mac-sec/nested level of mac-sec
> and/or nested level of .1ad/.1ah), it can get to or exceed that magical 1500
> bytes !!
>
>
>  I think  the loop scneario is in common to both TRILL and IEEE. If case
> of TRILL,  the c-bridged network is dual-homed to an Rbridged network and
> the Rbridge network via IS-IS DRB mechanism wants to only have a single port
> per VLAN in forwarding mode. In case of IEEE, the c-bridged network is
> dual-homed to a 802.1ad/802.1ah network and in port-mode the .1ad/.1ah
> network tunnels c-bridged network BPDU and the blocking is done by the
> c-bridged network. However, the loss of BPDUs causes the c-bridge network to
> activate its multi-homed ports and thus causing loop. The difference is that
> in case of IEEE scenario, the blocking is performed by c-bridged network and
> its BPDUs is tunneled by .1ad/.1ah network; whereas, in case of TRILL
> scenario, the blocking is performed by the Rbridged network and its is-is
> hello is tunneled by the c-bridged network. In either case, the loss of
> hellos or BPDUs causes loop.
>
>
>
>>
>>
> I am not talking about TRILL discovery. I am saying that TRILL should
> simply mandate the use of 802.3as which is now part of 802.3 base spec on
> all its Ethernet link to avoid this type of MTU issue and have a clean
> solution w/o fiddling w/ is-is. Otherwise, you can run into this type of
> issue when you turn on mac-sec on a link or some other features
> With 802.3as, TRILL can use payload of 1500 bytes and so no changes is
> required. Without it, then it should set the max MTU size to 1498
> (1522-24) or 1494 (1518-24).
>
> Cheers,
> Ali
>
>
> Regards,
> Don
>
>>
>>
>> Cheers,
>> Ali
>>
>> <snip>
>>
>

---

From: "Ali Sajassi (sajassi)" <[email-masked]>
Date: Thu, 16 Apr 2009 20:03:34 -0700

Don,
 
I thought we already discussed this on a separate thread with Mick
Seaman and I already pointed out how with the nested mac-sec/.1ad/.1ah
you can exceed that limit (if you also refer to my email on this thread,
I explicitly mentioned nested mac-sec/.1ad/.1ah). Although it is granted
that the scenario in which customer BPDU size (over .1ah network) to
exceed 1500 bytes is much less likely than in TRILL, the points that I
was making still hold:
 
Similarity between the two:
 
1- In TRILL, hello messages are tunneled over customer network; whereas,
in IEEE, customer BPDUs are tunneled over provider network. In either
scenario, the loss of hellos or BPDUs can cause loop although the
likelihood of BPDU loss in IEEE is much less than the hello loss in
TRILL
 
2- In both TRILL and IEEE, control packets can be lost because of
additional encapsulation overhead. In TRILL, LSPs that exceed 1500 bytes
will be lost with indeterministic effect on the network and in IEEE
MVRP, MMRP, and other control packets that exceed 1500 bytes will be
lost with undesirable effect on the network
 
3- In both TRILL and IEEE, customer data frames that exceed 1500 bytes
can be lost with again undesirable effect.
 
I am pointing out that the solution which is common between both IEEE &
TRILL is 802.3as which allows for about 500 bytes of header overhead and
avoid these encapsulation pitfalls.
 
Now the other option for TRILL that we have discussed in this thread is
to reduce the MTU size (network wide) for both data & control packets to
allow for 24 bytes of TRILL overhead without changing existing IS-IS MTU
discovery/hello procedures but frankly I am wondering how feasible this
can be because some of the applications (clients of Ethernet) may assume
MTU size of 1500 bytes !!
 
Cheers,
Ali 

	Sent: Thursday, April 16, 2009 7:24 PM

	Ali

	On the IEEE 802.1 Bridge Protocol Data Units (BDPU) point. BDPUs
do not grow to any where near 1500 bytes at this point in time.
Therefore loss of BDPUs or looping due to loss of BDPUs is not an 802.1
issue. 
	 
	Possible Loss of Frames due to too small MTU is purely a TRILL &
IS-IS combination issue. 
	 
	802.as is not a bad idea.  802.3as helps applications that use
Ethernet maintain the 1500 byte minimum MTU limit by increasing the
headroom of Ethernet.  
	 
	Regards,
	Don 

		Don,

			From: Don Fedyk [mailto:[email-masked]] 
			Sent: Wednesday, April 15, 2009 5:53 PM
			To: Ali Sajassi (sajassi)
			Cc: Les Ginsberg (ginsberg); James Carlson;
Sadler, Jonathan B.; TRILL/RBridge Working Group; Silvano Gai (sgai);
Radia Perlman; [email-masked] 

			Subject: Re: [Isis-wg] [rbridge] Why is MTU
discovery important?

			Ali

			On Wed, Apr 15, 2009 at 6:05 PM, Ali Sajassi
(sajassi) <[email-masked]> wrote:

				The whole loop issue that we are talking
in here can also happen in IEEE
				bridged network !!

			Not exactly. Yes 802.1ah frames can be dropped
but this does not mean a loop. It means certain frames will be dropped.
If the frames were Bridge Protocol Data Units (BDPUs) yes things would
get ugly.  However BDPUs are not padded to my knowledge so they are
unlikely to be dropped for this particular reason.  
			 
			With max BPDU size and other overheads
(mac-sec/nested level of mac-sec and/or nested level of .1ad/.1ah), it
can get to or exceed that magical 1500 bytes !! 

			So to be precise here minimum MTU is affected by
larger encapsulation agreed,  but bridges don't have the designated
forwarding mode of RBridges.  Please be precise because this behaviour
is unique to RBridges as far as I can tell.  802.1aq Shortest path
bridging would use the normal mechanism for IS-IS MTU too small. SPB
would use the usual response if an IS-IS adjacency does not come because
of MTU or other issues up that particular link is disabled.  

			I think  the loop scneario is in common to both
TRILL and IEEE. If case of TRILL,  the c-bridged network is dual-homed
to an Rbridged network and the Rbridge network via IS-IS DRB mechanism
wants to only have a single port per VLAN in forwarding mode. In case of
IEEE, the c-bridged network is dual-homed to a 802.1ad/802.1ah network
and in port-mode the .1ad/.1ah network tunnels c-bridged network BPDU
and the blocking is done by the c-bridged network. However, the loss of
BPDUs causes the c-bridge network to activate its multi-homed ports and
thus causing loop. The difference is that in case of IEEE scenario, the
blocking is performed by c-bridged network and its BPDUs is tunneled by
.1ad/.1ah network; whereas, in case of TRILL scenario, the blocking is
performed by the Rbridged network and its is-is hello is tunneled by the
c-bridged network. In either case, the loss of hellos or BPDUs causes
loop. 

				
				In 802.1ah, the Back Bone Core (BCB)
bridges are of type S-VLAN which
				means they can be limited to support max
frame size of 1522 (1500 bytes
				of payload + 22 bytes of header).
However, if the original customer
				payload is 1500 bytes, then with
additional 802.1ah header, the total
				frame size becomes more than 1522 and
thus can get dropped by BCBs. This
				drop of customer frames can include
BPDUs which means if the customer
				network is multi-homed to the service
provider network (PBN/PBBN), then
				it would put its multi-homed ports in
the forwarding state and thus
				causing a loop over the provider
network.
				
				The way IEEE is addressing this MTU
issue is via 802.3as amendment (to
				802.3 spec) which increases the frame
size to 2000 byte (with 1500 bytes
				for payload) - e.g., there can by 500
bytes of header and overhead.
				
				So, a simple fix to this problem is to
put a simple text in the TRILL
				spec mandating that all Ethernet links
to support 802.3as
				maxEnvelopeFrameSize. This way, you
don't need to do any fiddling with
				IS-IS protocol.

			Agreed this would reduce the likelihood but like
I said before that Trill discovery should be outside IS-IS.  
			 
			I am not talking about TRILL discovery. I am
saying that TRILL should simply mandate the use of 802.3as which is now
part of 802.3 base spec on all its Ethernet link to avoid this type of
MTU issue and have a clean solution w/o fiddling w/ is-is. Otherwise,
you can run into this type of issue when you turn on mac-sec on a link
or some other features w/ additional header bytes. 

				
				Furthermore, as Les mentioned, if the
link can send some small sized
				frames but not some other larger frames,
then besides control plane
				issues, you will have dropped frames in
customer data which is not
				acceptable - e.g., a service that can
work for some frame size but not
				some other ones !!
				
				So to have a simple solution with a
consistent and deterministic
				behavior, we should expect that all
Ethernet links behave the same
				(e.g., they all support 802.3as).

			I believe 802.3as will take some time to deploy.
However I agree with your point in that there is always a minimum MTU
that Trill could use consistently in a network. It could use 1492 if
802.3as is implemented if not it could probably use 1450.  But  that is
separate from the Trill Discovery issue. 
			 
			With 802.3as, TRILL can use payload of 1500
bytes and so no changes is required. Without it, then it should set the
max MTU size to 1498 (1522-24) or 1494 (1518-24).
			 
			Cheers,
			Ali

			Regards,
			Don 

				Cheers,
				Ali

				<snip>

---

From: Don Fedyk <[email-masked]>
Date: Fri, 17 Apr 2009 08:38:49 -0400

Hi Ali

Ali Sajassi (sajassi) wrote:
> you can exceed that limit (if you also refer to my email on this 
> thread, I explicitly mentioned nested mac-sec/.1ad/.1ah). Although it 
> is granted that the scenario in which customer BPDU size (over .1ah 
> network) to exceed 1500 bytes is much less likely than in TRILL, the 
> points that I was making still hold:
Mick said "It is clearly unthinkable that 802.1 would specify a network 
arrangement requiring the use of BPDUs which could not be sent." 
Less likely is approaching zero.
> 1- In TRILL, hello messages are tunneled over customer network; 
> whereas, in IEEE, customer BPDUs are tunneled over provider network. 
> In either scenario, the loss of hellos or BPDUs can cause loop 
> although the likelihood of BPDU loss in IEEE is much less than the 
> hello loss in TRILL
Not true.Under such infrequent error conditions IEEE scenarios will drop 
traffic. The loss BDPUs and other frames in this case is a normal 
degrade of traffic. What this thread is about is that RBridges connected 
to LANs of the C-VLAN variety assume they are the only RBridge connected 
to the LAN and assume a forwarding behavior (DRB)  that can cause  
looping if this assumption is incorrect.  Therefore it is imperative 
that RBridges  know that they are connected to the same LAN even if they 
have some mismatch with the minimum MTU.
Very different in my books.
> additional encapsulation overhead. In TRILL, LSPs that exceed 1500 
> bytes will be lost with indeterministic effect on the network and in 
> IEEE MVRP, MMRP, and other control packets that exceed 1500 bytes will 
> be lost with undesirable effect on the network
Again worlds apart.  IEEE Provider Backbone Bridging was prototyped, 
deployed and standardized without any fanfare on this issue. IEEE 
802.3as was a proactive increase in the IEEE minimum frames size to 
support a future where multiple encapsulation of the PBB variety could 
be envisioned and still support the 1500 limit.  There is no law that 
say you cannot break your network with certain configurations but if 
that network breaks it should do so gracefully.
> can be lost with again undesirable effect.
Thats why higher layer protocols support MTU detection and can adapt to 
smaller MTU (usually).   IS-IS  does not at present adapt to different 
minimum MTU on different links because once a minimum MTU is chosen any 
IS-IS node may fill LSPs to that size.  Ergo the MTU must be the same on 
all IS-IS nodes.  That is the other point on this thread.
>  
> I am pointing out that the solution which is common between both IEEE 
> & TRILL is 802.3as which allows for about 500 bytes of header overhead 
> and avoid these encapsulation pitfalls.
That is nice for new bridges and Provider Bridges (agreed)  but it may 
not be a condition that TRILL is willing to accept.
>  
> Now the other option for TRILL that we have discussed in this thread 
> is to reduce the MTU size (network wide) for both data & control 
> packets to allow for 24 bytes of TRILL overhead without changing 
> existing IS-IS MTU discovery/hello procedures but frankly I am 
> wondering how feasible this can be because some of the applications 
> (clients of Ethernet) may assume MTU size of 1500 bytes !!
Again the same point  above,  higher layer  protocols adapt.

Regards,
Don

>  
> Cheers,
> Ali 
>
>     ------------------------------------------------------------------------
>     *Sent:* Thursday, April 16, 2009 7:24 PM
>     Therefore loss of BDPUs or looping due to loss of BDPUs is not an
>     802.1 issue.
>      
>     802.as <http://802.as> is not a bad idea.  802.3as helps
>     applications that use Ethernet maintain the 1500 byte minimum MTU
>     limit by increasing the headroom of Ethernet.  
>      
>     Regards,
>     Don
>
>     <[email-masked] <mailto:[email-masked]>> wrote:
>
>         Don,
>
>             ------------------------------------------------------------------------
>             *From:* Don Fedyk [mailto:[email-masked]
>             <mailto:[email-masked]>]
>             *Cc:* Les Ginsberg (ginsberg); James Carlson; Sadler,
>             Jonathan B.; TRILL/RBridge Working Group; Silvano Gai
>             (sgai); Radia Perlman; [email-masked]
>             <mailto:[email-masked]>
>
>             <[email-masked] <mailto:[email-masked]>> wrote:
>
>
>             Not exactly. Yes 802.1ah frames can be dropped but this
>             does not mean a loop. It means certain frames will be
>             dropped. If the frames were Bridge Protocol Data Units
>             (BDPUs) yes things would get ugly.  However BDPUs are not
>             padded to my knowledge so they are unlikely to be dropped
>             With max BPDU size and other overheads (mac-sec/nested
>             level of mac-sec and/or nested level of .1ad/.1ah), it can
>             get to or exceed that magical 1500 bytes !! 
>
>              
>             encapsulation agreed,  but bridges don't have the
>             designated forwarding mode of RBridges.  Please be precise
>             because this behaviour is unique to RBridges as far as I
>             can tell.  802.1aq Shortest path bridging would use the
>             normal mechanism for IS-IS MTU too small. SPB would use
>             the usual response if an IS-IS adjacency does not come
>             because of MTU or other issues up that particular link is
>             disabled.  
>              
>             I think  the loop scneario is in common to both TRILL and
>             IEEE. If case of TRILL,  the c-bridged network is
>             dual-homed to an Rbridged network and the Rbridge network
>             via IS-IS DRB mechanism wants to only have a single port
>             per VLAN in forwarding mode. In case of IEEE, the
>             c-bridged network is dual-homed to a 802.1ad/802.1ah
>             network and in port-mode the .1ad/.1ah network tunnels
>             c-bridged network BPDU and the blocking is done by the
>             c-bridged network. However, the loss of BPDUs causes the
>             c-bridge network to activate its multi-homed ports and
>             thus causing loop. The difference is that in case of IEEE
>             scenario, the blocking is performed by c-bridged
>             network and its BPDUs is tunneled by .1ad/.1ah network;
>             whereas, in case of TRILL scenario, the blocking is
>             performed by the Rbridged network and its is-is hello is
>             tunneled by the c-bridged network. In either case, the
>             loss of hellos or BPDUs causes loop. 
>              
>              
>
>
>
>             Agreed this would reduce the likelihood but like I said
>             before that Trill discovery should be outside IS-IS.  
>              
>             I am not talking about TRILL discovery. I am saying that
>             TRILL should simply mandate the use of 802.3as which is
>             now part of 802.3 base spec on all its Ethernet link to
>             avoid this type of MTU issue and have a clean solution w/o
>             fiddling w/ is-is. Otherwise, you can run into this type
>             of issue when you turn on mac-sec on a link or some other
>             features w/ additional header bytes. 
>              
>
>
>
>             I believe 802.3as will take some time to deploy.  However
>             I agree with your point in that there is always a minimum
>             MTU that Trill could use consistently in a network. It
>             could use 1492 if 802.3as is implemented if not it could
>             probably use 1450.  But  that is separate from the Trill
>             Discovery issue. 
>              
>             With 802.3as, TRILL can use payload of 1500 bytes and so
>             no changes is required. Without it, then it should set the

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Fri, 17 Apr 2009 10:51:18 -0700

> implement) if it were reverted back.  :-<
Treating IS-IS PDUs the same as data PDUs as far as L2 encapsulation
would be a good thing.

Is there some compelling reason NOT to do this?

   Les

---

From: "Ali Sajassi (sajassi)" <[email-masked]>
Date: Fri, 17 Apr 2009 12:53:50 -0700

Hi Don,

		2- In both TRILL and IEEE, control packets can be lost
because of additional encapsulation overhead. In TRILL, LSPs that exceed
1500 bytes will be lost with indeterministic effect on the network and
in IEEE MVRP, MMRP, and other control packets that exceed 1500 bytes
will be lost with undesirable effect on the network

	Again worlds apart.  IEEE Provider Backbone Bridging was
prototyped, deployed and standardized without any fanfare on this issue.
IEEE 802.3as was a proactive increase in the IEEE minimum frames size to
support a future where multiple encapsulation of the PBB variety could
be envisioned and still support the 1500 limit.  There is no law that
say you cannot break your network with certain configurations but if
that network breaks it should do so gracefully.  
	 
	 You are missing the point in there - we are not talking about
BEBs but BCBs. BCB bridges are supposed to be standard s-vlan aware
bridges which can be limited to 1516 or 1522 bytes in frame-size
handling  !! So, the problem that I describe above can easily happen. 
	 
	Cheers,
	Ali