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

From: [email-masked]
Date: Wed, 01 Apr 2009 13:01:37 +0100

Mike Shand said:

    So would it make more sense to leave the hellos, adjacency
establishment rules, DIS election exactly as it is for IS-IS and use
THAT for the IS-IS related stuff like generating pseudonodes, running
the LAN reliable update process and advertising connectivity, and then
have a new small TRILL hello which behaved the way you described and use
that for electing the DRB from the point of view of determining who does
the forwarding?

    Mike

****************************************

I don't think so. It's basically the same thing, with some different rules.
If we did the TRILL Hellos and DRB election, we wouldn't need the other
one also. So I think we should just modify the rules for TRILL.

It's possible we should even rewrite the spec for exactly how TRILL IS-IS should work.
There isn't any other IETF protocol that doesn't get updated every few years with new versions.

Radia

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

---

From: mike shand <[email-masked]>
Date: Thu, 02 Apr 2009 13:48:04 +0100

Radia,
    Re-reading draft-ietf-trill-rbridge-protocol-12, isn't the 
combination of adjacency hellos and protection hellos essentially the 
same as what I proposed below? So why are you proposing that it should 
be reversed to have non-padded IS-IS hellos (which would also have to 
have the IS-IS rules changed with respect to not using only UP 
adjacencies and still electing even when there are no other adjacencies) 
and (optional?) MTU discovery hellos, which interact in some yet to be 
completely specified way with the adjacency formation rules. Why is that 
better than what seems to be the natural approach of keeping the IS-IS 
stuff unchanged and adding something which has the required TRILL 
semantics for the identification of  the forwarders. It seems to have 
traded two hellos, one of which was identical to the existing IS-IS 
mechanisms, for two hellos, neither of which are the same as IS-IS.

    Mike

---

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

Mike,

Personally, I would have been OK with what was in the latest version
of the spec (I think I might even have been the one that suggested that 
solution
on the mailing list), but it did not get a warm reception at the WG 
meeting in San Fransisco. Two types of hellos, padded
and unpadded, being sent on different VLANs -- it seemed unnecessarily 
complicated, and indeed I kind of tripped
over my words as I was trying to describe it. People were saying that 
Hellos should be for finding neighbors, not
also for MTU discovery.

After hearing people's
concerns and suggestions, I described what I thought would go over 
better, and actually, I like it much better.

a) Hellos just as we'd specified it before Jim Carlson noticed the 
problem with padded hellos, but adding to the
spec that TRILL Hellos MUST NOT be padded.
b) Having a separate protocol, that actually works better I think, for 
MTU discovery, where to allow it to be optional,
we add a flag to the Hello saying "I support MTU discovery", and then 
having an MTU discovery protocol where R1
sends a padded message of some size, and other RBridges on the link that 
hear that message reply with an ack to R1.

Radia

mike shand wrote:
> adjacencies and still electing even when there are no other 
> adjacencies) and (optional?) MTU discovery hellos, which interact in 
> some yet to be completely specified way with the adjacency formation 
> rules. Why is that better than what seems to be the natural approach 
> of keeping the IS-IS stuff unchanged and adding something which has 
> the required TRILL semantics for the identification of  the 
> forwarders. It seems to have traded two hellos, one of which was 
> identical to the existing IS-IS mechanisms, for two hellos, neither of 
> which are the same as IS-IS.
>
>    Mike
>

---

From: "Eric Gray" <[email-masked]>
Date: Fri, 3 Apr 2009 06:03:46 -0500

Radia,

	I liked the wording of the second part of this better in your
previous posting - i.e. - where the mechanism used for MTU discovery
is clearly to be specified separately.

	As I mentioned during the meeting, there are capabilties at the
L2 level that can be used to determine the L2 MTU size.  Since this 
is clearly a general problem for L2 networks, defining a solution for
it in the IETF - particularly one that is very specific to a single
application - is probably not appropriate.

--
Eric

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Radia Perlman
Sent: Thursday, April 02, 2009 12:50 PM
To: TRILL/RBridge Working Group
Subject: Re: [rbridge] Proposed compromise for short/long hellos

Mike,

After hearing people's

Radia

---

From: mike shand <[email-masked]>
Date: Fri, 03 Apr 2009 12:29:28 +0100

Eric Gray wrote:

Radia,

But IS-IS requires the enforcement of a minimum MTU size to ensure that
its LSPs are correctly delivered and it already has the mechanism to do
that (in the padded hellos). Why change that?

Mike

--
Eric

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

Mike,

After hearing people's

Radia

mike shand wrote:

Radia,

Mike

---

From: "Eric Gray" <[email-masked]>
Date: Fri, 3 Apr 2009 08:56:29 -0500

Mike,
 
    Based on the discussion thus far, the ideal solution would be
something along
the lines of the following:
 
    1) Padding of IS-IS messages would be optional (we could argue what
the default
        would be) - and would be determined either by configuration, or
by any method
        an implementation may choose (for example, an implementation
might simply
        elect to remove padding if a sharp rise in congestion
indications is noted - for
        example, a sudden and continuous stream of buffer overflow
indications from
        forwarding components).
    2) RBridge implementations MUST NOT reject a hello message because
it is not
        padded - for whatever reason.
    3) RBridge implementations MUST NOT make any assumptions based on
the size
        of a hello PDU (such as guessing that this is the peer's MTU
size), unless there
        is an explicit indication that a specific hello PDU is padded.
 
I would argue that padding of the RBridge IS-IS messages would be done
if there is
any way for a specific implementation to be certain that the MTU size
used in padding 
is well known.  This would be the case if a pair of RBridge
implementations has any sort 
of MTU discovery mechanism that will determine an accurate MTU size, if
there is a
useful minimum MTU size defined for the technology (useful in that it is
large enough
to support at least a maximum size un-fragmentable control message), or
if the network
operator is certain enough of this size to enable padding.
 
    I would also argue that - if there is a mechanism capable of being
used for MTU 
discovery - MTU discovery/determination should occur BEFORE the DRB
(and/or 
designated forwarder) determination process begins (and certainly before
forwarding
begins), and would be repeated periodically after this is done.
 
--
Eric

________________________________

From: mike shand [mailto:[email-masked]] 
Sent: Friday, April 03, 2009 7:29 AM
To: Eric Gray
Cc: Radia Perlman; TRILL/RBridge Working Group
Subject: Re: [rbridge] Proposed compromise for short/long hellos
Importance: High

Eric Gray wrote: 

	Radia,
	
		I liked the wording of the second part of this better in
your
	previous posting - i.e. - where the mechanism used for MTU
discovery
	is clearly to be specified separately.
	
		As I mentioned during the meeting, there are capabilties
at the
	L2 level that can be used to determine the L2 MTU size.  Since
this 
	is clearly a general problem for L2 networks, defining a
solution for
	it in the IETF - particularly one that is very specific to a
single
	application - is probably not appropriate.

    Mike

	--
	Eric
	
	-----Original Message-----
	From: [email-masked]
[mailto:[email-masked]] On
	Behalf Of Radia Perlman
	Sent: Thursday, April 02, 2009 12:50 PM
	To: TRILL/RBridge Working Group
	Subject: Re: [rbridge] Proposed compromise for short/long hellos
	
	Mike,
	
	Personally, I would have been OK with what was in the latest
version
	of the spec (I think I might even have been the one that
suggested that 
	solution
	on the mailing list), but it did not get a warm reception at the
WG 
	meeting in San Fransisco. Two types of hellos, padded
	and unpadded, being sent on different VLANs -- it seemed
unnecessarily 
	complicated, and indeed I kind of tripped
	over my words as I was trying to describe it. People were saying
that 
	Hellos should be for finding neighbors, not
	also for MTU discovery.
	
	After hearing people's
	concerns and suggestions, I described what I thought would go
over 
	better, and actually, I like it much better.
	
	a) Hellos just as we'd specified it before Jim Carlson noticed
the 
	problem with padded hellos, but adding to the
	spec that TRILL Hellos MUST NOT be padded.
	b) Having a separate protocol, that actually works better I
think, for 
	MTU discovery, where to allow it to be optional,
	we add a flag to the Hello saying "I support MTU discovery", and
then 
	having an MTU discovery protocol where R1
	sends a padded message of some size, and other RBridges on the
link that

	Radia

	mike shand wrote:

		Radia,
		   Re-reading draft-ietf-trill-rbridge-protocol-12,
isn't the 
		combination of adjacency hellos and protection hellos
