Subject: Re: [rbridge] [Isis-wg] Progressing draft-ietf-isis-trill

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Wed, 10 Nov 2010 05:38:36 -0800

I am struggling to appreciate the rationale behind this two document
approach.

It is as if when defining the Three-Way-Handshake (RFC 5303) it was
decided that there would be two documents - one to define the state
machine and provide exposition - and a second to define the encoding of
the TLV. It could be done this way (though I am unclear on the
motivation) - but if so there would be interdependence between the two
documents and it would not be possible to conduct a complete review of
one without the other.

I have no wish to extensively discuss "process" - so if there is
consensus that in this case we should have two documents rather than one
- I will not argue the point. But I do not see that it is logical to
review/progress draft-ietf-isis-trill independent of the proposed
draft-ietf-trill-adj (or vice versa).

   Les

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Ralph Droms
> Sent: Sunday, November 07, 2010 5:27 PM
> To: [email-masked]; isis list mailing
> Cc: [email-masked]; [email-masked]
> Subject: [Isis-wg] Progressing draft-ietf-isis-trill
> 
> 
> Ralph and Stewart (as ADs responsible for TRILL and ISIS WGs) have
> agreed on the following way forward with regard to
> draft-ietf-isis-trill.
> 
> draft-ietf-isis-trill will include a normative reference to a new
> document to be produced by the TRILL WG. For the purposes of this
> email we will call it draft-ietf-trill-adj.
> 
> draft-ietf-isis-trill will now proceed to the IESG for review and
> approval in the normal process, but will wait in the RFC Editor's
> queue on the normative reference (as it would wait for the publication
> of any other normative reference) to draft-ietf-trill-adj.
> 
> draft-ietf-trill-adj will provide a state machine description of the
> adjacency formation including:
> 
> - Adjacency formation
> - DRB (aka DIS) election
> - rules for two-way and MTU matching for advertisements
> - creation/use of pseudo-nodes
> 
> Stewart and Ralph
> _______________________________________________
> Isis-wg mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/isis-wg

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

---

From: Erik Nordmark <[email-masked]>
Date: Wed, 10 Nov 2010 18:58:46 -0800

> I am struggling to appreciate the rationale behind this two document

I think we are doing this in the interest of protocol document quality, 
and bending the process rules in order to reach the desired document 
quality.

