[RTG-DIR] RtgDir review: https://www.ietf.org/id/draft-ietf-mpls-spring-lsp-ping-06.txt

Antoni Przygienda <prz@juniper.net> Fri, 25 August 2017 00:07 UTC

From: Antoni Przygienda <prz@juniper.net>
To: "rtg-ads@ietf.org" <rtg-ads@ietf.org>
CC: "rtg-dir@ietf.org" <rtg-dir@ietf.org>, "draft-ietf-mpls-spring-lsp-ping.all@ietf.org" <draft-ietf-mpls-spring-lsp-ping.all@ietf.org>
Thread-Topic: RtgDir review: https://www.ietf.org/id/draft-ietf-mpls-spring-lsp-ping-06.txt
Thread-Index: AQHTHKjgJn8SjDBg/UO3z7edS1wbNg==
Date: Fri, 25 Aug 2017 00:06:40 +0000
Message-ID: <12A8D2A7-3B83-4D4D-A0BC-7086DAB33D54@juniper.net>
Accept-Language: en-US
Content-Language: en-US
user-agent: Microsoft-MacOutlook/f.20.0.170309
received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts)
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_12A8D2A73B834D4DA0BC7086DAB33D54junipernet_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-originalarrivaltime: 25 Aug 2017 00:06:40.5991 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM2PR0501MB1261
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtg-dir/e8rKninzDLZY7VO01CksPRx57tY>
Subject: [RTG-DIR] RtgDir review: https://www.ietf.org/id/draft-ietf-mpls-spring-lsp-ping-06.txt
X-BeenThere: rtg-dir@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Routing Area Directorate <rtg-dir.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtg-dir>, <mailto:rtg-dir-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rtg-dir/>
List-Post: <mailto:rtg-dir@ietf.org>
List-Help: <mailto:rtg-dir-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtg-dir>, <mailto:rtg-dir-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 25 Aug 2017 00:07:06 -0000

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://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir<http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir>
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: https://www.ietf.org/id/draft-ietf-mpls-spring-lsp-ping-06.txt
Reviewer: Tony Przygienda
Review Date: 08/17
Intended Status: Standards Track
Summary:

I have significant concerns about this document and recommend that the Routing ADs discuss these issues further with the authors. Overall, I think that both the quality as well as scope of the draft seems rushed to LC and at a deeper level, SR IMO maybe not in a state yet to deliver a complete, standards-track RFC for the scope the draft claims to cover unless its breadth gets heavily curtailed.

As note of caution: I’m not traditionally a MPLS/SR dataplane deep subject matter expert so I basically looked over the architectural integrity first and then read up enough detail to be fairly sure I make sense. Nevertheless, some of my comments may be off mark obviously.

Comments:

  *   The name of the draft implies a scope which it covers to a small degree only
  *   The draft feels somewhat rushed, contains numerous spelling mistakes, partial and mis-numbered references. It omits good amount of text that is necessary for a standards track spec in terms of being normative (missing capitalization, error conditions/mis-formatted input etc).
  *   I recommend to send the draft back to the WG until the according SIDs are mentioned/treated/stabilized to the point where it truly is a “SPRING LSP Ping” or otherwise rename the draft/RFC as “LSP Ping for IGP Prefix/adjacency SIDs” and address the comments pertaining to this scope
Major Issues:

·         While claiming that it’s “LSP Ping/Trace for SPRING” the document does not mention many types of SIDs already defined today and/or does not differentiate enough between them

o    LAN adjacency SIDs (either that needs to be differentiated from adjacency SIDs or explained why it’s not necessary)

o    Binding SIDs

o    anycast SIDs

o    EPE SIDs

o    Mirroring SIDs?

o    possibly topology SIDs

o    in section 5.3 we have an assumption that GMPLS is running to support unnumbered links (4302)? How does that play with rfc3630 and incoming draft-ietf-ospf-lls-interface-id-00 identifiers.

o    we have Prefix Range in IGPs and the question is, should that be considered a special sub-type on LSP Ping Downstream mapping TLV?

o    How is the draft dealing with “controller installed SIDs”, how is that treated?

·         Generally, I think it may be premature to publish the draft before the “SID types” have settled to a certain degree or otherwise it has to be renamed and address a much reduced scope.


Minor Issues:

·         “It may simplify implementations to reuse Implicit Null for Node Segment ID PHP and Adjacency Segment ID cases.”  What is this saying? This is not normative, does not explain how it can be done and whether a node encountering Implicit NULL for the SIDs does consider it an error, a correct “smart” implementation or anything else? Am I missing something?

·         Section 5.1 (and many other sections defining formats): No error condition treatements are specified anywhere. What happens if e.g. another value than 0,1,2 is received in the protocol field?
Nits:

·         Misspelled “supports hierarchal”

·         “is not hop-by-hop always” is awkward English ;-)

·         correction “the assignment can be unique to the node or within _a_ domain.”. We have multiple possible domains in SR (AD, area, mapping server tie-breaks)

·         “illustrates the problem and describe_s_ a mechanism”

·          “that is used to distribute a specific a label.” does not parse

·         “regardless of if PHP” would be better as e.g. “regardless whether”

·         “Adjacency Segment ID represents parallel adjacencies (Section 3.5.1 of [I-D.ietf-spring-segment-routing])”. In fact, section 3.5.1 deals with mapping server? 3.4.1 maybe?

·         “of &pop& operation” ?

·         “it can be thought _of_ as _a_ next hop destined _to a_ ? locally allocated segment that has PHP enabled.”

·         “When Protocol is OSPF, NP-flag defined in Section 5 of [I-D.ietf-ospf-segment-routing-extensions] should be set to 0.”. Probably MUST and in good couple of other places where normative language is not capitalized and an error on violation is implied by the section above.

[RTG-DIR] RtgDir review: https://www.ietf.org/id/… Antoni Przygienda
Re: [RTG-DIR] RtgDir review: https://www.ietf.org… Carlos Pignataro (cpignata)
Re: [RTG-DIR] RtgDir review: https://www.ietf.org… Antoni Przygienda
Re: [RTG-DIR] RtgDir review: https://www.ietf.org… Carlos Pignataro (cpignata)
Re: [RTG-DIR] RtgDir review: https://www.ietf.org… Antoni Przygienda
Re: [RTG-DIR] RtgDir review: https://www.ietf.org… BRUNGARD, DEBORAH A
Re: [RTG-DIR] RtgDir review: https://www.ietf.org… Antoni Przygienda