essentially the 
		same as what I proposed below? So why are you proposing
that it should

		be reversed to have non-padded IS-IS hellos (which would
also have to 
		have the IS-IS rules changed with respect to not using
only UP 
		adjacencies and still electing even when there are no
other 
		adjacencies) and (optional?) MTU discovery hellos, which
interact in 
		some yet to be completely specified way with the
adjacency formation 
		rules. Why is that better than what seems to be the
natural approach 
		of keeping the IS-IS stuff unchanged and adding
something which has 
		the required TRILL semantics for the identification of
the 
		forwarders. It seems to have traded two hellos, one of
which was 
		identical to the existing IS-IS mechanisms, for two
hellos, neither of

		
		   Mike

---

From: James Carlson <[email-masked]>
Date: Fri, 3 Apr 2009 11:08:45 -0400

>     1) Padding of IS-IS messages would be optional (we could argue what

No.  We can't do that, because it runs right into the original problem
that I described.

With "normal" IS-IS used for routing, the padding serves as a
protective device: if I can't hear your Hello messages because there's
an MTU restriction somewhere between us, then I won't peer with you,
and I won't try to route anything through you.  The failure mode is
only a loss of connectivity.

With IS-IS as used for TRILL, the padding is toxic.  If I can't hear
your Hello messages, then I'll assume that *I* am the DRB, and I'll
begin forwarding for all the VLANs I know about.  If you can't hear
me, you'll do the same.  And that potentially results in an L2
forwarding loop for all frames that are of a size less than the MTU
restriction: a very *BAD* failure mode.  It's the exact opposite of
the L3 routing scenario.

For Hellos used as a protective device, we *cannot* safely pad out to
the locally known MTU.

>     3) RBridge implementations MUST NOT make any assumptions based on

If either of those really needs to be specified, then I think we've
got much bigger problems to wrestle than just the MTU issue.

> begins), and would be repeated periodically after this is done.

Yes.  DRB selection must be conditional on it, which is why doing it
with the Hello messages is quite useful.  But we could obviously
specify something different.

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

---

From: "Don Fedyk" <[email-masked]>
Date: Fri, 3 Apr 2009 11:59:43 -0400

Hi James 

Please see inline:

> [mailto:[email-masked]] On Behalf Of James Carlson
> Sent: Friday, April 03, 2009 11:09 AM
> To: Eric Gray
> Cc: TRILL/RBridge Working Group; Radia Perlman
People are avioding the real issue here:

It is not the padding that is toxic.  It is the use of a discovery
protocol where the failure/absense of the protocol results in RBridges
self electing themselves the DRB.   Whether or not you use IS-IS hellos
to discover or some new fangled protocol, any failure of the discovery
protocol results in this undesirable behavior.  Yes IS-IS with padding
may be a less robust discovery protocol but it was not designed for this
purpose.   And repurposing the IS-IS design only reduses the problem it
does not eliminate it. 

Don

---

From: "Eric Gray" <[email-masked]>
Date: Fri, 3 Apr 2009 11:02:12 -0500

James,

	You took my message and replied to it in a way that seems
to deliberately remove relevant context.  If it was as deliberate 
as it seems, it would be questionable professional behavior.

	Presumably it was simply accidental.

	With the original context, you are merely agreeing with 
what I said, and arguing that padding should not be the default. 

	You should be aware that I have not - precisely - argued
that it should be the default.  In my opinion, if padding MUST
be on by default, then pair-wise MTU discovery MUST occur first.
Note that I am saying "MTU discovery", not the pass-fail form of
MTU verification that has so far been explicitly suggested in
this thread.

	The reason why the 2nd and third items would need to be 
specified is that doing so is necessary if you really want to
be allowed the option of not doing padding.  When people say
that we simply would not do the padding, what they have not 
explicitly added is the bit about "and everything that IS-IS 
implementations out there in the world might do based on the 
assumption that padding is used."

	And I've not really heard a proposal for doing MTU discovery
using the hello protocol.  At most, what has been proposed is MTU
verification, assuming that some value is assumed, or configured,
at each peer.

	Thanks!

--
Eric

---

From: James Carlson <[email-masked]>
Date: Fri, 3 Apr 2009 13:29:48 -0400

> 	Presumably it was simply accidental.

It must have been.  I have no clue what you're talking about.

> what I said, and arguing that padding should not be the default. 

No, I'm saying that it _can't_ be optional.  It has to be a MUST NOT,
and not an option.  That's why I was responding to that part of your
message.

It's required that RBridges be able to "see" each other if they're
connected by any other L2 forwarding mechanism, such as a traditional
802 bridge.

> MTU verification that has so far been explicitly suggested in

That's not clear to me.  How does this pairwise MTU discovery work?

If we make padding a "MUST NOT," and then invent a new mechanism for
MTU discovery, then I understand exactly how it works: you exchange
MTU-sized messages with all of your neighbors (as seen by Hello), and
if any of them fail, then you can handle that as an MTU-failed
adjacency.

If we do pairwise MTU discovery first, as I think you're suggesting,
then I don't see how that can function.  How does MTU discovery know
what peers must be checked?  Does it have its own discovery protocol
as well that runs first?

> assumption that padding is used."

I'm not following.  Can you clarify what those other things might be?

What other assumptions, besides verifying that the path can handle
MTU-sized messages, are implementations making?  If you know about
some other assumptions, I'd like to hear about them.

> verification, assuming that some value is assumed, or configured,

The MTU is verified by the existing Hello protocol simply by having
large packets fail to get through any hidden restrictions in the
network.

Whether you want to call that "discovery" or "verification," I don't
quite see how it matters.

---

From: James Carlson <[email-masked]>
Date: Fri, 3 Apr 2009 13:22:24 -0400

Don Fedyk writes:
> self electing themselves the DRB.

The padding leads to non-discovery, and non-discovery leads to
forwarding loops.

I believe that what you're suggesting is that there's a different
place to break this chain.  What I don't see is where that place would
be.  If it's not in eliminating the padding, then where is it?

Are you suggesting that nodes that see no other devices on the network
should not become DRB on their own?  If so, then what forwards on and
off of stub networks?

>   Whether or not you use IS-IS hellos
> protocol results in this undesirable behavior.

Correct.  This is just one way to cause the problem.

>  Yes IS-IS with padding

I'm unsure what you're suggesting as an alternative.  Could you clarify?

---

From: "Eric Gray" <[email-masked]>
Date: Fri, 3 Apr 2009 13:28:30 -0500

James,

	So, that being the case, I have to disagree with you.  Also,
I strongly suspect you'll find a large number of other people will 
as well.

	The problem you saw was simply the result of faulty network
equipment.  You can argue about my use of the term "faulty" in this
case, but - in my lexicon - any device that purports to be an
Ethernet device is required to support forwarding of a frames of a
certain size and any such device that does not do so is faulty.

	But set that aside for a minute.  It's clear that - faulty or
not - it creates a very serious problem if there is a mismatch of
configured and real MTU sizes.  But there are really good reasons
why IS-IS does what it does.  Hence there are reasons to avoid 
changing how IS-IS operates arbitrarily.  If you want to change IS-IS
in some critical ways, you're better off choosing another protocol.

	In this case, provided you meet the conditions I stated, then
it is absolutely okay to pad IS-IS messages just as is being done in
IS-IS today.  Now, before you reply, re-read what I said previously
(of course, those conditions appear to have been omitted below, so I 
am reinserting them here):

> used for MTU discovery - MTU discovery/determination should occur 
> BEFORE the DRB (and/or designated forwarder) determination process 
> begins (and certainly before forwarding begins), and would be 
> repeated periodically after this is done.

	If you read this carefully, what I am saying is that - if it's
possible for a pair of RBridge peers to know exactly what the real
MTU size is between them - then padding of IS-IS hello messages is 
okay.  In fact, it's more than okay because - implicit in what I said 
- particularly in the context in which I said it (a reply to Mike 
Shand in which I am trying to state an ideal solution given all of 
the preceding discussion), padding is actually preferred.

	What you're doing is conflating the MTU discovery process and
the use of IS-IS hello messages.  There are other mechanisms that
can be used and - since this is a general problem that applies to L2
network generally - it is likely that people already have solutions 
of this type in play.

	Where ANY other solution may already exist, your proposal to
modify IS-IS is unnacceptable.  A far cleaner approach is to simply
state something along the lines of "unless a mechanism is in place
to ascertain that a padded IS-IS hello message will be delivered to
all connected RBridges, IS-IS hello padding is disabled."  If you
want to propose modifying an IS-IS hello message in some way, as a
means for doing this, that's fine - but do it on your own nickle.

	I don't think we need it, and - unless it does more than a 
