Subject: [RTG-DIR] RtgDir review: draft-ietf-isis-mi-06

From: Ross Callon <[email-masked]>
Date: Fri, 7 Sep 2012 00:36:21 -0400

Hello,
I have been selected as the Routing Directorate reviewer for this draft. The Routing Directorate seeks to review all routing or routing-related drafts as they pass through IETF last call and IESG review, and sometimes on special request. The purpose of the review is to provide assistance to the Routing ADs. For more information about the Routing Directorate, please see http://www.ietf.org/iesg/directorate/routing.html
Although these comments are primarily for the use of the Routing ADs, it would be helpful if you could consider them along with any other IETF Last Call comments that you receive, and strive to resolve them through discussion or by updating the draft.
Document: draft-ietf-isis-mi-06
Reviewer: Ross Callon
Review Date: September 6, 2012
Intended Status: Standards Track
Summary:
I have minor concerns about this document that I think should be resolved before publication.
Comments:
On the most part the document is well written and very readable, and is nearly ready for publication. I have one minor issue which should be resolved prior to publication, a question, and a few nits.
Major Issues:  None
Minor Issues:
I found the manner in which this document supports multi-topology routing within an single instance to be confusing and probably underspecified. The relationship with RFC 5120 is part of this issue. The text in section 1 was not particularly helpful and I had to read all of both documents to figure out what the relationship is - and am still not sure that I got it right.

