Subject: [Isis-wg] Advancing draft-ietf-isis-layer2

From: Donald Eastlake <[email-masked]>
Date: Wed, 11 Aug 2010 23:06:42 -0400

Hi Dave,

As far as I know, draft-ietf-isis-layer2-06.txt is not controversial.

Can this draft be advanced now, presumably through a Working Group Last
Call?

Thanks,
Donald
=============================
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 155 Beaver Street
 Milford, MA 01757 USA
 [email-masked]

---

From: Peter Ashwood-Smith <[email-masked]>
Date: Thu, 12 Aug 2010 09:13:44 -0400

I have no objections.

Peter

  _____  

From: [email-masked] [mailto:[email-masked]] On Behalf
Of Donald Eastlake
Sent: Wednesday, August 11, 2010 11:07 PM
To: David Ward; isis mailing list
Subject: [Isis-wg] Advancing draft-ietf-isis-layer2

Hi Dave,

Thanks,

Donald

---

From: Paul Unbehagen <[email-masked]>
Date: Thu, 12 Aug 2010 08:37:08 -0700

Ditto

--
Paul Unbehagen

from my iPhone 

On Aug 12, 2010, at 6:13 AM, Peter Ashwood-Smith <[email-masked]> wrote:

> I have no objections.
>  
> Peter
>  
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Donald Eastlake
> Can this draft be advanced now, presumably through a Working Group Last Call?
>  
> Thanks,
> Donald
> _______________________________________________
> Isis-wg mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/isis-wg

---

From: David Ward <[email-masked]>
Date: Thu, 12 Aug 2010 08:09:32 -0700

Dear WG -

Let's have some comments on the three draft suite:

TRILL

AQ

layer2

and make certain that the split is correct; then we'll last call.

There is a known overlap of the definition of TLV 143 in layer2 and trill but, after chatting with the authors of the trill draft; layer2 will be the draft in which TLV 143 is defined and referenced in other drafts.

WG LC will start the 26th barring any massive reconstruction of the drafts.

Thanks

-DWard, CHopps

On Aug 11, 2010, at 8:06 PM, Donald Eastlake wrote:

Hi Dave,

Thanks,
Donald
=============================
 Donald E. Eastlake 3rd   +1-508-333-2270 (cell)
 155 Beaver Street
 Milford, MA 01757 USA
 [email-masked]<mailto:[email-masked]>

---

From: "Fedyk, Donald (Don)" <[email-masked]>
Date: Thu, 12 Aug 2010 20:05:06 -0500

Hi Dave

Can you (or someone) comment on the final organization of the Layer2 draft?  We had 2 TLVs that were used by Trill and OTV. And one used by SPB Trill and OTV for a total of 3.   The Layer2 v06 draft now has 2 of those.

MAC-RI TLV  (141)  Trill & OTV 
MT-Port-Cap-TLV (143)  All  

What about 
GADDR-TLV   (142) ?  Trill & OTV

What was the rational for including 143 and not 142 ? 

Thanks,
Don                   

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of David Ward
Sent: Thursday, August 12, 2010 11:10 AM
To: Donald Eastlake
Cc: isis mailing list
Subject: Re: [Isis-wg] Advancing draft-ietf-isis-layer2

Dear WG -

TRILL

AQ

layer2

Thanks

-DWard, CHopps

Hi Dave,

Thanks,
Donald

---

From: Donald Eastlake <[email-masked]>
Date: Fri, 20 Aug 2010 10:28:08 -0400

Hi,

I've re-read draft-ietf-isis-layer2-06.txt and have only one minor comment:
The last sentence of the first paragraph of Section 1, Overview, on page 3,
seems to have a problem. I think that sentence should be dropped or fixed.

Thanks,
Donald

On Thu, Aug 12, 2010 at 11:09 AM, David Ward <[email-masked]> wrote:

> There is a known overlap of the definition of TLV 143 in layer2 and trill
> but, after chatting with the authors of the trill draft; layer2 will be the
> draft in which TLV 143 is defined and referenced in other drafts.
>