simple "yes/no" verification of a configured MTU size - I don't 
think it's particularly useful.

--
Eric

---

From: Radia Perlman <[email-masked]>
Date: Fri, 03 Apr 2009 12:56:33 -0700

This thread is getting too long.
Let's not take forever arguing about philosophical things like whether 
by making a change in IS-IS
such as saying that padding Hellos in TRILL IS-IS is a MUST NOT, that 
it's now
a totally different protocol. There will be differences between TRILL 
IS-IS and layer 3 IS-IS. It's nice
to do as much as possible to make it easy for a layer 3 IS-IS 
implementation to be modified to become
TRILL IS-IS, but we have to come up with a simple, practical plan for
how to make TRILL work.

1) As multiple people have pointed out, it's safe for IS-IS to pad 
Hellos. It is *not* safe for TRILL to pad Hellos.
(see movie Marathon Man, or Hitchhiker's Guide, for discussion
of "safe"). If there are both padded and unpadded Hellos, they serve 
different purposes (testing
MTU size in one case, and finding neighbor RBridges in the other case). 
I think it's cleaner to
call the messages solving the different purposes "different messages", 
and design each for the purpose
it is solving.

2) MTU discovery is also important, but the most important thing is for 
RBridges on the same layer 2 cloud NOT
to be hidden from each other due to things like VLAN configurations, or 
MTU differences. I think we can and should
solve both problems, but it would be OK with me if the MTU discovery 
protocol was SHOULD rather than MUST.
(Though I think I prefer MUST). If, as Eric Gray pointed out, there is 
already a rock-solid protocol defined
in layer 2 for determining MTU size on Ethernet links, and therefore
we (TRILL) don't need to solve this problem, then that would be great. 
So if there is,
can someone explain to the mailing list exactly how that protocol works?

We need a complete protocol. As James Carlson discovered, the spec as it 
is has to change, so that we are defensive
against differing MTU sizes, or intermediate components adding tags.

So, let me see if I can reiterate all the details in one place, since 
when I do it from memory in a hurry, I tend to miss
some little detail.

a) TRILL Hellos MUST NOT be padded. They also MUST NOT be bigger than 
some size. We should pick a
conservative maximum size for a Hello, so that it is guaranteed not to 
be dropped because of being too big,
even with extra tags that might be added by intermediate components. So 
perhaps 1400 bytes? (feel free
to suggest a different number). The purpose of the Hello is to ensure 
that neighbors see each other. It does
not test for MTU size.

b) The Hello contains a flag "I support the MTU discovery protocol".

c) The LSP contains an optional TLV "I think the campus-wide MTU size is x".

d) This MTU-size TLV is ignored in all LSPs except the LSP of the 
highest priority RBridge, R1, in the campus.
If R1 does not include this MTU-size TLV in its LSP, then each RBridge 
R2 decides for itself what the MTU size should
be, and does not report links to an RBridge neighbor R3, if the R2-R3 
link cannot support R2's assumption of MTU.
If R1 *does* include the MTU-size TLV, then R2 uses that size for a 
criteria for reporting links. Note that
if R2 cannot support R1's MTU size, then R2 will continue attempting to 
be DRB, etc., but will not report any
of its links in LSPs.

e) We define an "MTU discovery probe" packet, which is padded to some 
size, say s, and included inside the data
is the "s". These can be unicast to a neighbor, or multicast to the 
all-RBridges layer 2 address.

f) If R2 receives an MTU discovery packet from R3, R2 replies to R3 with 
an "MTU ack", including "s".

g) If R2 does not get acks from R3 for its MTU discovery probes, (say, 
after sending 3 of them), then R2 does not
report R3 in its Hellos, R3 will not report connectivity to the 
pseudonode, and if it's a pt-to-pt link, neither R2 nor
R3 will report the R2-R3 link in their LSP. However, if R3 has not set 
the "I support the MTU discovery protocol",
then R2 MUST NOT drop the adjacency to R3 because of nonreceipt of acks 
to its MTU discovery probes.

Have I left anything out?

Radia

---

From: James Carlson <[email-masked]>
Date: Fri, 3 Apr 2009 15:24:26 -0400

> I strongly suspect you'll find a large number of other people will 

I'm not sure if you're referring to this list or some other list (or
just "people" in general).  If it's this list, I don't think that's
true, based on the feedback so far.

But it'd certainly be good to check for rough consensus here before
going forward.

> certain size and any such device that does not do so is faulty.

I understand what you're saying, but whether the equipment is "faulty"
or not seems immaterial to me.  The issue here is about protection
against these known failure modes, and not trying to rule existing
equipment out as not just "bad" but "will melt your network."

In this particular case, the fault is fairly insidious.  Users likely
don't know that they have the problem *UNTIL* they try to deploy
RBridges, and the extra overhead required now becomes an issue.  From
a user's (deployer's) point of view, the network worked fine until he
tried to add an RBridge: thus, the RBridge is a bad thing, and he
won't want to repeat the experience.

It can be pretty hard to tell users that their existing equipment,
which appears to work just fine today, fails some technical purity
test and thus will cause actual failures when new nodes are deployed.

> why IS-IS does what it does.

The "really good reason" that I know about is because of bogus
FDDI/Ethernet bridges deployed long ago.  If you were FDDI-attached at
both apparent ends, but had an Ethernet bridge in the middle, you
could have an invisible MTU restriction.  The padded Hello checks for
this cleanly.

Is there some other reason that you know about?  Is there some other
reason that we should not consider changing this one aspect of IS-IS
to suit our needs?  If so, please relate it to us.  I'd certainly like
to know about it.

>  Hence there are reasons to avoid 

I don't think what Radia has proposed here is in any way "arbitrary."
I don't see how that characterization of this change is fair.

It solves a specific problem.

> am reinserting them here):

And, in the interest of not bloating the reply, I'll snip them again.

Yes, of course, if you can somehow guarantee that the MTU is not
restricted in the L2 path, then padding is harmless.  That's perfectly
well understood.

It's the "somehow" part that's unclear.  It's unclear how you're
proposing that we should do that prior to the Hello exchange.

> the preceding discussion), padding is actually preferred.

OK, then, how?

How exactly do we get the peers to agree on MTU *before* exchanging
Hello messages?  What mechanism will do that?  How do we even find the
other peers?  (I asked that previously, but you've declined to
answer.)

Radia has suggested a mechanism that will solve this problem, and will
work.  If you're going to say that it's unacceptable, then I think
it's reasonable to ask for a hint of what the preferred alternative
might be.

> the use of IS-IS hello messages.

Can you explain what other possible purpose the padding might have?

>  There are other mechanisms that

I agree that it's a general L2 problem.  I disagree that it's likely
that others have other solutions.  If so, please clarify.

(Maybe you're thinking of LLDP.  We'd probably have to bring this up
as a separate thread if the alternative is to force reliance on LLDP
for MTU information.  I'm not even sure it works, as the solution
"assumes" that all of the nodes actually implement LLDP.)

> modify IS-IS is unnacceptable.

I disagree most vehemently with that.

First of all, it's worth noting that the proposal was Radia's.  I
happen to agree with it, so if you call it "your proposal," then
that's just flattery.  ;-}

More importantly, though, IS-IS is already highly modified in order to
operate with TRILL.  We have already:

  - Changed the MAC address in use.

  - Changed the Area Addresses.

  - Changed the supported NLPID operation.

  - Changed Hello operation to send special Hellos on different VLANs.

  - Added special bits to the Hello messages that trigger new actions
    in the recipients.  (AF conflict resolution)

That's among other interesting changes.  If it helps, we'll pick a new
name for this, and just call it the "TRILL signaling protocol."  The
fact that it happens to look a whole lot like IS-IS and reuses some of
its algorithms becomes merely an implementation detail.

>  A far cleaner approach is to simply

If you're able to determine that a padded Hello message will be
delivered to all connected RBridges, then I contend that there *IS NO*
reason to pad at all.  In other words, the solution you're proposing
still devolves down to just "MUST NOT pad Hello."

Also, I don't know what you mean by referring to my nickles.  You'll
need to clarify that.  We're talking about TRILL/RBridges here, not
Jim's toys.

---

From: "Don Fedyk" <[email-masked]>
Date: Fri, 3 Apr 2009 16:30:31 -0400