Considering the following paragraphs from section 1:

   A given instance MAY support multiple topologies.  Each topology is
   associated with a unique LSDB and a topology specific IS-IS Update
   Process.  This differs from [RFC5120<http://tools.ietf.org/html/rfc5120>] where a single LSDB/single
   IS-IS Update Process is used in support of all topologies.

   MI-IS-IS might be used to support topology specific routing.  When
   used for this purpose it is an alternative to [RFC5120<http://tools.ietf.org/html/rfc5120>].

The second of these two paragraphs seems straightforward to understand: If you want to support multiple topologies, one option is to use a separate independent instance for each topology. This use case is explicitly described in section 3.1 and is intuitively straightforward.

The first of these two paragraphs is not clear. There is more description in sections 2.5, 3.2, 3.3, and 4 which help significantly. However, section 3 is "Usage Guidelines", and as such does not seem to be the right place to include a rigorous description of how flooding is to occur when multiple topologies are supported with a single instance (nor does it seem to contain a rigorous description).

This document does not claim to obsolete RFC 5120. Thus for the standard instance (#0) it would seem that the same approach defined in 5120 needs to be used without any change, at least for interoperability with older implementations that support 5120 and do not support this draft. This would seem to contradict the first paragraph above -- or at least require slightly different wording of this paragraph. The document should clearly state whether the standard instance (#0) uses the method in RFC 5120 for support of multiple topologies (which seems likely, for example since the IID-TLV's are not carried in the standard instance).

I think that this document should say up front (section 1) that it defines a new method for supporting multiple topologies, which can be done either within multiple instances or within a single instance -- it might also mention in section 1 that for backward compatibility the approach in  RFC 5120 is used in IID zero. It looks to me that section 2.5 could be enhanced to clarify operation when multiple topologies are supported within a single instance. It should clearly state whether any one LSP contains only information specific to a particular IID and ITID (this is my interpretation of the first sentence of 2.5).  I also infer from the first sentence of 2.5 that each LSP contains information for a single IID and a single ITID, encoded using the TLV defined in section 2.1, and the LSP is flooded only among routers that support that IID/ITID combination. Thus if I am reading this correctly then when occurring in an LSP the IID TLV MUST contain only one ITID value (although I also expect that some physical links may want to be shared by multiple topologies, and whether they have to be separately listed in multiple LSPs, one per topology, or if they could be described in a single LSP that is associated with multiple ITID's). I think that this needs to be made clearer.

Also a question: Section 2.6.1 describes the use of two new dedicated layer 2 multicast addresses:

   An MI-RTR will use two new (TBD) dedicated layer
   2 multicast addresses (one for each level) when sending IS-IS PDUs
   for any non-zero IID.

I am wondering whether or not this should be mentioned in the IANA section (it is not currently). This seems like something that someone needs to get assigned, but it is not obvious to me whether the IANA is involved in this.

Nits:
>> Last sentence of section 2.1:

   A PDU without an IID-TLV is assumed to belong to the standard
   instance (#0).

I don't think that "is assumed" is quite the right terminology. A PDU without an IID-TLV by definition does belong to the standard instance (#0). Thus, how about:

   A PDU without an IID-TLV belongs to the standard instance (#0).

>> section 2.6.1, first bullet item (describing PDUs that MUST be discarded):

  o  The destination multicast address is AllL1IS or AllL2IS and the
      PDU contains an IID-TLV

Elsewhere it says that the IID-TLV with a value of zero MUST NOT be included except as specified in this document. As such this comment is very minor: However, wouldn't it be more precise and/or more flexible for future extensions to reword this  bullet item as:

   o  The destination multicast address is AllL1IS or AllL2IS and the
      PDU contains an IID-TLV with a non-zero IID

---

From: "Les Ginsberg (ginsberg)" <[email-masked]>
Date: Mon, 10 Sep 2012 04:58:59 +0000

Ross -

Thank you for the review.

I will respond inline to each of your points below - however I want to preface my responses by saying that it concerns me that the document is not clear to you as regards multi-topology routing support and the relationship to RFC 5120. We tried in a number of ways to be clear about this (as I will point out below) - but given that you still are confused on some points it seems that we did not succeed. I therefore believe the text requires revision - though at this moment I am not certain as to what changes will resolve all the ambiguities that presented themselves to you. I hope you will work with us in trying to find better wording. I'll do my best to indicate below where I think rewording may help and where your help may be needed as I don't know what rewording will resolve the issues you raise.

Please see LES: inline.

From: Ross Callon [mailto:[email-masked]]
Sent: Thursday, September 06, 2012 9:36 PM
To: [email-masked]; Stefano Previdi (sprevidi); Les Ginsberg (ginsberg); [email-masked]; Abhay Roy (akr); David Ward (wardd)
Cc: [email-masked]; [email-masked]; Ross Callon
Subject: RtgDir review: draft-ietf-isis-mi-06

Hello,

LES: It is possible to create separate instances (i.e. unique IID values) on a per topology basis. In such a case each topology will have a 1-1 relationship with the instance,  will have a unique IID value, will have instance specific adjacencies, and an instance specific LSDB. However, it is also possible to support multiple topologies within a single non-zero instance. In this case a set of topologies share an instance specific adjacency (based on IID value) but do NOT share  the LSDB. The LSDB is scoped by the IID/ITID pair. This is the concept the first paragraph you quote above is introducing. Section 2 (third paragraph) goes on to state:

"MI-RTRs support the exchange of topology specific Link State PDUs for
   the IID/ITID pairs that each neighbor supports.  A unique IS-IS
   Update process [see IS-IS] operates for each IID/ITID pair."

I am not sure how to be more clear about this.

LES: Section 2 is intended to be the normative specification. Section 2.5 specifically  is the normative specification of how the Update process operates.
Section 3 is intended to clarify through discussion of some example use cases. Which is why the second paragraph of Section 3 states:

"The following sub-sections provide some guidelines for usage of
   instances and topologies within each instance.  While this represents
   examples based on the intent of the authors, implementors are not
   constrained by the examples."

I believe Section 2 to be complete - and Section 3 could be omitted entirely without loss of completeness. However, it was the consensus of the authors that Section 3 was needed to clarify how the protocol extensions might be used by way of examples.
I am not sure how to be more clear about this.

This document does not claim to obsolete RFC 5120.

LES: This is correct. RFC 5120 is not changed in any way by this document - nor do we propose that RFC 5120 should no longer be used/supported.

Thus for the standard instance (#0) it would seem that the same approach defined in 5120 needs to be used without any change, at least for interoperability with older implementations that support 5120 and do not support this draft. This would seem to contradict the first paragraph above -- or at least require slightly different wording of this paragraph. The document should clearly state whether the standard instance (#0) uses the method in RFC 5120 for support of multiple topologies (which seems likely, for example since the IID-TLV's are not carried in the standard instance).

LES: The standard instance is not changed in any way by this document. Indeed, it is not possible to do so without introducing backwards compatibility issues - which we have been careful to avoid. See Section 2.6. But I will try to make this more clear in the Introduction.

I think that this document should say up front (section 1) that it defines a new method for supporting multiple topologies, which can be done either within multiple instances or within a single instance -- it might also mention in section 1 that for backward compatibility the approach in  RFC 5120 is used in IID zero.

LES: This is NOT the intent of the document. The draft defines two new protocol capabilities:

1)Overcoming the existing limitation that one and only one instance of the protocol can be run on a given circuit.
2)Within a given non-zero(sic) instance support a topology specific update process.

The first of these two points is clearly stated in the Introduction. The second point I think is less clear - I will reword the introduction to make that point clearer.
But it is decidedly NOT our intent to suggest that RFC 5120 should be replaced.

It looks to me that section 2.5 could be enhanced to clarify operation when multiple topologies are supported within a single instance. It should clearly state whether any one LSP contains only information specific to a particular IID and ITID (this is my interpretation of the first sentence of 2.5).

I also infer from the first sentence of 2.5 that each LSP contains information for a single IID and a single ITID, encoded using the TLV defined in section 2.1, and the LSP is flooded only among routers that support that IID/ITID combination. Thus if I am reading this correctly then when occurring in an LSP the IID TLV MUST contain only one ITID value (although I also expect that some physical links may want to be shared by multiple topologies, and whether they have to be separately listed in multiple LSPs, one per topology, or if they could be described in a single LSP that is associated with multiple ITID's). I think that this needs to be made clearer.

LES:  Section 2 states

"  MI-RTRs support the exchange of topology specific Link State PDUs for
   the IID/ITID pairs that each neighbor supports.  A unique IS-IS
   Update process [see IS-IS] operates for each IID/ITID pair."

Section 2.1 states:

    "When the IID is non-zero and the TLV appears in an SNP or LSP,
     exactly one ITID MUST be present indicating the topology with
     which the PDU is associated."

Although this seems unambiguous to me and has language that specifically addresses the points you raise, your confusion suggests we need some rewording - but I am not sure how to be more clear.

LES: Yes - this issue came up during the IANA review. Our intention is to obtain the addresses from the IANA managed address space specified in RFC 5342. IANA has asked that we update the IANA section to reflect this - which we intend to do.

LES: OK

LES: No. The only exception to the rule that an instance #0 PDU NOT contain the IID-TLV is in the case of P2P IIHs as described in Section 2.6.2. As Section 2.6.1 is talking about operation on a broadcast circuit we are intentionally saying there MUST NOT be an IID-TLV at all (even w IID value #0) in such a PDU.

I will however make this more clear - especially in the context of P2P operation over broadcast media (RFC 5309).

   Les

---

From: Ross Callon <[email-masked]>
Date: Wed, 12 Sep 2012 13:37:19 -0400

Reading through your response, it looks to me that resolving my comments will require relatively few changes to the draft (and probably no substantial technical change), but might require several emails back and forth. Probably it is most productive to have this exchange of emails off-line, and then report the results to the larger lists.

I will therefore reply in detail to the authors, with the understanding that the three mailing lists CC'd above will need a summary of the results when we are done.

Thanks, Ross

From: Les Ginsberg (ginsberg) [mailto:[email-masked]]
Sent: Monday, September 10, 2012 12:59 AM
To: Ross Callon; [email-masked]; Stefano Previdi (sprevidi); [email-masked]; Abhay Roy (akr); David Ward (wardd)
Cc: [email-masked]; [email-masked]
Subject: RE: RtgDir review: draft-ietf-isis-mi-06

Ross -

Please see LES: inline.

From: Ross Callon [mailto:[email-masked]]
Sent: Thursday, September 06, 2012 9:36 PM
To: [email-masked]<mailto:[email-masked]>; Stefano Previdi (sprevidi); Les Ginsberg (ginsberg); [email-masked]<mailto:[email-masked]>; Abhay Roy (akr); David Ward (wardd)
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; Ross Callon
Subject: RtgDir review: draft-ietf-isis-mi-06

Hello,

LES:  Section 2 states

Section 2.1 states:

LES: OK

   Les

---

From: Ross Callon <[email-masked]>
Date: Sun, 16 Sep 2012 22:25:02 -0400

The -07 version of the draft (draft-ietf-isis-mi-07), which has just been posted, addresses to my satisfaction the issues and comments that I mentioned in my routing directorate review.

Thanks to the authors for quickly dealing with these.

Ross

From: [email-masked] [mailto:[email-masked]] On Behalf Of Ross Callon
Sent: Wednesday, September 12, 2012 1:37 PM
To: Les Ginsberg (ginsberg); Stefano Previdi (sprevidi); [email-masked]; Abhay Roy (akr); David Ward (wardd)
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: [RTG-DIR] RtgDir review: draft-ietf-isis-mi-06

Thanks, Ross

From: Les Ginsberg (ginsberg) [mailto:[email-masked]]
Sent: Monday, September 10, 2012 12:59 AM
To: Ross Callon; [email-masked]<mailto:[email-masked]>; Stefano Previdi (sprevidi); [email-masked]<mailto:[email-masked]>; Abhay Roy (akr); David Ward (wardd)
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: RE: RtgDir review: draft-ietf-isis-mi-06

Ross -

Please see LES: inline.

Hello,

LES:  Section 2 states

Section 2.1 states:

LES: OK

   Les