Subject: Re: [Isis-wg] draft-ietf-isis-trill-01: Adjacency State Machinery

From: Donald Eastlake <[email-masked]>
Date: Tue, 7 Sep 2010 23:52:11 -0400

Hi Les,

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

>> 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.
>
> The IS-IS-WG document has NOT been last called.

Right, that's why I refer to "the TRILL base protocol specification"
above.

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

That was not the agreement reached by the Internet and Routing ADs in
May 2009. That agreement included acceptance of the TRILL Hello
protocol in the TRILL base protocol standard and agreement that the
IS-IS code points and data formats would be in the ISIS WG document
and the TRILL specific behaviors would be in the TRILL document.

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

I note that the subject line of this mail says
"draft-ietf-isis-trill-01". I believe that draft-ietf-isis-trill-01 is
quite clear. In fact, it has benefited greatly from extensive comments
by members of the ISIS WG including Mike Shand and, if I recall
correctly, at least one comment from yourself.

In fact, this is nothing to do with the adequacy or clarity of
draft-ietf-isis-trill-01, a document which, as it states in the
abstract "specifies the data formats and code points for the IS-IS
extensions to support TRILL". All your comments have been about the
adequacy of the behavioral descriptions in
draft-ietf-trill-rbridge-protocol-16. What is really going on is that
you are improperly attempting to impose your opinion not just on the
TRILL WG but on the IETF.

The IETF has approved draft-ietf-trill-rbridge-protocol-16 as a
standard through an unusually thorough review process which even
included a special Last Call in the ISIS WG. I think it is improper
for you to demand that the substance of a such a TRILL WG IETF
standard be changed as the price for ISIS approval of such a stable
and thoroughly reviewed draft as draft-ietf-isis-trill-01.

In addition, while I do not agree with the ambiguity you have claimed,
as an author of draft-ietf-trill-rbridge-protocol-16, I'm happy to
commit to the AUTH48 editorial clarification pasted below since it
does not change the meaning of the document.

>   Les

Thanks,
Donald

AUTH48 Change: In the last paragraph of Section 4.4.2.1, replace

   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.

with

   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, that is, within a period that depends on
   RB1's policy and not necessarily within any specific period such as
   the holding time.

PS: Just in case you think I'm being abusive by cc'ing the ADs, I
would point out that the AD agreement mentioned above also provided
that the ADs SHOULD be cc'ed on cross-WG messages between TRILL and
ISIS.

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Wed, 22 Sep 2010 23:09:32 -0700

Donald -

The statement from the IS-IS WG co-chairs earlier today clearly asserts the expectation that IS-IS WG documents for all the L2 technologies MUST include clear specification of the changes to the base protocol. This makes sense to me and has been my understanding/expectation of what the L2 IS-IS WG documents would contain.

In regards to draft-ietf-isis-trill-01 here is at least a partial list of base protocol changes that I think need to be discussed in the draft in addition to the new TLV content which is already present:

1)Adjacency state machine - hold time on existing adjacencies is updated even when the hello does not include explicit verification of two way connectivity

2)DIS(AKA DRB) election - no two-way connectivity required for ISs to be considered as a candidate

3)Advertisement of neighbors in LSPs depends on both two-way connectivity and MTU match

4)Use of pseudo-node on a LAN is now optional and driven by the DRB choice

In the coming days I will try to discuss each of these in more detail. Hopefully others will also provide their comments.

My intent is to insure that the protocol extensions defined to support TRILL are technically sound and clearly specified. I would hope that is a goal we both find desirable. In that context it disturbs me that you believe that expressing my opinion is 

"improperly attempting to impose your opinion not just on the TRILL WG but on the IETF."

The IETF Mission statement is quite clear on the openness of the process and the opportunity for any individual to express their opinion - and I believe my posts are consistent with that philosophy. You may certainly disagree with the technical points that I make - but to suggest that I do not have the right to make them seems quite wrong to me. 

I hope in the coming days we will have constructive discussions.

   Les

> -----Original Message-----
> From: Donald Eastlake [mailto:[email-masked]]
> Sent: Tuesday, September 07, 2010 8:52 PM
> To: Les Ginsberg (ginsberg)
> Cc: isis mailing list; Ralph Droms; Stewart Bryant (stbryant); Jari
> Arkko; Adrian Farrel; Erik Nordmark
> Subject: Re: [Isis-wg] draft-ietf-isis-trill-01: Adjacency State
> Machinery
> 
> Hi Les,
>

---

