Re: [mpls] [spring] RtgDir review:

"Nagendra Kumar Nainar (naikumar)" <> Wed, 20 September 2017 22:41 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 61111132397; Wed, 20 Sep 2017 15:41:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -14.52
X-Spam-Status: No, score=-14.52 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 2BR_jUlYvpXI; Wed, 20 Sep 2017 15:41:52 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id D6D721243F6; Wed, 20 Sep 2017 15:41:51 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=47850; q=dns/txt; s=iport; t=1505947311; x=1507156911; h=from:to:cc:subject:date:message-id:mime-version; bh=VYFe2iCydhnxmG6vXI7TTYPAJ/cp8hlfErRuHVwhStY=; b=SHTKfNfRAEKlWsJQNnsayyrLCG0O9uOqDIIG/lmb6nP8Sq/+sFh/GMR8 HjdTHRKGf76BlYbpcHd/UK+/Y9dgmjQJ2g2UQtJ8RnvJzD2Bi73xPL0Zv sX1ZvtfhXe2pt5Yr+lrMIpmcegWCGXs5WlhJtH+O2DB6CEPDG9nCwX5rO c=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos; i="5.42,422,1500940800"; d="scan'208,217"; a="80030055"
Received: from ([]) by with ESMTP/TLS/DHE-RSA-AES256-SHA; 20 Sep 2017 22:41:20 +0000
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id v8KMfKoT029724 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Wed, 20 Sep 2017 22:41:20 GMT
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.1263.5; Wed, 20 Sep 2017 17:41:19 -0500
Received: from ([]) by ([]) with mapi id 15.00.1263.000; Wed, 20 Sep 2017 17:41:19 -0500
From: "Nagendra Kumar Nainar (naikumar)" <>
To: Alexander Vainshtein <>, "" <>
CC: "Jonathan Hardwick (" <>, "" <>, "" <>, "" <>, "" <>
Thread-Topic: [spring] RtgDir review:
Thread-Index: AQHTMmGTKrYHjrFRHE+7WhCrFfdLIQ==
Date: Wed, 20 Sep 2017 22:41:19 +0000
Message-ID: <>
Accept-Language: en-US
Content-Language: en-US
user-agent: Microsoft-MacOutlook/f.25.0.170815
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_DBE838B231464EDD8A276B06A7C0C3EDciscocom_"
MIME-Version: 1.0
Archived-At: <>
Subject: Re: [mpls] [spring] RtgDir review:
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Multi-Protocol Label Switching WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 20 Sep 2017 22:41:55 -0000

Hi Sasha,

Thanks for the comments. Please see below:

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 ​

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.


Reviewer: Alexander (“Sasha”) Vainshtein

Review date: 20.09.2017

IETF LC End Date: Not known

Intended status: Standards Track


I have significant concerns about this document and recommend that the Routing ADs discuss these issues further with the authors.


I have noticed that there is an earlier review of the same version of  the draft<>, and I fully agree with the previous reviewer regarding the overall impression and specific issues raised. I have tried to avoid reporting the same issues again and focus only on new issues.

This review have been done on a very tight schedule for me, and therefore I could have missed some issues and definitely many nits. The tight schedule has also limited my ability to discuss the draft with the authors in sufficient detail – but some interactions did took place. I would like to thank the authors for their cooperation.

Major Issues:

  1.  Section 7.4 “Segment ID Check” of the draft claims to update “the procedure defined in Step 6 of Section 4.4  of [RFC8029]”. However, I have failed to integrate the logic defined by the pseudocode in this section with the logic defined by the referenced pseudocode.
     *   I have suspected that the newly introduced logic should be part of the Egress FEC Validation logic defined in Section 4.4.1 of RFC 8029.  This suspicion has been acknowledged by the authors, and they plan to fix the wrong reference in the next revision of the draft.
<Nagendra> We have this addressed in the new revision. We have updated the section as 4.4.1.

     *   From my POV the best way to avoid possible misinterpretation by the implementers would be inclusion of the updated version of the pseudocode (with explicit marking of the new logic) directly in the document. I have suggested this to the authors, but I did not get their response so far.
<Nagendra> We addressed this one as well. We included the modified/updated version of Step 4 (from RFC 8029) and continued the procedure as Step 4a.

  1.  I agree with the previous reviewer regarding the mismatch between the (presumed) claim and the actual scope covered by the draft. To the best of my understanding, the authors have already agreed to fix this in the next revision of the draft.

<Nagendra> We changed the title to reflect the scope appropriately.

Minor Issues:

  1.  I wonder why the authors place such an emphasis on Service labels (which, AFAIK, have not been defined in any level of detail anywhere so far) – these labels are mentioned in Sections 4.2, 5 (that mentions them as “Service segments”)  and 8, while so many types of Segment IDs that are already well defined both in the SRPING WG documents and in the extensions of the relevant routing protocols are left out of scope of the draft.  The authors have acknowledged this and plan to fix this issue (probably by removing the Service labels completely).