Hi James 

>Don Fedyk writes:
>
>> > With IS-IS as used for TRILL, the padding is toxic.  If
>> > I can't hear your Hello messages, then I'll assume that
>> > *I* am the DRB, and I'll begin forwarding for all the
>> > VLANs I know about.  If you can't hear me, you'll do the
>> > same.  And that potentially results in an L2 forwarding
>> > loop for all frames that are of a size less than the MTU
>> > restriction: a very *BAD* failure mode.  It's the exact
>> > opposite of the L3 routing scenario.
>> > 
>> It is not the padding that is toxic.  It is the use of a
>> discovery protocol where the failure/absense of the
>> protocol results in RBridges self electing themselves the
>> DRB.
>
>The padding leads to non-discovery, and non-discovery leads
>to forwarding loops.
>
>I believe that what you're suggesting is that there's a
>different place to break this chain.  What I don't see is
>where that place would be.  If it's not in eliminating the
>padding, then where is it?
>
>Are you suggesting that nodes that see no other devices on
>the network should not become DRB on their own?  If so, then
>what forwards on and off of stub networks?

I'm suggesting that is the crux of the issue. 

>
>>   Whether or not you use IS-IS hellos to discover or some
>>   new fangled protocol, any failure of the discovery
>>  Yes IS-IS with padding may be a less robust discovery
>>  protocol but it was not designed for this purpose.   And
>>  repurposing the IS-IS design only reduses the problem it
>>  does not eliminate it. 
>

I already suggested the alternative: Interwork with STP (actually you
suggested it first).  You either make the RBridges smart enough to talk
STP or you do something where STP(RSTP) will block you.  STP won't form
loops if it is told the right information.  I'm sure it can be done. 

Don

---

From: "Eric Gray" <[email-masked]>
Date: Fri, 3 Apr 2009 15:30:45 -0500

I did a quick check on this thread.  It seems to be fairly split into
3 groups:

1) those who think some variation of what you propose is a good 
   enough solution.  Note that there is not a firm agreement as
   to which of the similar approaches would be adopted.
2) those who object to one or another of the specific proposals.
3) those who are still trying to understand the issues and what
   the implications are.

Some people are not clearly in one group or the other, so I would
count them twice.  I, for instance, would count myself in both
group 1 and group 2 because I agree with the basics of what Radia
has proposed, but don't agree with the way that you interpret it.

To be fair, I should probably count you in both the first group 
and in the third, because you apparently still have questions
(based on your reply below) - but that would probably be seen
as a specious argument, so I count you only in the first group.

Given the small number of participants, and the division that seems
to exist among them, I think it will be hard to call any particular 
consensus at this point.  Perhaps if the chairs explicitly ask, we
may find out otherwise.

Of course, a consensus call would need to carefully spell out what
exactly we are deciding - and there are more options than Radia 
includes in her mail.  Perhaps what we need to do is list all of 
the variations and throw as many off the island as we can before we
actually try to determine consensus on a way forward from the few
(hopefully) that will remain.

For example, maybe we could throw STP off of the island?

--
Eric

-----Original Message-----
From: James Carlson [mailto:[email-masked]] 
Sent: Friday, April 03, 2009 3:24 PM
To: Eric Gray
Cc: mike shand; TRILL/RBridge Working Group; Radia Perlman
Subject: RE: [rbridge] Proposed compromise for short/long hellos
Importance: High

OK, then, how?

---

From: James Carlson <[email-masked]>
Date: Fri, 3 Apr 2009 16:45:39 -0400

> 3) those who are still trying to understand the issues and what
[...]
> as a specious argument, so I count you only in the first group.

Wow.  That ends the thread for me.

For purposes of consensus, everyone else can count me as a supporter
of Radia's existing proposal.

---

From: Jim Burrows <[email-masked]>
Date: Fri, 3 Apr 2009 17:22:16 -0400

On Apr 3, 2009, at 3:56 PM, Radia Perlman wrote:

> This thread is getting too long....
> So, let me see if I can reiterate all the details in one place,  
> since when I do it from memory in a hurry, I tend to miss some  
> little detail....

Bless you!

> Have I left anything out?

I don't think so. While a bit long, your message summarized what I  
believe I have been reading here as concisely and completely as  
possible. I will admit to being something of a newbie to both the list  
and TRILL, but given the few weeks of experience I have with it, I  
believe I understand the issues and your summary corresponds to that  
understanding very well.

I'm left slightly uncertain what the proper value for "s" is, and what  
criteria R1 (and its ilk) should have used in determining what it  
assert the campus MTU size is--should it be based solely on the MTU  
probing protocol or other mechanisms--but it is not clear to me that  
either of these *have* to be specified. If we can agree on your  
outlined points a-g, then these "implementation details" can probably  
be worked out.

The big "if", of course, getting consensus on a-g. I for one, haven't  
seen concrete reasons to disagree with your summary, beyond the more  
philosophical and unspecific notions that have floated around in prior  
emails.

Thank you,
JimB.

---

From: James Carlson <[email-masked]>
Date: Fri, 3 Apr 2009 16:42:06 -0400

> I'm suggesting that is the crux of the issue. 

OK.

> loops if it is told the right information.  I'm sure it can be done. 

The BPDUs at least have the benefit of not being MTU-padded by
default.  ;-}

This is the path we went down on my initial message and then
abandoned.  It ultimately forces you to run a giant STP instance over
the entire bridged network -- TRILL nodes included -- and the wg
consensus was that this would not be a good answer.

I think there are two possible behaviors that TRILL could have with
respect to STP, corresponding to having one protocol logically "on
top" of the other:

  1. TRILL nodes look like end stations to STP.  Regular bridges are
     invisible to TRILL; they just make it look like there's a
     multidrop link present.

  2. An entire TRILL cloud looks like a single STP-speaking bridge to
     the regular bridges attached anywhere in the network.  TRILL DRBs
     are responsible for running a fraction of STP and somehow
     coordinating with other DRBs.

We've intentionally chosen (1), and I think you're suggesting we
switch to (2).

I think we'd need a solution for how you run STP in a cloud in order
to do that, plus a substantial change in the existing consensus.  (I
don't remember anyone else clamoring for having giant STP networks ...)

---

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

> when I do it from memory in a hurry, I tend to miss

I agree with this mostly, but I think there's a simplification

> b) The Hello contains a flag "I support the MTU discovery protocol".

If we make it so that RBridges MUST respond to the MTU probe, but only
MAY (or possibly SHOULD) send probes of their own, then the need for
this extra flag goes away.