From: Ralph Droms <[email-masked]>
Date: Thu, 23 Sep 2010 12:25:22 -0400

Les - in the case of draft-ietf-isis-trill, the necessary documentation of changes to the base IS-IS protocol is contained in draft-ietf-trill-rbridge-protocol-16.  I think all of the issues that you've raised are addressed in draft-ietf-trill-rbridge-protocol-16, which has completed its IETF review and is in the RFC Editor queue.  The distribution of protocol operation and semantics in draft-ietf-trill-rbridge-protocol and descriptions of PDUs and TLV formats in draft-ietf-isis-trill has been the working arrangement between the trill and isis WGs for the TRILL specification.

- Ralph

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Thu, 23 Sep 2010 11:10:22 -0700

Ralph -

Your statements are in direct contradiction to the statements of the
IS-IS WG chairs - and I am proceeding on that basis - which frankly
makes sense to me since extensions to IS-IS have always been defined in
IS-IS WG documents.

Secondly, I do take issue that what is in
draft-ietf-trill-rbridge-protocol-16 is both comprehensive and clear in
regards to the the IS-IS base protocol changes. Please review earlier
emails in this thread for some indications as to why.

   Les

> From: Ralph Droms [mailto:[email-masked]]
> Sent: Thursday, September 23, 2010 9:25 AM
> Cc: Donald Eastlake; isis mailing list; Stewart Bryant (stbryant);
Jari
> Les - in the case of draft-ietf-isis-trill, the necessary
documentation
> of changes to the base IS-IS protocol is contained in
draft-ietf-trill-
> rbridge-protocol-16.  I think all of the issues that you've raised are
> addressed in draft-ietf-trill-rbridge-protocol-16, which has completed
> its IETF review and is in the RFC Editor queue.  The distribution of
> protocol operation and semantics in draft-ietf-trill-rbridge-protocol
> and descriptions of PDUs and TLV formats in draft-ietf-isis-trill has
> been the working arrangement between the trill and isis WGs for the
> TRILL specification.
> 
> - Ralph
> 
> > The statement from the IS-IS WG co-chairs earlier today clearly
> asserts the expectation that IS-IS WG documents for all the L2
> technologies MUST include clear specification of the changes to the
> base protocol. This makes sense to me and has been my
> understanding/expectation of what the L2 IS-IS WG documents would
> contain.
> >
> > In regards to draft-ietf-isis-trill-01 here is at least a partial
> list of base protocol changes that I think need to be discussed in the
> draft in addition to the new TLV content which is already present:
> >
> > 1)Adjacency state machine - hold time on existing adjacencies is
> updated even when the hello does not include explicit verification of
> two way connectivity
> >
> > 2)DIS(AKA DRB) election - no two-way connectivity required for ISs
to
> be considered as a candidate
> >
> > In the coming days I will try to discuss each of these in more
> detail. Hopefully others will also provide their comments.
> >
> > My intent is to insure that the protocol extensions defined to
> support TRILL are technically sound and clearly specified. I would
hope
> that is a goal we both find desirable. In that context it disturbs me
> that you believe that expressing my opinion is
> >
> > The IETF Mission statement is quite clear on the openness of the
> process and the opportunity for any individual to express their
opinion
> - and I believe my posts are consistent with that philosophy. You may
> certainly disagree with the technical points that I make - but to
> suggest that I do not have the right to make them seems quite wrong to
> me.
> >
> >>>> way with some degree of informality in IETF Proposed Standards,
to
> >> be

---

From: Ralph Droms <[email-masked]>
Date: Sat, 25 Sep 2010 17:36:02 +0100

Les - The Routing and Internet Area Directors (including myself), and the isis and trill WG chairs have an agreement about how the content of the TRILL specification is divided between draft-ietf-trill-rbridge-protocol and draft-ietf-isis-trill.  The modifications to IS-IS for TRILL are, according to that agreement, documented in draft-ietf-trill-rbridge-protocol, so "any changes to the fundamental ISIS protocol machinery" in the case of TRILL should be reviewed in draft-ietf-trill-rbridge-protocol.

draft-ietf-trill-rbridge-protocol-16 has been reviewed and accepted by the IETF for publication as an RFC.  There have been successful interop tests of implementations based on draft-ietf-trill-rbridge-protocol-16.  Seems we can conclude draft-ietf-trill-rbridge-protocol-16 is sufficiently comprehensive and clear to move on to WG, IETF and IESG review of draft-ietf-isis-trill.

- Ralph

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Sat, 25 Sep 2010 15:43:10 -0700