---

From: Donald Eastlake <[email-masked]>
Date: Sun, 22 Aug 2010 21:27:14 -0400

Hi,

> Let's have some comments on the three draft suite:

I plan to make the following changes in draft-ietf-isis-trill-00.txt before
the announced target date for the Working Group Last Call on it:

- Remove TLV 143 and reference draft-ietf-isis-layer2
- In Section 4.3, change the level of requirement for including the
Protocols Supported TLV from "SHOULD" to "MUST".
- In Section 4.1, an earlier draft specified that the Maximum Areas field
must be set to 1 but this seems to have gotten dropped along the way. Append
to the second paragraph the sentence "The Maximum Area Addresses octet in
the common fixed header MUST be set to 0x01."
- In Section 2.5, as a clarification, add to the end of the Section the
following sentence: "If an RBridge believes it has no neighbors, its MUST
send an empty TRILL Neighbor TLV, which will have both the S and L bits on."

Thanks,
Donald

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Wed, 25 Aug 2010 15:05:54 -0700

One of the major changes to the IS-IS protocol which is introduced by
TRILL is a change in the adjacency state machine. Because of the need to
advertise a potentially large amount of VLAN information in IIHs, it is
recognized that it may not always be possible to send a complete set of
TRILL neighbors (replacement for IS-neighbors) in a given IIH. There are
also interactions w the new MTU testing PDUs. All of this affects the
way adjacencies are brought up and maintained - but the details of the
revised state machine are not specified. For example, how long should
IS-A maintain it's neighbor relationship to IS-B given that an
indefinite number of IIHs might be received from IS-B which do not
include any verification (positive or negative) that two way
connectivity exists between IS-A and IS-B??

There is some background text in draft-ietf-trill-rbridge-protocol-16 -
but this is not normative and it is difficult to derive exactly what an
implementation MUST do to be interoperable. Also, while it is logical
for the TRILL spec to describe the motivation for the IS-IS protocol
changes, the appropriate place to provide a normative description of the
protocol changes is in draft-ietf-isis-trill.

I think this is a necessary part of draft-ietf-isis-trill. A state table
would be preferable - but other forms could be used if the authors wish
so long as the result is unambiguous and provides a reference which
implementors can use to ensure interoperability and conformance.

   Les

---

From: Donald Eastlake <[email-masked]>
Date: Sat, 28 Aug 2010 19:39:49 -0400

Hi Les,

> connectivity exists between IS-A and IS-B??

The change due to fragmenting the Neighbor TLV is very minor and, as
far as I know, implementers are not having any inordinate problems
with this. The event of receiving a Hello in which you are not listed
in the Neighbors TLV (ISO 10589, Section 8.4.2.5.3) is simply replaced
by the event of receiving a Hello where the TRILL Neighbors TLV covers
a range of MAC addresses including yours and you are not listed.

If you have an adjacency but then you continue to get Hellos from that
Neighbor and never get one that covers a range of MAC addresses
including you, under the present TRILL standard, the adjacency would
stay up forever. Given that the Holding Time can be over 18 hours, I
don't see a practical difference between an obnxious Intermediate
System that sets an 18 hour+ Holding Time and withholds Hellos for 18
hours (yes, I'm assuming no other events occur in the interim that
require a Hello) and an obnoxioius RBridge that regularly sends Hellos
but, after indicating it can hear you, fails to ever include a TRILL
Neighbor TLV that covers your MAC address. I suppose, if people do see
a diffeence, a 2**16 - 1 second time limit could be added.

> protocol changes is in draft-ietf-isis-trill.

Perhaps you mean "not formal"? The TRILL base protocol specification
is an approved standards track document so I don't understand why you
say that document is not "normative". TRILL is being implemented today
based on the TRILL base protocol standard (and the code points and
data structures specified in isis-layer2 and isis-trill), a successful
TRILL control plane plug-fest has been held at UNH IOL, etc.