This allows us to satisfy the folks who don't believe that MTU checks
are necessary (they're free to avoid sending probes if they want),
while allowing those who want to check for MTU flaws to do so whenever
needed.

> highest priority RBridge, R1, in the campus.

I've been thinking about this part of a while.  I don't know whether
choosing the highest priority RBridge to set the MTU value is right,
but I can't actually think of a cleaner answer.

In general, you might have some links with a higher possible MTU
(going to waste, I suppose), and ones with a lower MTU (being rendered
unusable).

We could choose the smallest value (rather than the value from the
highest priority RBridge), to make sure that all links are always
included, but then adding a new RBridge to a campus becomes a more
risky proposition.

---

From: Dinesh G Dutt <[email-masked]>
Date: Fri, 03 Apr 2009 14:57:04 -0700

Agreed,

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

---

From: "Don Fedyk" <[email-masked]>
Date: Fri, 3 Apr 2009 17:38:48 -0400

Hi James 

> Sent: Friday, April 03, 2009 4:42 PM
> To: Fedyk, Don (BL60:1A00)
> Cc: Eric Gray; TRILL/RBridge Working Group; Radia Perlman

Not exactly I'm suggesting you make the RBridge attachment such that the
LAN running STP decides two or more RBridges cannot be tolerated. STP
will block the ports until you can fix things.  Rather than running STP
in a cloud you run enough of an STP stub locally on your RBridge to
break loops in the rare event your discovery protocol fails. Remember
your only counting on STP iff the discovery protocol breaks. And then
IS-IS can be your discovery protocol. 

Don

---

From: James Carlson <[email-masked]>
Date: Fri, 3 Apr 2009 17:48:42 -0400

> IS-IS can be your discovery protocol. 

I'm unaware of a good way to do that.  I know how to make links in the
middle of the STP topology snap apart unpredictably (reporting the
same root bridge from each RBridge ought to be enough), but I don't
offhand know how to cause STP to break off the attachment right at the
"duplicate" node.

If you've got a concrete suggestion on how to do that, I'd be
interested.  (I still doubt we can get consensus on going that way,
particularly because it'd hard to keep it from interfering with the AF
delegation behavior, but it'd be interesting nonetheless.)

---

From: "Don Fedyk" <[email-masked]>
Date: Sat, 4 Apr 2009 07:43:10 -0400

Hi James

>Don Fedyk writes:
>
>> >   2. An entire TRILL cloud looks like a single
>> >   STP-speaking bridge to the regular bridges attached
>> >   anywhere in the network.  TRILL DRBs are responsible
>> >   for running a fraction of STP and somehow coordinating
>> >   with other DRBs.
>> > 
>> > We've intentionally chosen (1), and I think you're
>> > suggesting we switch to (2).
>> 
>> Not exactly I'm suggesting you make the RBridge attachment
>> such that the LAN running STP decides two or more RBridges
>> cannot be tolerated. STP will block the ports until you
>> can fix things.  Rather than running STP in a cloud you
>> run enough of an STP stub locally on your RBridge to break
>> loops in the rare event your discovery protocol fails.
>> Remember your only counting on STP iff the discovery
>> protocol breaks. And then IS-IS can be your discovery
>> protocol. 
>
>I'm unaware of a good way to do that.  I know how to make
>links in the middle of the STP topology snap apart
>unpredictably (reporting the same root bridge from each
>RBridge ought to be enough), but I don't offhand know how to
>cause STP to break off the attachment right at the
>"duplicate" node.
>
>If you've got a concrete suggestion on how to do that, I'd
>be interested.  (I still doubt we can get consensus on going
>that way, particularly because it'd hard to keep it from
>interfering with the AF delegation behavior, but it'd be
>interesting nonetheless.)
>

What if every RBridge reported it was connected to a well known low
priority "pseudo" bridge.  If ever two RBridges were connected to the
same LAN and tried to do this STP would require one of the RBridge break
the connection to the "pseudo node".  The RBridges would know implicitly
there were two RBridges connect to the LAN and one of then would go into
listen mostly mode (by removing the low priority pseudo node from the
BPDUs).  The RBridge could still send locally to this LAN sending Hellos
etc but it would not bridge to the LAN. (It would see the pseudo bridge
already in the LAN.)  It seems to me this would be a condition before
you became an appointed forwarder.  Unfortunately I'm not an STP expert
to say defacto this would work but it seems you want to inject some
harmless information using STP that would allow RBridges to detect
RBridges. You still have the issue that the condition to become
appointed forwarder or DRB is dependent on you not hearing something. 

Regards,
Don

---

From: "Eric Gray" <[email-masked]>
Date: Sat, 4 Apr 2009 10:19:21 -0500

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Radia Perlman
Sent: Friday, April 03, 2009 3:57 PM
To: TRILL/RBridge Working Group
Subject: Re: [rbridge] Proposed compromise for short/long hellos

---[SNIP]---

If, as Eric Gray pointed out, there is already a rock-solid protocol 
defined in layer 2 for determining MTU size on Ethernet links, ...

EG> I never said this. What I said was that there are mechanisms which
EG> have been, or are being, defined in IEEE 802 (.1 Interworking in 
EG> particular) that can be used to solve this problem.  Since this is
EG> a problem specific to L2 technologies, and has broader applicability
EG> then TRILL, this problem may be solved in a larger context.  If it
EG> solved, then any TRILL specific solution will likely become
obsolete.

... and therefore we (TRILL) don't need to solve this problem, then that

would be great.  

EG> Never said that either.  What I said is that we should not - in the 
EG> Base protocol specification - describe an MTU discovery protocol.
EG> I am amenable to proposing what you have been suggesting as a proof
EG> of concept example (in the base protocol specification) that such a 
EG> protocol can be defined, but I do not find this proposal to be very
EG> useful (as I have said) because it is basically a pass-fail MTU
EG> validation (nothing particularly "discovery" about it), and I do 
EG> not believe this will be the long-term approach for a number of
EG> reasons.

So if there is, can someone explain to the mailing list exactly how that

protocol works?

EG> You ask quite a lot.  I participate in several of the activities in
EG> IEEE 802.1, and there are a few that have some impact on this issue.
EG> 
EG> As the IETF liaison to IEEE 802.1, I occasionally produce meeting
EG> summaries of work (I know of) in IEEE that is related to (what I 
EG> know of) work in the IETF.  As far as I know, nobody expects me to 
EG> produce summaries of the actual specifications (and that's a good
EG> thing, as it would be impossible for me to do so).
EG>
EG> At a high level, however, there are a number of specifications that
EG> may impact on this issue - and particularly - on the applicablility
EG> of (or need for) a TRILL-defined MTU discovery mechanism.
EG> 
EG> For instance, there is Connectivity Fault Management (CFM - and 
EG> particularly Data-Driven CFM, or DDCFM) which can be used to find
EG> an exact MTU size between any two bridges.
EG> 
EG> Although it is to be presumed that operators would want to configure
EG> security parameters correctly, a quick look at the security work in
EG> IEEE indicates that it may be possible to mis-configure security in
EG> such a way that one RBridge does not discover another (for instance,
EG> by being rejected as invalid by a lower layer entity). I imagine we
EG> really need someone from the IEEE Security task group to let us know

EG> if that is an issue.  If it is, are we going to attempt to fix this
EG> in TRILL as well?
EG>
EG> Then there is Logical Link Discovery Protocol (LLDP - P802.1AB) that
EG> has been around a while and may have some impact on whether or not
EG> an (additional) MTU discovery mechanism is required.
EG> 
EG> Spanning tree itself can be used to determine if there intermediate 
EG> bridges (where insertion of additional TAGs may occur).
EG>
EG> And these do not include the possibility of new work, potentially
EG> inspired by this discussion and potentially inspired by others.  
EG> The relevant point is that we should not specify a _required_ MTU 
EG> discovery protocol as part of the base protocol specification in
EG> TRILL.
EG> 
EG> All of this is essentially part of what the TRILL WG should be 
EG> considering in reference to the IEEE liaison response that Donald
EG> mentioned at the last meeting - i.e. - in particular, references 
EG> to the need to be clear about the scope of TRILL and the potential
EG> for TRILL to have future conflicts with the work in IEEE 802.1.

is has to change, so that we are defensive against differing MTU sizes, 
or intermediate components adding tags.

EG> The presence of intermediate components may be a detectable phenom.
EG> If it is, and there are none, is MTU discovery required?  Are hello
EG> messages allowed to be padded in this case?

So, let me see if I can reiterate all the details in one place, since 
when I do it from memory in a hurry, I tend to miss some little detail.

a) TRILL Hellos MUST NOT be padded. They also MUST NOT be bigger than 
   some size. We should pick a conservative maximum size for a Hello,
   so that it is guaranteed not to be dropped because of being too big,
   even with extra tags that might be added by intermediate components.
   So perhaps 1400 bytes? 

EG> The problems I see with this approach is several:
EG> A) any number greater than the smallest MTU size we will ever
EG>    find will need to be configurable to a lower number.  And,
EG>    given that we didn't want to do that for the initial case,
EG>    it seems likely that we're saying we won't want to do it 
EG>    then either.  Clearly we cannot know the smallest size we
EG>    will ever see.
EG> B) If we pick a number today, and find out that it is too big
EG>    for some implementation/deployment, will we then change the
EG>    protocol solution to use this lower value as the new MAX?
EG> C) what do you do when the hello messages must be larger than
EG>    whatever we've decided will be the maximum - even when that
EG>    maximum clearly doesn't apply in some particular deployment
EG>    scenario? 
EG> D) Does this apply when two adjacent RBrdiges are connected by
EG>    a point to point link and this link is configured not to 
EG>    require a DRB?
EG> E> Would this apply for an RBridge that is not capable of being 
EG>    a DRB?

(feel free to suggest a different number). The purpose of the Hello is 
to ensure that neighbors see each other. It does not test for MTU size.

EG> I suggest "... the TRILL MTU discovery protocol ..." simply as a
EG> clarification, because there are others.  You might argue that it
EG> should be understood because it is a flag in a TRILL protocol PDU,
EG> but the simple truth is that customers are going to call it what
EG> ever we call it and I'd like to avoid injecting more confuion into
EG> the situation.

c) The LSP contains an optional TLV "I think the campus-wide MTU size 
   is x".