Ralph -

The IS-IS WG chairs have made a clear statement which is contrary to
what you say below. If you have an issue - please take it up w the WG
chairs.

I will say that logically it makes no sense to confine the discussion in
the IS-IS WG to simply the content of new TLVs. Changes to fundamental
IS-IS protocol processes obviously fall under the purview of the IS-IS
WG and are of greater significance than the contents of a new TLV. So if
the WG is required to approve new TLV content in an IS-IS WG document,
then it should also be required to approve protocol process changes in
an IS-IS WG document.

   Les

> Sent: Saturday, September 25, 2010 9:36 AM
Jari
> Les - The Routing and Internet Area Directors (including myself), and
> the isis and trill WG chairs have an agreement about how the content
of
> the TRILL specification is divided between draft-ietf-trill-rbridge-
> protocol and draft-ietf-isis-trill.  The modifications to IS-IS for
> TRILL are, according to that agreement, documented in
draft-ietf-trill-
> rbridge-protocol, so "any changes to the fundamental ISIS protocol
> machinery" in the case of TRILL should be reviewed in
draft-ietf-trill-
> rbridge-protocol.
> 
> draft-ietf-trill-rbridge-protocol-16 has been reviewed and accepted by
> the IETF for publication as an RFC.  There have been successful
interop
> tests of implementations based on
draft-ietf-trill-rbridge-protocol-16.
> Seems we can conclude draft-ietf-trill-rbridge-protocol-16 is
> sufficiently comprehensive and clear to move on to WG, IETF and IESG
> review of draft-ietf-isis-trill.
> 
> - Ralph
> 
> >>> 4)Use of pseudo-node on a LAN is now optional and driven by the
DRB
> >> choice
> >>> "improperly attempting to impose your opinion not just on the
TRILL
> >> WG but on the IETF."
> >>>>>> type formal standards with conformance testing. I believe in
the
> >>>> IETF
> >>>>>> conformance testing. And, it appears to me that in this case
the
> >>>> TRILL
> >>>>>> Routing Directorate reviewer, and the IETF in IETF Last Call,
> and
> >>>> the
> >>>> That was not the agreement reached by the Internet and Routing
ADs
> >> in
> >>>> "draft-ietf-isis-trill-01". I believe that draft-ietf-isis-trill-
> 01
> >> is

---

From: Tony Li <[email-masked]>
Date: Sat, 25 Sep 2010 21:58:37 -0700

While I'm less concerned about the ownership of the document, I'll note that draft-ietf-trill-rbridge-protocol was last called in the IS-IS WG in Jan. 2010.   That was version 15, which is no longer current.  There appear to have been non-trivial changes in -16.

While the chair did mention that section 4.2 might be of interest, there was no indication that protocol fundamentals were being changed.

If you're going to perform open heart surgery, it sure would be nice to tell the patient.

I would strongly recommend that we do an IS-IS WG LC of draft-ietf-trill-rbridge-16.

Tony

On Sep 25, 2010, at 3:43 PM, Les Ginsberg (ginsberg) wrote:

> _______________________________________________
> Isis-wg mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/isis-wg

---

From: Ralph Droms <[email-masked]>
Date: Sun, 26 Sep 2010 08:34:06 +0100

Tony - can you be specific about problems with any non-trivial changes you see? The goal, of course, is a correct specification and we can fix deficiencies through AUTH48 updates; however, it would be unusual to re-open a doc that has been accepted for publication for another WG last call.

- Ralph

---

From: Tony Li <[email-masked]>
Date: Sun, 26 Sep 2010 00:40:21 -0700

Ralph,

I haven't had a chance to review it yet, in part because I was unaware of the deal that was in place.

Tony

---

From: David Ward <[email-masked]>
Date: Sun, 26 Sep 2010 09:49:00 -0700

All -