Of course, many parts of the TRILL base protocol specification could
be improved in various ways.

> implementors can use to ensure interoperability and conformance.

I didn't think the IETF did conformance...

Although none of the various groups implementing TRILL has complained
that the specification of the Hello protocol was incomplete or
difficult to understand, we could produce a separate draft focusing
just on the Hello protocol, or perhaps covering any other parts of
TRILL that could benefit from more in depth or more explanatory
verbiage

Thanks,
Donald

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Sun, 29 Aug 2010 00:50:09 -0700

Donald -

Thanx for the reply.
Inline.

> From: Donald Eastlake [mailto:[email-masked]]
> Sent: Saturday, August 28, 2010 4:40 PM
> To: Les Ginsberg (ginsberg)
> Cc: isis mailing list; Erik Nordmark; Ralph Droms
> Subject: Re: [Isis-wg] draft-ietf-isis-trill-01: Adjacency State
> Machinery
> 
> Hi Les,
> 

A minimal requirement for a protocol standard is to include definition of what the externally visible behavior of an implementation MUST BE in order to comply with the standard. In regards to adjacency maintenance, ISO 10589 is very clear:

<snip>
Section 8.4.2.5.3 
If a Level n LAN IIH PDU is received from neighbour N, and this system's lANAddress is no longer in N's IIH PDU, the IS shall

a)	set the adjacency's adjacencyState to "initialising", and
b)	generate an adjacencyStateChange (Down) event.
<end snip>

Clearly this text is no longer applicable to IS-IS use in support of TRILL. What text is offered to replace the text above? What I can find from draft-ietf-trill-rbridge-protocol-16.txt is the following near the end of Section 4.4.2.1:

<snip>
To ensure that any RBridge RB2 can definitively determine whether RB1
   can hear RB2, RB1's neighbor list must eventually cover every
   possible range of IDs
<end snip>

Now, what is the meaning of "eventually"? Here are two possible meanings:

A)RB1 MUST cover every possible range of IDs at least once within the holding time advertised in its IIHs
B)RB1 MAY take longer than the advertised holding time to cover every possible range of IDs

An implementation written based on "A" would not interoperate with an implementation based on "B" under all circumstances. If RB1 uses interpretation B and under stress takes longer to cover the complete range of IDs in its hellos than the advertised holding time a neighbor implementation on RB2 based on interpretation A will flap the adjacency to RB1 in such a case. Is RB2 correct in flapping the adjacency or not? Given the text we have available it is not possible to know what the correct behavior is.

There are of course other related issues which are worthy of discussion. For example, ISO 10589 default behavior ensures that multiple IIHs which have all neighbors advertised will be sent within the holding time (once every hello interval - where holding time is a multiple of the hello interval). This prevents spurious flaps in the case that one IIH is dropped (either by the transmitter or the receiver) during peak link usage. Given that for TRILL the number of IIHs which cover the range of IDs associated with a given neighbor is reduced, what protection is there against spurious flaps in case of a single dropped IIH?

My point is that the specification as it currently exists lacks a definition of what is the correct behavior. I believe such a definition MUST BE a part of the new protocol standard.

> Perhaps you mean "not formal"?

My post is not meant to be provocative. I was in no way dismissing the TRILL document as not a standards track document. My comment was that the language in the TRILL document does not provide a clear definition of the required behavior (see my comments above for more detail). 

   Les

> The TRILL base protocol specification

---

From: Radia Perlman <[email-masked]>
Date: Sun, 29 Aug 2010 22:50:39 +0530

The phrase "If a Level n LAN IIH PDU is received from neighbour N, and
this system's lANAddress is no longer in N's IIH PDU" does not seem
unclear to me.  If there is a fragment that does not contain this
system's address, because this systems' address is not in the range
advertised in this PDU, that does not mean "this system's address is
no longer in the IIH PDU".  That phrase would only get invoked if a
Hello is received from N that covers this system's ID, and the
system's ID is not included.

This is the correct behavior.