d) This MTU-size TLV is ignored in all LSPs except the LSP of the 
   highest priority RBridge, R1, in the campus.  If R1 does not 
   include this MTU-size TLV in its LSP, then each RBridge R2
   decides for itself what the MTU size should be, and does not 
   report links to an RBridge neighbor R3, if the R2-R3 link 
   cannot support R2's assumption of MTU.  If R1 *does* include 
   the MTU-size TLV, then R2 uses that size for a criteria for 
   reporting links. Note that if R2 cannot support R1's MTU size, 
   then R2 will continue attempting to be DRB, etc., but will not
   report any of its links in LSPs.

EG> I am not sure I understand this at all, given that it seems 
EG> like you're using campus to mean "shared link", since the 
EG> RBridge R2 appears to need to support at least as great an
EG> MTU as the highest priority RBridge - even though they may 
EG> may not be attached to a shared link (and would not therefore
EG> be competing DRB candidates), or you are assuming it will not
EG> become the DRB for the shared link.
EG> 
EG> If that is indeed what you mean, then what happens if there 
EG> are no RBridges connected to the same shared link as R2 that
EG> are capable of supporting the MTU asserted by the highest
EG> priority RBridge?
EG> 
EG> Also, I think you are forgetting at least one thing.  The  
EG> highest priority  RBridge would need to change the MTU it 
EG> asserts to the value determined as the minimum of all MTU 
EG> size assertions if the intent is to make sure that all 
EG> RBridges can handle a frame of that size.
EG>
EG> And, instead of determining the campus-wide MTU, the MTU 
EG> assertions could be scoped by VLAN - avoiding the scenario
EG> in which every link is treated as if it has the worst case 
EG> MTU, even if none of the taffic that traverses that link 
EG> will ever traverse the link(s) that require this worst case
EG> MTU.

e) We define an "MTU discovery probe" packet, which is padded to some 
   size, say s, and included inside the data is the "s". These can be
   unicast to a neighbor, or multicast to the all-RBridges layer 2 
   address.

g) If R2 does not get acks from R3 for its MTU discovery probes, (say, 
   after sending 3 of them), then R2 does not report R3 in its Hellos,
   R3 will not report connectivity to the pseudonode, and if it's a 
   pt-to-pt link, neither R2 nor R3 will report the R2-R3 link in their
   LSP. However, if R3 has not set the "I support the MTU discovery 
   protocol", then R2 MUST NOT drop the adjacency to R3 because of
   nonreceipt of acks to its MTU discovery probes.

EG> Alternatively, R2 could decide to reduce the size of subsequent
EG> discovery probes, until it does receive an ACK.

Radia

---

From: Radia Perlman <[email-masked]>
Date: Sat, 04 Apr 2009 15:52:59 -0700

Hi Don,

You're basically suggesting something that was in the spec in an earlier 
version, and that I liked, but it got shot down.
The rule was that RBridges would participate in the STP on each link, 
with priority configured so that RBridges would
have priority over regular bridges for becoming spanning tree root. And 
then an RBridge would become DRB if and only
if it was elected root in the STP.

As I said, I liked this approach, but it got shot down, I'm not sure I 
remember all the reasons, but I think it had to
do with "which version of the spanning tree would RBridges have to 
run?", and "what if bridges are also configured to
have highest priority"?

But given that it was discussed in the WG, and given that for whatever 
reason it was overruled, we shouldn't try to
go back to that. There were a bunch of things I wish had gone a 
different way, like the clever TRILL header encoding
that Don (I think) proposed where the VLAN and DA were brought into the 
TRILL header. But we'll never finish
this if we keep regretting decisions we made.

Radia

---

From: "Eric Gray" <[email-masked]>
Date: Sat, 4 Apr 2009 19:16:16 -0500

Radia,

	This is an interesting argument.  For many reasons, some of
which we 
don't remember, an earlier proposal similar to Don's was thrown out. So
we 
shouldn't go back to that proposal - or consider a similar one - because

we will only discover again what the reasons were for shooting the
similar 
proposal down earlier.

	A highly analogous situation exists with the IS-IS padding of
hello
messages.  You won't find anyone to bet against if you want to bet that
a
suggestion was made once or twice in specifying IS-IS to do away with
the
padding of hello messages.  But it was shot down, apparently, because
it's
still there.

	I suspect the reason why using STP in the manner you suggest was
shot
down was in part because people said their customers didn't want to hear

the word "STP" being talked about in connection with their network.

	But it really doesn't matter - in the final analysis - why an
earlier
proposal was shot down, if the proposal that was accepted in its place
was
thereafter the basis for all subsequent work.  We've moved on quite a
bit 
since we made the decision not to use STP in precisely the way that you 
suggest, and that decision is now ingrained in most of the work we've
done 
since.

	Unfortunately, I am concerned that people may have lost sight of
the
fact that this same reasoning may very well apply to revisiting the
early
decision in IS-IS to pad hello messages.

	In one sense, I definitely feel that Don is onto something.
Perhaps
there needs to be an RBridge discovery protocol that is BPDU-based, even
if it is not STP.  Nothing else would have to change - either in TRILL,
or
in IS-IS - though the use of the discovery aspect of IS-IS is bound to
be
a bit anti-climactic (but this is already true if we've had to configure
a
lot of information about neighbors anyway).

	This approach would eliminate any concerns about not discovering
an
adjacent Rbridge, and it would decouple the content of IS-IS Hello
messages
from concerns about MTU size.  RBridges would already know who they
should
be seeing IS-IS Hello messages from and could take appropriate actions
if 
they don't see them. 

--
Eric

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Radia Perlman
Sent: Saturday, April 04, 2009 6:53 PM
To: Don Fedyk
Cc: TRILL/RBridge Working Group
Subject: Re: [rbridge] Proposed compromise for short/long hellos

Hi Don,

Radia

---

From: Kris Price <[email-masked]>
Date: Sun, 05 Apr 2009 17:00:23 +1200

Eric Gray wrote:
[snip]
> be seeing IS-IS Hello messages from and could take appropriate actions
[snip]

I thought this approach was more ideal (if the TRILL cloud acting as a 
bridge approach wasn't a goer) as it meant no modification to IS-IS. I 
assumed an entirely new discovery protocol, becuase I couldn't quickly 
think up a nice way to use BPDUs/STP, but if that is possible I'd quite 
like to hear thoughts on how it'd be done (just to satiate my curiosity 
on the subject).

If you have a new protocol, and you discover other RBridges are on the 
link via this new protocol, you can either not transmit or recieve from 
the link if there is a discrepency between IS-IS and this new protocol. 
Otherwise you still need to elect the DRB somehow, and handle VLANs, so 
the discovery protocol needs to incorporate that behavior... then it 
starts looking like the current behaviour that's been designed into IS-IS...

And if you follow that path maybe eventually maybe you've just created 
an all new TRILL specific Hello protocol... and perhaps remove some of 
the TRILL additions from IS-IS... or you say the opposite, and why have 
a separate protocl when a modified IS-IS will do.

In the end, I am mostly uncomfortable with this arbitrary maximum hello 
size (1400 bytes?) at which above things are ok, or below which the 
result may be bad. When picking that maximum I expected it needed to be 
something much smaller, like <600 bytes... to make sure they always gets 
through... or maybe needs to be the same as what STP would cope with, or 
something less arbitrary.

Probably speaking before properly engaging brain:

I still don't *feel* there is enough value in adapting to different MTU 
sizes though to warrant it, it may be "we can, so why not?" to many, but 
I just have this automatic dislike for finding features in things that 
are rarely used but add complexity.

What is the reason for adapting to small MTUs? Because some customers 
don't want to be told that they can't use this strange configuration? 
Who are these people? In the first 5 years will the people deploying 
TRILL be the ones with these environments? Or more realistically those 
with money that can afford to overcome such problems (which are problems 
in most networks anyway when the MTU <1500) when they deploy TRILL? And 
when TRILL trickles down to the kinds of people who can't, will they 
really still have this problem at that point in the future?

If it doesn't adapt automatically, what is going to be the default MTU?

I can think of some networks I know that would have this MTU problem, 
but only because of poor planning, and those people shouldn't be running 
TRILL anyway, they should be (and are) routing IP.

Of course, it presumably came up for a reason. The safety aspect of the 
Hellos is clearly very important, too risky to ignore, but I (in my 
limited/humble experience) don't buy the MTU adaptation part so much.

But alright, some people have MTU cripled links, want to run TRILL over 
them, and will be offended if told to upgrade. In summary:

1. If MTU adaptation for LSPs etc. is something IS-IS needs to do, 
wouldn't it be better to design it as a proposed enhancement to IS-IS, 
because surely it has non-TRILL uses in that case too...doesn't it? And 
surely it also goes both ways, increasing as well as decreasing the MTU 
size?

2. If not a separate protocol, of course shorten Hellos for safety, but 
if a link doesn't support the IS-IS MTU, I would've thought leave it at 
that. The IS-IS MTU size stays for all LSPs/etc. and it's only Hellos 
that are modified...

3. If there are really customers that want to run TRILL over small links 
  and the minimum supported size settled on the WG is something quite 
large like 1400, then why not just adopt it as the new one size fits all 
standard for TRILL's version of IS-IS. It would be just like IS-IS, but 
with one field in the spec changed from 1492 to 1400.

[/ignorable humble opinion]

---

From: "Don Fedyk" <[email-masked]>
Date: Sun, 5 Apr 2009 09:14:54 -0400

Hi Radia 

OK I hear what you are saying but there is also some subtle conclusions
I can draw. 

On the Problems to solve list/ Desires list (not sorted): 

1) Trill Discovery Protocol Robustness
2) Padded IS-IS Hellos take too much bandwidth
3) Staying clear of legacy STP etc
4) IS-IS Adjacency robustness

On the solutions on the table/discussed about: 

a) IS-IS short/long Hellos 
b) Smaller IS-IS MTU (ReceiveLSPBufferSize reduced from 1492 or
whatever)
c) Solving the discovery with STP on RBridge

>From the direction of the solutions mapped to the set of problems if you
told me that 2) was your most important problem and 1) was secondary I'd
understand where the direction is headed on a). (maybe everybody knew
this but me). 

Also a) addresses 2) primarily. A simple solution is b) for 1) but does
zero for 2).  And the implementation of a) must be correct to ensure no
impacts on 4). 

For the record 3) limits the ability to better address 1) with c) but c)
admittedly has additional burden and does not address 2) other than the
fact that the frequency of Hellos could drop if c) was implemented. 

So I would buy that a) primarily addresses 2) and improves 1)(when MTU
is a factor) and that may be all the WG is willing to do,

Regards,
Don 

> From: Radia Perlman [mailto:[email-masked]]

---

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

Don: (just a nit on your
email) The problem with large hellos isn't wasted bandwidth...it's that 
they might not actually get received. Which causes loops with TRILL
even though (as we pointed out in earlier messages) it might cause weird 
stuff with layer 3, but nothing fatal.

Kris: "no modification to IS-IS" is not an issue. TRILL requires 
modifications to IS-IS. Not padding Hellos, and separating
RBridge neighbor discovery from MTU discovery is no more of a change 
than any of the other things we've needed to do.
It's always good to see if a change is gratuitous or necessary. In this 
case it is necessary.

Eric: Yes we definitely should come up with a new name. I never liked 
"MTU". It's almost as baffling even when it is
expanded.  And "MTU discovery protocol", as you pointed out, is already 
taken, so perhaps we could call it
"link size test protocol" or something.

Jim: If we make ability to handle link size test protocol probes 
mandatory, we have to define *now*, the format of a probe.
Which shouldn't be hard, I'd assume. Perhaps a variant of a Hello 
message, so that we don't have to use a new packet type?
All that needs to be in it is the size being tested, "s", and whether it 
is a probe or an ack. The probe would be
padded to size s. The ack would not, but it would include "s", the size 
in the probe packet being ack'ed.

This shouldn't be a big deal, let's try to agree quickly.

So, to reiterate the design, this time making handling of a probe 
mandatory and part of the spec:

a) TRILL Hellos MUST NOT be padded. They also MUST NOT be bigger than 
some size. Let's pick
1400 bytes, because that really is big enough to handle all reasonable sized Hellos.
The only thing that could make it bigger is very weird assignments of Designated Forwarders,
and the 1400 byte limit would just limit the DRB's creativity in handing out forwarding
assignments.

b) The LSP contains an optional TLV "I think the campus-wide MTU size is x".

c) This MTU-size TLV is ignored in all LSPs except the LSP of the 

d) We define a "link size probe" packet, which is padded to some 
size, say s, and included inside the data
is the "s". These can be unicast to a neighbor, or multicast to the 
all-RBridges layer 2 address. Likewise there is a "link size probe ack", which
contains "s", the size stated inside the probe packet being ack'd. The ack would
be unicast to the sender of the probe. I'd recommend some variant on a Hello
packet, just so we don't need a new packet type. But as I've said before,
I tend to be overly disinterested in encoding.

e) If R2 does not get acks from R3 for its link size probes, (say, 
after sending 3 of them), then R2 does not
report R3 in its Hellos, R3 will not report connectivity to the 
pseudonode, and if it's a pt-to-pt link, neither R2 nor
R3 will report the R2-R3 link in their LSP.

---

From: "Eric Gray" <[email-masked]>
Date: Mon, 6 Apr 2009 11:26:03 -0500

Radia,

	Re-iterating my prior question, what does "c)" mean?

	I think an important piece is still missing.  If I try
to analyze "c)" a piece at a time, this is what I get:

1) RBridges throughout the campus are looking to be told what the
   common MTU is by the highest priority RBridge (apparently for 
   the entire campus) in an MTU size TLV.
2) I assume you're intent is to make support for this mandatory
   (based on your comment to Jim) and - if that is so - the highest
   priority RBridge would (presumably) necessarily have this TLV.
   If this is correct, why include the (confusing/ambiguous) text
   about what the rest of the campus-wide RBridges would do if the
   highest priority RBridge does not include it.
3) Any RBridge that does not support this MTU size can contend to
   be DRB but cannot advertise any of its links in RBridge IS-IS.
   If that RBridge cannot advertise its links, what would be the
   effect of its being elected DRB for some set of end-stations,
   if it is not allowed to advertise associated links? If there 
   are no RBridges associated with any set of end-stations that 
   support the MTU advertised by the highest-priority bridge, 
   then how will those end-stations be attached to the campus?

I suspect the missing piece is how the highest priority RBridge
determines what MTU to assert.  And - if we were going to adopt
this scheme - that would need to be deterministic as we probably
don't want to have an arbitrarily complex shuffling of RBridges
as a result of changing the higest priority RBridge.

--
Eric

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Radia Perlman
Sent: Sunday, April 05, 2009 3:08 PM
To: TRILL/RBridge Working Group
Subject: Re: [rbridge] Recap short long hello problem statement

Don: (just a nit on your

a) TRILL Hellos MUST NOT be padded. They also MUST NOT be bigger than 
some size. Let's pick
1400 bytes, because that really is big enough to handle all reasonable
sized Hellos.
The only thing that could make it bigger is very weird assignments of
Designated Forwarders,
and the 1400 byte limit would just limit the DRB's creativity in handing
out forwarding
assignments.

b) The LSP contains an optional TLV "I think the campus-wide MTU size is
x".

d) We define a "link size probe" packet, which is padded to some 
size, say s, and included inside the data
is the "s". These can be unicast to a neighbor, or multicast to the 
all-RBridges layer 2 address. Likewise there is a "link size probe ack",
which
contains "s", the size stated inside the probe packet being ack'd. The
ack would
be unicast to the sender of the probe. I'd recommend some variant on a
Hello
packet, just so we don't need a new packet type. But as I've said
before,
I tend to be overly disinterested in encoding.

---

From: Dinesh G Dutt <[email-masked]>
Date: Mon, 06 Apr 2009 10:48:55 -0700

The imperative problem to solve is to avoid two Rbridges from becoming 
DRBs on a single link and creating a loop. The optional problem, to me 
at least, is the MTU discovery.

 From this perspective, doing what Radia is suggesting i.e. not padding 
Hellos is what I support. If we chose to solve the MTU discovery 
problem, I'm not in favor of mandating every node to support it.

On the separate problem of setting a campus-wide MTU for the sake of not 
sending LSP's larger than a lowest common denominator value, how does 
L3  IS-IS solve this ?

So from Radia's email, I like (a), (d)/(e) should be optional and I'm 
not sure about the use of (b) and (c).

Dinesh

---

From: "Eric Gray" <[email-masked]>
Date: Mon, 6 Apr 2009 13:53:39 -0500

Dinesh,

	The MTU (common, or least common) size problem is not solved by
routing at L3.  It is solved - for IP at least - by setting the "don't
fragment" bit at sending hsosts and handling the resulting ICMP error 
messages.

	If it was handled by routers, the routers would have to handle