The ISIS WG is more than willing to accept a WG LC on trill-rbridge-16. The chairs have tried to bring to the attention of the ISIS an TRILL WGs repeatedly over the last 18 months the importance of understanding and reviewing the proposed changes for TRILL, .aq as they effect the IS-IS protocol. There has been much discussion on the list and and during scheduled WG meetings on this topic and any changes that are being introduced to the protocol. Although there are claims of interoperable implementations of routing portion of TRILL, I know of none (which doesn't really mean anything) but, I point out that the ISIS and TRILL WG modified the protocol significantly in the last 6 months from new packet types to TLVs (in an attempt to reduce changes to the ISIS protocol and efficiency). Given the magnitude of the changes, the ISIS WG would be interested in receiving the implementation report on the implementations of TRILL-16 and isis-trill-01. Ralph, can you help here?

A wdiff of -15 and -16 of the TRILL protocol document can be found here:

http://tools.ietf.org/rfcdiff?url1=draft-ietf-trill-rbridge-protocol-15&difftype=--hwdiff&submit=Go%21&url2=draft-ietf-trill-rbridge-protocol-16

If the WG would like an opportunity to review TRILL-16 at the same time as ISIS-TRILL-01 we'll work to make that happen.  Note that additionally, Acee Lindem provided a routing directorate review of -15 which we did not receive (neither WG chairs nor WGs).

-DWard, CHopps

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Mon, 27 Sep 2010 23:53:29 -0700

[TRILL] refers to draft-ietf-trill-rbridge-protocol-16.txt
[IS-IS-TRILL] refers to draft-ietf-isis-trill-01.txt

[TRILL] defines a number of changes to the information exchanged between
neighbors. Although it uses the same IIH PDUs as Layer-3 IS-IS ([TRILL
4.4.2]) is out of date in this regard) it uses different TLVs. These
differences are most pronounced on a LAN and include:

1) The ability to advertise a subset of the neighbors on the link in a
given IIH [IS-IS-TRILL 2.5]
2) Advertisement of appointed forwarders for VLANs (DRB function)
[IS-IS-TRILL 2.2.3]

The combination of these two, but in particular advertisement of
appointed forwarders, makes the set of information which is required to
be advertised in LAN-IIHs potentially quite large. That in combination
with a modest limitation on the max size of a LAN-IIH (1470 octets)
makes it likely that a single IIH will not be able to advertise the full
set of information a given RBridge is required to send to its neighbors.
This has a number of consequences.

Convergence time (i.e. the time it takes to be notified of the loss or
addition of two way connectivity to a neighbor) becomes indeterminate.
This is because a given IIH is only required to advertise a locally
defined subset of the neighbors with which it currently has two way
connectivity. To avoid spurious flapping of adjacencies an IS is
REQUIRED to update the hold time on an existing adjacency in the UP
state whenever an IIH is received from that neighbor so long as there is
no explicit indication that two-way connectivity has been lost. An
adjacency can be maintained indefinitely without any explicit indication
that two-way connectivity exists so long as IIHs are being received from
that neighbor. If a change in adjacency state needs to be signalled
explicitly, implementors will have to devise a strategy to tradeoff VLAN
appointed forwarder updates vs adjacency state updates.

More significant, however, is the way appointed forwarder updates are
advertised. The DRB is required to advertise this information in
LAN-IIHs and as the number of supported VLANs can be large this can be a
significant amount of information. How large depends on the number of
VLANs supported, how sparsely they are distributed through the 12 bit
VLAN number space, and what algorithm is used to assign a subset of
VLANs to a given RBridge.

Reliable distribution of this information to all participating RBridges
on a LAN is key to correct operation of TRILL. Distribution of appointed
forwarder information has the same requirements in regards to
reliability as information sent by the IS-IS Update Process in LSPs with
the difference that its scope is a single circuit rather than the
area/domain. However, as currently defined there is no confirmation of
receipt of appointed forwarder information. As there is no explicit
indication that a given RBridge has successfully received the latest
appointed forwarder information this requires that the DRB MUST
continuously send appointed forwarder information.
 
It can be expected that appointed forwarder information changes
infrequently. In the absence of the addition/deletion of neighbors on a
LAN and/or the enabling/disabling of VLANs the actual appointed
forwarder information is likely not to change at all - yet the
advertisent of this information will be repeated endlessly. This will
require all RBridges on the LAN to check the contents of the appointed
forwarders subTLV(s) in every IIH received from the DRB so as not to
miss any changes.

I see a number of potential ways to provide reliability to the appointed
forwarder updates - each of which has advantages and disadvantages. At
the present time I am just presenting the alternatives w/o advocating a
particular solution.

Solution #1: DRB includes an appointed forwarders sequence number subTLV
in IIHs. Whenever a change is made to the appointed forwarders database
the DRB bumps the sequence number. In addition an S/L flag similar to
what has been proposed for the TRILL Neighbor TLV is added to the actual
appointed forwarders subTLV so the DRB can explicitly indicate when the
full range has been advertised. Non DRBs on the LAN indicate when they
have successfully received the full set of appointed forwarders on the
LAN for a given sequence number by including an appointed forwarders
acknowledgement subTLV in their IIHs. The ACK would indicate the latest
sequence # for which they have successfully received a complete set of
updates (0 => none successfully received). In this way the DRB would
know when it is safe to stop sending appointed forwarder information. So
long as at least one neighbor on the LAN indicates it does not have
current information the DRB would need to send appointed forwarder
information in its IIHs.