Radia

---

From: Radia Perlman <[email-masked]>
Date: Sun, 29 Aug 2010 18:10:48 -0700

Based on an off-list exchange, I think it's worth a followup email to
explain the rationale for the design.  Again, I think the spec is
clear enough, but of course wording can always be improved.

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

The most important reason for a Hello in TRILL is to ensure there are not two
RBs that think they are DRB.  So the Hello timer needs to be fairly
short for *that* reason.

The urgency for seeing if connectivity between R1 and R2 has become
one-way after if was two-way at some point, is *not* high.

The way the spec is written, and the intention of the spec, is that if
R1 ever hears itself in R2's Hello, it is happy with the 2-way
connectivity of the R1-R2 link.  In other words, R1 does not assume
2-way connectivity has failed based on any timer.
Once R1 sees itself in R2's Hellos, as long as R1 continues to see
Hellos from R2, R1 assumes connectivity
is 2-way.  The only thing that will change R1's assumption of 2-way connectivity
is if R1 receives a Hello from R2 containing a neighbor list with
R1 in the reported range, but R1 is missing.  At that point, R1
reverts to assuming connectivity is 1-way.

R2 will eventually get around to reporting all the neighbor ranges (I
believe the spec is clear that
R2 must periodically  report all its neighbors, but it need
not be within a Hello interval), so eventually R1 will
discover if connectivity isn't 2-way.  Again, no need to report each
neighbor in the
same order of magnitude of time as how often R2 sends Hellos.  So even if
several consecutive of R2's Hellos that contain R1's range get lost,
yet R1 is still hearing R2's Hellos, then R1 will keep thinking
connectivity is 2-way.

This may seem weird, but the consequences are no big deal even in the
bizarre and improbable case where

a) connectivity was 2-way between R1 and R2,
b) there's enough neighbors that the neighbor list has to be split
among lots of fragments,
c) and then connectivity becomes one-way (R1 hears R2 but R2 stops hearing R1).

Let's look at the consequences of the above obscure case:

1) If either of R1 or R2 is the DRB, there won't be any problem because if
R2 stops hearing R1, there won't be reported connectivity in the LSPs
from R1-to-pseudonode-to-R2. (because R2 will stop reporting
connectivity to R1 in its LSPs)

2) There's only the very very obscure case, unlikely to happen, and not
that much of a problem, in which for a transition time until R1 hears
R2's Hello with the relevant address range, when R1
*could* get data packets through to R2 if R1 forwards to the DRB, that
R1 (not knowing R2 can't hear it) will send directly to R2 and some
data will get lost until R2 does
issue a fragment with R1's range.

I believe that the spec clearly specifies this behavior.  It does not
say that R1 should assume 1-way connectivity based on a time interval
without  hearing itself in R2's Hellos.  It could be conceptually
clearer to include the rationale, but if implementations just follow
the directions without assuming there should be a timer for being
reassured of 2-way connectivity continuing, I think the spec is
sufficiently clear.  There's already way more rationale in the TRILL
spec than most specs.

Radia

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Sun, 29 Aug 2010 19:16:00 -0700

Radia -

Thanx for the clarifications. From the information you provided below,
it is possible to understand the intended behavior. But it is not
possible to do that based on the current text in
draft-ietf-trill-rbridge-protocol-16/draft-ietf-isis-trill-01.

The point I raised at the beginning of this thread was that the TRILL
specification requires changes to the existing IS-IS adjacency state
machinery and that these changes are not clearly specified. As I have
previously cited ISO 10589 specifies:

<snip>
8.4.2.5.3 If a Level n LAN IIH PDU is received from neighbour N, and
this system's lANAddress is no longer in N's IIH PDU, the IS shall

Based on the text below it seems clear that this clause no longer
applies - but there is no text in the current drafts which states this.
Such a statement is necessary in a standard because it defines the
externally visible behavior of a conformant implementation. In the
absence of such a statement there is ambiguity which I have previously
illustrated.

What I am asking for is a commitment on the part of the authors of
draft-ietf-isis-trill-01 to include content which unambiguously
specifies this and other changes to the existing adjacency state
machine. This seems to me to be necessary and prudent - and it has
precedent (e.g. see RFC 5303).

There is another discussion which should be had as to whether the new
behavior of the protocol achieves what you have defined as its major
goal:

> The most important reason for a Hello in TRILL is to ensure there are
> not two RBs that think they are DRB.  

However it is difficult to have that discussion until there is a clear
definition of what the new behavior is. Explicit language in
draft-ietf-isis-trill-01 would make it easier to resolve the second
discussion.

   Les

> From: Radia Perlman [mailto:[email-masked]]
> Sent: Sunday, August 29, 2010 6:11 PM
> Cc: Donald Eastlake; isis mailing list
> 1) If either of R1 or R2 is the DRB, there won't be any problem
because
> if