IP fragmentation - which most router vendors would rather not do...

--
Eric

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Dinesh G Dutt
Sent: Monday, April 06, 2009 1:49 PM
To: Radia Perlman
Cc: TRILL/RBridge Working Group
Subject: Re: [rbridge] Recap short long hello problem statement

Dinesh
sized Hellos.
Designated Forwarders,

ack would
Hello
before,

---

From: Radia Perlman <[email-masked]>
Date: Mon, 06 Apr 2009 12:09:43 -0700

In that case -- if L3 IS-IS doesn't worry about network-wide MTU size, 
then it seems like we could probably
live with the extremely simple fix to TRILL of:

"Don't pad Hellos".

End of story.

I'd like that.

Radia

Eric Gray wrote:
>> email) The problem with large hellos isn't wasted bandwidth...it's
>>     
> that 
>   
>> even though (as we pointed out in earlier messages) it might cause
>>     
> weird 
>   
>> It's always good to see if a change is gratuitous or necessary. In
>>     
> this 
>   
>> case it is necessary.
>>
>> expanded.  And "MTU discovery protocol", as you pointed out, is
>>     
> already 
>   
>> All that needs to be in it is the size being tested, "s", and whether
>>     
> it 
>   
>> padded to size s. The ack would not, but it would include "s", the
>>     
> size 
>   
>> and the 1400 byte limit would just limit the DRB's creativity in
>>     
> handing out forwarding
>   
>> assignments.
>>
>> b) The LSP contains an optional TLV "I think the campus-wide MTU size
>>     
> is x".
>   
>> if R2 cannot support R1's MTU size, then R2 will continue attempting
>>     
> to 
>   
>> all-RBridges layer 2 address. Likewise there is a "link size probe
>>     
> ack", which
>

---

From: "Eric Gray" <[email-masked]>
Date: Mon, 6 Apr 2009 14:12:33 -0500

Dinesh,

	Aha.  Radia's proposal is for IS-IS control plane use only.
That's something I hadn't picked up on.

	Thanks!

--
Eric 

-----Original Message-----
From: Dinesh G Dutt [mailto:[email-masked]] 
Sent: Monday, April 06, 2009 3:08 PM
To: Eric Gray
Cc: Radia Perlman; TRILL/RBridge Working Group
Subject: Re: [rbridge] Recap short long hello problem statement
Importance: High

My question was related to not breaking down LSP fragments sent by 
Rbridges who have a larger-than-thou MTU. I was told that in IS-IS, 
LSP's of other Rbridges cannot be chopped up into smaller pieces for 
transmission on lower sized MTU links. Therefore, Radia was proposing 
the campus-wide MTU TLV.

Dinesh

---

From: Dinesh G Dutt <[email-masked]>
Date: Mon, 06 Apr 2009 12:08:27 -0700

Dinesh

---

From: James Carlson <[email-masked]>
Date: Mon, 6 Apr 2009 15:14:31 -0400

> problem, I'm not in favor of mandating every node to support it.

It depends on what you mean by "support."

If you mean forcing every implementation to send probe messages and
actively look for restricted MTUs between peer RBridges, then I
completely agree.  That shouldn't be mandatory.  Not everyone agrees
that it's necessary in all implementations.

If you mean just responding appropriately to the probe message, then I
disagree.  That response mechanism needs to be mandatory for two
reasons:

  1. Making it optional makes it effectively impossible for others to
     build interoperable implementations that *do* implement the
     feature, because they have to live with the risk of paths that
     won't respond and won't detect MTU problems.

  2. Making it optional also adds more complexity: those nodes that do
     implement it will need a way to find out whether the
     non-responding peers are failing to respond because the MTU is
     restricted or because they're just ornery.  That forces the
     addition of the extra bit in Hello as Radia originally suggested.

I suggest keeping it simple: response is trivial to do, represents no
burden on those that otherwise lack the feature, and is thus required.
Actively sending probes is not simple, but is not required.

> sending LSP's larger than a lowest common denominator value, how does 

Agreed; that really shouldn't be addressed in this thread, because it
is a completely separate matter.  (But part of the answer is that most
L3s can deal with separate subnetworks with differing MTUs.  We don't
have that luxury because we're forwarding at L2.)

---

From: "Sina Mirtorabi (smirtora)" <[email-masked]>
Date: Mon, 6 Apr 2009 15:09:43 -0700

Radia,

Let's assume, we know that for a given minimum MTU size ( Smin = 1500-X
) all the stupid old devices could handle correctly the packet and
whatever overhead that is added to the packet would still not make its
size more than 1500 byte. Now if we agree on Smin then most of the below
proposal is unnecessary apart from NOT padding Hello (although that
could be included as well but just for safety)

Note that ISIS spec (ISO 10589:2002) define the following parameters

ReceiveLSPBufferSize set to 1492 (by default)
originatingLSPBufferSize included in a TLV when generating LSP

The assumption is that 

originatingLSPBufferSize <= ReceiveLSPBufferSize 
&
originatingLSPBufferSize <= MTU for all links 

For Trill if we set the originatingLSPBufferSize = Smin then we know
that all packets will make it through legacy devices. I think a simple
conservative calculation by considering worse case overhead could give
us the Smin. Of course if there is a "L2 MTU path discovery mechanism"
which can tell what is a better value for S when sending packets then
such a value could be used otherwise the default has to be set to Smin.
Last, defining L2 MTU path discovery mechanism should be outside of the
TRILL scope or at least being optional.

Thanks
Sina

to

---

From: Radia Perlman <[email-masked]>
Date: Mon, 06 Apr 2009 15:36:20 -0700

Personally, I'm happy to completely get rid of any MTU discovery 
mechanism, and have the only change to the TRILL
spec at this point to say that IS-IS MUST NOT pad hellos. If Hellos 
don't get through, it could cause loops. If
there isn't an agreed-upon campus-wide MTU size, then
a) big data packets might not make it through on some links (who cares 
about data packets :-)  )
b) LSPs might not make it through on some links (perhaps could cause 
some problems, but I'm not sure if
this really would be that much of a problem)

There were some IS-IS people at the IETF meeting that seemed to be 
arguing that MTU discovery was important.
I'll raise the issue on the IS-IS mailing list, and see if anyone has 
any arguments about why it would be bad for TRILL
not to bother with MTU discovery.

***********
So, I think at this point we've agreed upon:

TRILL spec should be modified to say Hellos MUST NOT be padded

********
We are undecided about:

.   whether we need an MTU discovery mechanism, and if we have it, 
whether it
ought to be mandatory or optional, and whether we should have some sort 
of discovery mechanism for the
campus-wide MTU size.

Radia

---

From: "Sina Mirtorabi (smirtora)" <[email-masked]>
Date: Mon, 6 Apr 2009 16:15:09 -0700

Radia,

Supporting a minimum size packet in all links is important and L3 ISIS
relies on 1492 byte value. From a control plane perspective, if there is
a topology change and as a result the new LSP size cannot make it
through some nodes then all nodes may not have the same LSDB and you
could have a forwarding loop. From data plane perspective you could end
up black holing packet which could be less dramatic.

Any how the point I tried to make in my previous e-mail (which you
ignored ;-) is that we need to agree on a minimum size packet and in the
absence of other intelligent mechanism, such a minimum size value should
be used.

Thanks
Sina

> Sent: Monday, April 06, 2009 3:36 PM
> To: Sina Mirtorabi (smirtora)
> >> be unicast to the sender of the probe. I'd recommend some variant
on

---

From: "Sina Mirtorabi (smirtora)" <[email-masked]>
Date: Mon, 6 Apr 2009 20:45:06 -0700

Silvano,

I guess we all agree that the Hello must not be padded. The issue really
is that if your control and data traffic don't make it through, you may
have some other issues such as forwarding loop or black hole traffic.
Therefore in the absence of a (simple) mechanism to discover the MTU, we
better agree on a minimum size packet where the issue should not occur
for that minimum packet size. 

Thanks
Sina

> From: Silvano Gai (sgai)
> Sent: Monday, April 06, 2009 7:11 PM
> To: Radia Perlman; Sina Mirtorabi (smirtora)
> I support Radia Position " IS-IS MUST NOT pad hellos."
> 
> I don't care of MTU discovery
> 
> -- Silvano
> 
> 
> On 4/6/09 3:36 PM, "Radia Perlman" <[email-masked]> wrote:
> 
> >>> be, and does not report links to an RBridge neighbor R3, if the
R2-
> R3
> on a