Advantages: Adds reliability to the distribution of information and
minimizes the amount of needless repetition of the advertisements.

Disadvantages: Uses potentially large amounts of IIH space when
advertisements are needed. Retransmission is driven solely by the hello
interval - convergence is therefore likely to be sub-optimal.

Solution #2: Move the advertisement of appointed forwarder information
into the pseudo-node LSPs. 

Advantages: Reliability is provided by the normal operation of the
update process. Needless repetition is eliminated. Use of space in IIHs
for this information is no longer required which in turn will reduce
adjacency state change convergence issues. Retransmission (when needed)
is event driven so convergence is likely to be faster than solution #1.

Disadvantages: Information whose scope is local to a given circuit is
distributed area wide. It can easily be ignored by ISs who do not have a
neighbor to the pseudo-node, but it still must be stored in the LSP
database and must be flooded area wide.

Solution #3: Invent a new PDU which has the same semantics as an LSP but
whose flooding scope is confined to a given circuit and use that to
advertise appointed forwarder information.

Advantage: Similar advantages to Solution #2 - plus ISs not connected to
the circuit will never see this information.

Disadvantage: Requires the greatest changes to the protocol as we need
to invent an instance of the update process which is local to a circuit.

   Les

---

From: Radia Perlman <[email-masked]>
Date: Wed, 29 Sep 2010 17:20:10 -0700

Les...Once again, you are making assertions about broken mechanisms in
TRILL, and you are (again) incorrect.  The protocol handles the cases
you are talking about, with actually multiple safety mechanisms where
any one of them would be sufficient. I'm getting exhausted arguing
with you about these things.  Ordinarily I enjoy explaining things,
but when someone continually makes loud public assertions about things
being broken, rather than asking polite questions, I run out of
patience and time.  In the future, if you have concerns over certain
mechanisms, first assume that such a widely reviewed spec and protocol
designed by very competent people is correct and it is likely that you
just do not understand it, and then phrase your concern in the form of
a polite question about what happens in this case or that, and
preferably, just to the authors instead of cluttering the whole
mailing list.

The mechanisms in the trill spec are clearly specified, as in "do
exactly this".  All the assertions you've made about ambiguities,
opportunities for noninteroperability (in this and previous messages)
etc., are incorrect. Perhaps the
spec is so detailed that the motivations for the mechanisms are not as
clear as they could be, but I don't even believe that.  I believe the
spec, despite its excruciating detail (thanks to Donald mostly), is
still readable. However, even though I believe the spec is readable,
sometimes a tutorial document that doesn't bother with all the
details, but focuses on the motivations, can be instructive.  I do
enjoy writing such documents, and would be happy to, especially if
there is anyone other than you that is having trouble understanding
the spec.  The people actually interested in implementing it did not
seem to have any problems with the document. But writing a tutorial
document will have to wait until I have more time, and there is no
excuse for delaying the packet format document until (and if) the
tutorial document exists.

As for suggesting incompatible optimizations at this point...the time
for constructive participation in
the design has long passed, except for new features that the WG will
be designing, in which case
anyone (including you) is certainly welcome to participate (politely
and respectfully).

Radia

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Wed, 29 Sep 2010 19:40:15 -0700

Radia -

> From: Radia Perlman [mailto:[email-masked]]
> Sent: Wednesday, September 29, 2010 5:20 PM
> Cc: isis mailing list
> Subject: Re: [Isis-wg] Comments on draft-ietf-isis-trill-01: Hello
> Protocol
> 
> any one of them would be sufficient.

A close reading of my original text in this thread would show that I
have NOT stated that TRILL is "broken" in regards to the issues
discussed - rather I have stated that it is sub-optimal in significant
ways. Now, perhaps you think even that statement is incorrect - in which
case I would appreciate if you would take the time to address the
following point that I made:

> > as currently defined there is no confirmation
> of
> > continuously send appointed forwarder information...
> > This will

If you believe this to be incorrect please cut and paste the relevant
lines from draft-ietf-trill-rbridge-protocol-16.txt and/or
draft-ietf-isis-trill-01.txt - add whatever supplementary explanation
you feel would be helpful and demonstrate that I am in error.

Thanx.

   Les