---

From: Radia Perlman <[email-masked]>
Date: Sun, 29 Aug 2010 19:28:49 -0700

> this system's lANAddress is no longer in N's IIH PDU, the IS shall

To me, the wording is clear and correct as stated above.  "this
system's Address is
no longer in the PDU" means that you receive a PDU telling you that
you are now gone from the list. Meaning that
a range is reported in which your address should be included, but it
is explicitly not included.

Another interpretation might conceivably be "if you ever receive a
Hello without your address in it, even
though your address range is not reported, then
bring the adjacency down", but that would be if the reader didn't
understand the concept of fragmentation
as designed into IS-IS.  I really find it hard to believe that anyone
would read it that way.  The spec is explicit about
what it means to report the neighbors with addresses within a range.

I don't see how one can interpret the wording in the quote as saying
that you should time out the assumption of 2-way
connectivity based on any timer.  It's based on receiving a Hello
where your address is omitted.

So it seems completely unambiguous to me.

Radia

---

From: Radia Perlman <[email-masked]>
Date: Sun, 29 Aug 2010 20:34:23 -0700

And not only is the spec already clear and unambiguous, but note that
the state change description you quote has not changed. The
description in IS-IS is:

"8.4.2.5.3 If a Level n LAN IIH PDU is received from neighbour N, and
this system's lANAddress is no longer in N's IIH PDU, the IS shall

"

Those exact words still apply.

------
As for Les's comment below:

>>"There is another discussion which should be had as to whether the new

>>discussion."

--------
Really?  It's difficult to understand how to assure the DRB election
unless there's even more explanation?
Deferring to another RB is based solely on ID and priority. It
couldn't be clearer or simpler or more obviously correct.
It has nothing to do with 2-way connectivity.  We've discussed this
issue ad nauseum.  The protocol is extremely simple, and is carefully
designed so that these things are orthogonal
a) who is DRB
b) what connectivity you report in LSPs

Radia

---

From: Donald Eastlake <[email-masked]>
Date: Mon, 30 Aug 2010 00:23:32 -0400

Hi Les,

On Sun, Aug 29, 2010 at 3:50 AM, Les Ginsberg (ginsberg)
<[email-masked]> wrote:
>> ...

I'm sorry, I just do not see "A" above as a plausible interpretation
of "eventually". "Eventually" is an indefinite word that was chosen to
avoid implying any specific time.

Looking in my copy of Webster's Third New International Dictionary,
unabridged, for "eventually", I find the following definition: "at an
unspecified later time". Synonyms given are "finally" and
"ultimately". It is just not consistent with my understanding of
"eventually" or the English definition of the word for it to mean
"within the holding  time" or any other specific time because
"eventually" means unspecified.

> There are of course other related issues which are worthy of discussion. For example, ISO 10589 default behavior ensures that multiple IIHs which have all neighbors advertised will be sent within t…

I have no problem with your analysis if you assume that "A" above is a
plausible interpretation. But, since I do not believe that is a
plausible interpretation, the analysis is inapplicable, there is no
problem with interoperability, and there is no way a dropped IIH can
cause a spurious flap in the way you describe.