<Nagendra> As we discussed offline, this section was included as part of the merge of the two individual drafts. To avoid any confusion and stay within the scope of this draft, we removed any discussion about service label/segment.

  1.  The description of possible data plane malfunctions in section 4.1 seems to assume that all the nodes in the referenced topology (shown in Figure 1) us the same SRGB. If this assumption (which is not explicitly mentioned) is not correct, the LSP Ping Echo request packets would not be “delivered to their expected destinations but not via the expected path” (as the text in this section claims). I suggest making any such assumptions explicit in the text

<Nagendra> Does the below updated text clarifies?:

                   Assume in above topology, R1 sends traffic with segment stack as
   {9124, 5008} so that the path taken will be R1-R2-R4-R5-R7-R8.  If
   the Adjacency Segment ID 9124 is misprogrammed in R2 to send the
   packet to R1 or R3, it will still be delivered to R8 but is not via
   the expected path.

                   Assume in above topology, R1 sends traffic with segment stack as
   {9124, 5008} so that the path taken will be R1-R2-R4-R5-R7-R8.  If
   the Adjacency Segment ID 9124 is misprogrammed in R2 to forward the
   packet to R1 or R3, the packet may still be delivered to R8 (if the nodes are
 configured with same SRGB)but is not via the expected path.

  1.   I am not sure if “OSPF” and ISIS” (without any reference to Segment Routing) are the proper names for the label distribution protocols in the proposed new IANA registry in Section 10.2. From my POV “OSPF/ISIS SR Extensions” would be more appropriate. The authors disagree with this proposal claiming that OSPF and ISIS are not used for label distribution in any other way. (RFC 8029 that encodes the label distribution protocol in the Downstream  Detailed Mapping TLV did not request a dedicated registry for this purpose, and I think that the authors have been right to request such a registry).
<Nagendra> As we discussed, we are not aware of the use of OSPF/ISIS for label distribution other than SR. I am not sure if there is a need to differentiate BGP as signaling protocol for RFC3107 vs ePE. We may need to guage it and update protocol BGP if required. If the WG and/or AD is favor of renaming it as “OSPF/ISIS SR Extensions”, we can definitely update it accordingly.

  1.  I doubt the draft needs address any FRR issues even in future (as mentioned in the last statement in Section 5), since, to the best of my understanding, any form of FRR:
     *   Is operated locally by the node that is upstream to the failure without passing any information to the initiator of LSP-Ping Request packets
     *   In any case is just a transient state in the (presumably short) interval between the failure being detected by the upstream node and re-convergence of IGP

<Nagendra> Any discussion related to FRR has been removed already.

I also think that references to “future versions” are not quite appropriate in the document that is going to the IETF LC. I recommend removing any such references from the document,

<Nagendra> Service segment is the one which has some reference to future versions or document. With the updated revision, we cleared all references to any future versions.

  1.  Section 9 “Backward Compatibility with non-Segment Routing devices” defines the behavior for the two slightly different use cases:
     *   LSP Ping Echo Request packets are initiated by an SR-capable node (and therefore their target FEC stack contains SR-related FECs), while the responder is legacy device that is not SR-capable. In this case the proposed solution (respond with the FEC-return-code “Replying router has no mapping for the FEC at stack-depth”) looks as the only possibility since the legacy device cannot parse SR FECs in any case
     *   LSP Ping Echo Request packets are initiated by a legacy device while the responder is SR-capable. The draft defines the same behavior in this case – but, IMHO and FWIW, the responder could provide slightly better diagnostics since it can parse the “old” target FEC and recognize the equivalent Node ID. An additional return code would be required to implement this behavior.

<Nagendra> In this case, I believe the legacy node (Initiator) will not be able to parse the new return code received. I am not sure if it will be helpful.

This issue has not been discussed with the authors due to lack of time.

  1.  The note to the RFC Editor in Section 10 mentions early IANA allocation for some Sub-TLV types defined in the document – but, as of today, these early allocations have already expired (they have been in force until 15.09.17).  I have to admit that I do not fully understand the implications of this fact – e.g., whether the authors may continue to refer to the specific values of parameters (e.g., Sub-TLV 34, 35 etc.) for which early IANA allocation has expired, or should use some other form of reference (e.g., TBDx).

<Nagendra> Loa and Amanda helped us to renew this allocation for another year. So I think the allocated value is valid for another year.

  1.  The draft mentions a TBD7 value to be assigned by IANA, but there are no TBD1, …, TBD6. The authors have acknowledged this and plan to fix it. However, I do not know how this can be affected by expiration of early IANA allocations (see above)
<Nagendra> We changed this one to TBD1 ☺

  1.  I have failed to understand the intention of the authors regarding already mentioned Service labels from the following statement in section 8: “How a node treats Service label is outside the scope of this document and will be included in this or a different document later”. Of course, if the Service labels are removed from the draft, this sentence would hopefully disappear with its internal controversy.

 <Nagendra>  As mentioned earlier, this section and any related discussion about service segment has been removed ☺.

Once again, thanks a lot for the thorough review and comments.



Office: +972-3926302
Cell:      +972-549266302


This e-mail message is intended for the recipient only and contains information which is
CONFIDENTIAL and which may be proprietary to ECI Telecom. If you have received this
transmission in error, please inform us by e-mail, phone or fax, and then delete the original
and all copies thereof.