We last called draft-ietf-trill-rbridge protocol-10 first in the TRILL 
WG on Fri, 07 Nov 2008 and that last call email was forwarded to the 
ISIS WG mailing list ten days later. (The MTU PDUs where not in place 
back then, but the adjacency formation hasn't changed since then.) That 
resulted in a few comments, but the concerns about the adjancency state 
machine were not raised at that point in time.

We had a TRILL WG last call draft-ietf-trill-rbridge-protocol-13.txt on 
06/30/09. After some edits an IETF last called was done on -14 on 
2009-12-18.

To really make sure that is IS-IS experts have reviewed the document, a 
separate ISIS WG last call was requested by routing AD Ross Callon. Thus 
it was last called in IS-IS on 01/28/10. While there isn't any process 
document which describes such an extra last call, it made some sense to 
ensure that the document was reviewed by ISIS experts that do not 
participate in the TRILL WG. That ISIS WG last call didn't result in any 
comments AFAIK.

Apparently that was not sufficient to get proper attention, since the 
concerns about the adjacency state machine were not raised until the 
code point document (draft-ietf-isis-trill) was last called.

So I agree things are quite unusual for this document; I think our 
desire to accept very late comments on draft-ietf-trill-rbridge-protocol 
is far beyond what I've seen for any other document in any other WG. 
These comments were submitted more than 6 months after the IESG had 
approved the document.

I'm quite concerned that we are setting a bad precedent by bending over 
backwards to consider such extremely late comments, because it 
encourages suboptimal review timing. Yet I accepted the AD way forward 
to create a separate document with the adjacency state machine. I'm 
starting to think that was a mistake and I should instead have filed an 
appeal against the ISIS WG not approving draft-ietf-isis-trill.

Sigh.

    Erik

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Wed, 10 Nov 2010 20:29:54 -0800

Erik -

My concern in regards to the proposed use of two documents
(draft-ietf-trill-adj/draft-ietf-isis-trill) has nothing to do with
"process" - which you discuss in detail below. It has to do with the
interdependence of the content. When defining extensions to the IS-IS
protocol it is necessary to define the new protocol behaviors and to
define the new TLVs, sub-TLVs, etc. that are used in support of the new
behaviors. To separate the two into different documents is arbitrary and
illogical. Until the review of the protocol behavior is completed we
cannot know if the current definition of the TLVs is complete and
accurate. And until the review of the TLVs is completed we cannot know
whether the protocol behavior description is complete and accurate. Thus
the separation makes life more difficult for both the reviewers and the
authors - and ultimately makes the use of the document(s) as a reference
more difficult.

I used the example of RFC 5303 - but one could look at any of the RFCs
that have been produced by the IS-IS WG (as well as other WGs) over the
years. No one has chosen to make such a separation - and I think for
very good reasons.

I believe the goal at this time is to provide the IS-IS WG with the
opportunity to review the changes to the IS-IS protocol which are
required by TRILL. A complete review requires a document which both
provides the normative definition of the changes and definition of the
encoding used in support of those changes. This most logically belongs
in a single document. If the consensus is that two documents be used
then so be it - but this does not mean that it makes sense to progress
the two documents independently.

In regards to the history you present below, I will only say that an
expectation was explicitly set as far back as draft-ward-l2isis-xx (back
in 2005!!) that all extensions to the IS-IS protocol in support of the
L2 technologies would be defined in an IS-IS WG draft. In more recent
times we had draft-ietf-isis-layer2-xx and now L2 technology specific
documents. My assumption has always been that once the various L2
technologies had reached a level of maturity that they would add the
normative description of changes to the IS-IS protocol processes to an
IS-IS document along with the TLV definitions as this has been the
normal practice with all other protocol extensions as noted above.

   Les

> From: Erik Nordmark [mailto:[email-masked]]
> Sent: Wednesday, November 10, 2010 6:59 PM
> To: Les Ginsberg (ginsberg)
> Cc: Ralph Droms; [email-masked]; isis list mailing; int-
> [email-masked]; [email-masked]
> Subject: Re: [Isis-wg] Progressing draft-ietf-isis-trill
>

---

From: Erik Nordmark <[email-masked]>
Date: Wed, 10 Nov 2010 20:54:49 -0800

> authors - and ultimately makes the use of the document(s) as a reference

The protocol behavior for TRILL is specified in 
draft-ietf-trill-rbridge-protocol, and not in a draft-ietf-isis-trill. 
That was the reason we asked the ISIS WG to review that document several 
times over several years. As has been stated in the past, there was an 
agreement between the INT and RTG ADs and the TRILL and ISIS co-chairs 
to do the ISIS code points and TLV formats in the ISIS WG.

The new draft-ietf-trill-adj is split from 
draft-ietf-trill-rbridge-protocol due to the extremely late review 
comments we received as I specified in my email.

I don't think it is uncommon to have code points and formats be reviewed 
separately in the IETF. For example, some new protocol might require 
some new DHCP option which would be reviewed in the DHC WG.

Having reviewed protocol documents in the IETF for a number of years 
that doesn't seem like a big deal.

> required by TRILL.

That opportunity started in 2008 (and we did receive some comments back 
then) and concluded with the last call in ISIS in January 2010.

> normal practice with all other protocol extensions as noted above.

The ISIS chair agreed to only have code points and TLV formats in ISIS 
with the blessings of the RTG and INT ADs.
Were you not informed of this agreement?

   Erik

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Wed, 10 Nov 2010 21:17:07 -0800

Erik -

We are covering old ground.

No I was not informed of the agreement you mention below - and in fact I
inquired when last call was started on draft-ietf-isis-trill as to what
to expect in the document and I was told otherwise.

Now, we can spend a bunch of cycles trying to track down who to blame
for this confusion - but this is not helpful. There does seem to be
agreement now that both a normative description of the protocol process
changes and the TLV codepoints should be reviewed by IS-IS WG. I would
prefer that this be done in one document - but if two documents is the
format chosen so be it.

What I am not willing to do is pass final judgment on the TLV codepoint
document (draft-ietf-isis-trill) independently of a review of the
protocol process specification - for reasons I have already stated.

   Les

> Sent: Wednesday, November 10, 2010 8:55 PM