> ...
>> ...
> My post is not meant to be provocative. ...

And I'm not trying to give you a hard time. I just can't see your
interpretation of "eventually" as plausible.

We also disagree on the level of formality needed and, on this point,
I doubt that we will come to agreement. You seem to want ANSI/IEEE/ISO
type formal standards with conformance testing. I believe in the IETF
way with some degree of informality in IETF Proposed Standards, to be
verified and improved based on interoperability testing, not
conformance testing. And, it appears to me that in this case the TRILL
and ISIS WGs, when the document was last called in them, and the
Routing Directorate reviewer, and the IETF in IETF Last Call, and the
IESG when they approved it as a Proposed Standard, agreed that the
TRILL base protocol specification was adequately formal to be a
Proposed Standard.

Thanks,
Donald

---

From: Radia Perlman <[email-masked]>
Date: Sun, 29 Aug 2010 21:59:35 -0700

And to follow up on Donald's email...there is NO possibility of
non-interoperability,
even if some implementer somehow bizarrely assumed Les's suggested  A)
interpretation of
">> To ensure that any RBridge RB2 can definitively determine whether RB1
>>   possible range of IDs"

>> B)RB1 MAY take longer than the advertised holding time to cover every possible range of IDs

The reason there is NO interoperability problem is that the
transmitter (RB1 in this case) can cycle through its neighbors at any
rate, and  it does not affect RB2, because as the spec clearly states,
RB2 only transitions out of the 2-way connected state if it receives a
Hello from RB1 that explicitly specifies that RB2 is not included in
RB1's neighbors.

Again...you (Les) are somehow assuming that there is a state change by
RB2 based on a timer.  This is not true, would be a less good design,
and it never stated that in the spec, and I don't see any words
anywhere that could remotely be interpreted as saying that RB2 reverts
to "initializing" based on a time of non-receipt of positive
confirmation that RB1 still hears RB1.

The TRILL spec is intentionally vague about how frequently a
particular neighbor range must be included in a Hello because it does
NOT affect interoperability.  Different implementations can take
different choices and there is no problem. It only affects how quickly
the very minor and unlikely transition behavior of 2-way connectivity
reverting to 1-way is discovered, and as I explained in great detail
in my previous email, it's not a big deal for it to take awhile.  It's
a legitimate tradeoff that each RBridge can make based on overhead vs
how long they are willing for a very unlikely event with minor
consequences to persist.

Radia

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Mon, 30 Aug 2010 00:20:20 -0700

Hmmm...let's just take one of the many statements that have been made in
the last flurry of emails and put it to the test.

Radia says:

>...the spec clearly states,

Please find the text in draft-ietf-trill-rbridge-protocol-16.txt that
states the above and provide Section # and quoted text.

I appreciate that you have - in this email thread - articulated that the
expected behavior is as you stated above - but that does not mean that
you have included text in the current drafts which states this. The
problem w writing clear specs is realizing that what you had in mind may
not be what you actually stated.

BTW, this is not just about editorial nits. In reviewing this I was
trying to figure out:

a)What is the defined behavior
b)What issues - if any - there may be with the defined behavior

As I was having trouble understanding what the defined behavior is - it
is difficult to determine whether there are any issues.

   Les

> Sent: Sunday, August 29, 2010 10:00 PM
> To: Donald Eastlake
> Cc: Les Ginsberg (ginsberg); isis mailing list

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Mon, 30 Aug 2010 00:29:42 -0700

> TRILL base protocol specification was adequately formal to be a

The IS-IS-WG document has NOT been last called.

It has always been the understanding - even from the old days of a single IS-IS L2 draft - that the IS-IS WG document would be the normative spec for the IS-IS protocol changes - which is why my comments are coming at this time. I have been expecting that the IS-IS WG document would provide the behavioral definition of the protocol changes.

As far as what criteria I am holding you to - it is the same as every other RFC in the IS-IS WG - no more and no less.

   Les