Re: [mpls] MPLS-RT review of draft-kumarkini-mpls-spring-lsp-ping

"Nagendra Kumar Nainar (naikumar)" <naikumar@cisco.com> Thu, 04 February 2016 03:54 UTC

Return-Path: <naikumar@cisco.com>
X-Original-To: mpls@ietfa.amsl.com
Delivered-To: mpls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8D8AB1B3933 for <mpls@ietfa.amsl.com>; Wed, 3 Feb 2016 19:54:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.501
X-Spam-Level:
X-Spam-Status: No, score=-14.501 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, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PeNmiZqYyj7s for <mpls@ietfa.amsl.com>; Wed, 3 Feb 2016 19:54:07 -0800 (PST)
Received: from alln-iport-6.cisco.com (alln-iport-6.cisco.com [173.37.142.93]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 401301B3934 for <mpls@ietf.org>; Wed, 3 Feb 2016 19:54:07 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=76899; q=dns/txt; s=iport; t=1454558047; x=1455767647; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=R/I6/1THmlb97v07fHH2rn4oTlF3xI5OoTZQLQ3Z73Q=; b=fcEgNTsRqrEE11ZTwwpNgAV+oZjKpTy1TjZY5T0uPT2uxaCIAcuIEn4I O6xs2vEupK2VhCMWViX/X+RfMmMApHueP/t6XawaMatVyUvlKv8YP3Lde pHsJ+OTBRyaWQ7k+1MWLVbzSYHSRIP9VY8kkM2B00xElxnarf7StA2Hhy Y=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0AEAgDwyrJW/5tdJa1egm5MUm0GhTiDH?= =?us-ascii?q?bEEAQ2BZiGEFYFXAoFFOBQBAQEBAQEBgQqEQQEBAQQaAQwGOgQODAICAgEIEQM?= =?us-ascii?q?BAQEhAQYHGwYRFAkIAgQBDQWIBgMSDrwgDYQ/AQEBAQEBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBEQQEiUp7gjeBQgkQAgEiAQcTDQuEAgWHUAOHAYQYhAUBhUiGEYFzgVuEQoh?= =?us-ascii?q?UhXCBD4Nvg1EBHgEBQoIDGYFIagGIMQIFGQcWfAEBAQ?=
X-IronPort-AV: E=Sophos;i="5.22,393,1449532800"; d="scan'208,217";a="234657087"
Received: from rcdn-core-4.cisco.com ([173.37.93.155]) by alln-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 04 Feb 2016 03:54:05 +0000
Received: from XCH-ALN-011.cisco.com (xch-aln-011.cisco.com [173.36.7.21]) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id u143s5Yi011321 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 4 Feb 2016 03:54:05 GMT
Received: from xch-aln-015.cisco.com (173.36.7.25) by XCH-ALN-011.cisco.com (173.36.7.21) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Wed, 3 Feb 2016 21:54:04 -0600
Received: from xch-aln-015.cisco.com ([173.36.7.25]) by XCH-ALN-015.cisco.com ([173.36.7.25]) with mapi id 15.00.1104.009; Wed, 3 Feb 2016 21:54:04 -0600
From: "Nagendra Kumar Nainar (naikumar)" <naikumar@cisco.com>
To: "Dutta, Pranjal K (Pranjal)" <pranjal.dutta@alcatel-lucent.com>, "Loa Andersson" <loa@pi.nu>, Curtis Villamizar <curtis@occnc.com>, "vishwas.manral@gmail.com" <vishwas.manral@gmail.com>, Lizhong Jin <lizho.jin@gmail.com>, "draft-kumarkini-mpls-spring-lsp-ping@tools.ietf.org" <draft-kumarkini-mpls-spring-lsp-ping@tools.ietf.org>, "mpls-chairs@tools.ietf.org" <mpls-chairs@tools.ietf.org>
Thread-Topic: MPLS-RT review of draft-kumarkini-mpls-spring-lsp-ping
Thread-Index: AQHQ6uZThyQvT/8dOEmUFCIze73HOJ5OavkAgM3PW4A=
Date: Thu, 4 Feb 2016 03:54:04 +0000
Message-ID: <D2D8352E.E2185%naikumar@cisco.com>
References: <55F0006E.2000906@pi.nu> <55F00321.2070602@pi.nu> <ABD110CD5D879A4BB51C269846E4CA3128C9CB@SG70YWXCHMBA08.zap.alcatel-lucent.com>
In-Reply-To: <ABD110CD5D879A4BB51C269846E4CA3128C9CB@SG70YWXCHMBA08.zap.alcatel-lucent.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/14.5.7.151005
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.82.252.75]
Content-Type: multipart/alternative; boundary="_000_D2D8352EE2185naikumarciscocom_"
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/mpls/ChsocZcytRR0DqYCNB_Y9soH_5w>
Cc: "mpls@ietf.org" <mpls@ietf.org>
Subject: Re: [mpls] MPLS-RT review of draft-kumarkini-mpls-spring-lsp-ping
X-BeenThere: mpls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Multi-Protocol Label Switching WG <mpls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mpls>, <mailto:mpls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/mpls/>
List-Post: <mailto:mpls@ietf.org>
List-Help: <mailto:mpls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mpls>, <mailto:mpls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 04 Feb 2016 03:54:14 -0000

Hi Pranjal,

Thanks for the comments. Apologies for the delayed response.

Please see below for the response:

“
1.      Section 4.1 on the problem definition: This section falls short of discussing various critical fault scenarios in detail.

For example, following is an important case.


                  +--------+
                  |   L2   |
                  R3-------R6
                 /           \
                /             \
        R1----R2               R7----R8
                \             /
                 \           /
                  R4-------R5

    9136 --> Adjacency Segment ID from R3 to R6 over link L1.
    9236 --> Adjacency Segment ID from R3 to R6 over link L2.
    9124 --> Adjacency segment ID from R2 to R4.
    9123 --> Adjacency Segment ID from R2 to R3.
    9145 --> Adjacency Segment ID from R4 to R5.
    9157 --> Adjacency segment ID from R5 to R7.
    9178 --> Adjacency segment ID from R7 to R8.
    9167 --> Adjacency segment ID from R6 to R7.

Let's say R1 originates a packet with the following label stack:

   9123 + 9136 + 9167 + 9178 + Payload

   R2 pops Adjacency Segment ID 9123 and forwards the packet to the correct next-hop link R2-R3. But R2 is malfunctioning such that it also pops 9136.
   Thus R3 receives the Adjacency Segment ID 9167. By quirk of fate Label/9167 = label/9236 because both labels are locally significant to advertising nodes.
   As a result, R3 forwards the packet to R6 over link L2. R6 receives 9178 and drops the packet after finding no state programmed for 9178. The packet
   traverses the intended path till R6 whereas the problem is at R2.

   Similarly, instead of POPPing unwanted labels the malfunctioning node could PUSH unwanted labels. Such issues may not be due to wrong programming by control plane (or data
   plane out of sync) and can happen due to a few bit flips on faulty h/w or memory.

<Authors> Right. There are various such possibilities. We thought of highlighting the commonly seen issue to justify the basic reason for this document/mechanism. If the WG is in favor of including more issues (or the above issues), we are fine to include the same.

</Authors>

2.      Sections 5.1 and 5.2: the target FEC stack TLV for a prefix SID MUST include the SID index value and not just the address to be sure this gets checked for overlaps or errors of assigning the SID index value.

<Authors> From different discussion with co-authors and others, the existing information in TLV is sufficient to detect any overlaps. Further overlap/duplicate SID Index will be detected by COntrol plane and such prefixes (and so the segment/label) will not be installed in forwarding table. Let us know if there is any scenario where SID Index is mandatory to detect any issues.  Carrying this Prefix SID in TFS and use Stack-R will be redundant. We initially had in earlier revision and removed it for this reason. Please let us know if we are missing any need to carry it in TFS.
</Authors>


3.      Section 6: The DSMAP should not be supported with SR and SR-TE LSP. The DDMAP is required because of the hierarchical nature of the LSP. See next comment for more details.

<Authors> Yes. Agreed. RFC6424 already deprecates DSMAP. We will update the draft with DDMAP in relevant sections.

4.      Section 7.1: I think what is missing upfront in the document is the modeling in MPLS OAM of a SR or SR-TE LSP. Basically, it should be modeled as a hierarchical LSP which MUST use the DDMAP TLV with the FEC Stack Change sub-TLV to operate correctly. The following operations are supported:

<Authors>SR LSP (following shortest path) can be considered as traditional LSP while SR-TE could be hierarchical or stitching or a combination of both. Irrespective of SR LSP or SR-TE LSP, ping will expect to have the destination FEC and trace should carry all FEC in TFS. We highlighted this in section 7.1 and highlighted the procedure on how to handle stack change in section 7.2
</Authors>

a.       A node/prefix SID label that is swapped at an LSR results in the normal return code of 8  "Label switched at stack-depth <RSC>" as per RFC 4379.
b.      A node/prefix SID label which is popped at an LSR results in a FEC stack change TLV operation of “POP” as per RFC 6424.
c.       An adjacency SID label popped at an LSR results in a FEC stack change TLV operation of “POP” as per RFC 6424. In other words, we are modeling the swap operation into a implicit NULL label as a POP to simplify the tracing operation with DDMAP.

<Authors>We already include the below in Introduction section:

""Detecting Multi-Protocol Label Switched (MPLS) Data Plane Failures"
   [RFC4379] defines a simple and efficient mechanism to detect data
   plane failures in Label Switched Paths (LSP) by specifying
   information to be carried in an MPLS "echo request" and "echo reply"
   for the purposes of fault detection and isolation.  Mechanisms for
   reliably sending the echo reply are defined.  The functionality
   defined in [RFC4379]is modeled after the ping/traceroute paradigm
   (ICMP echo request [RFC0792]) and is typically referred to as LSP
   ping and LSP traceroute.  [RFC6424] updates [RFC4379] to support
   hierarchal and stitching LSPs.
"

So I think, it might be repetitive to add the same again?.

</Authors>

5.      Section 7.1: The text under paragraph titled “Traceroute” is very ambiguous and confusing and it may suggest that new behavior is being described. In fact, there is nothing new to add here and the behavior of the FEC stack change sub-TLV is as per RFC 6424. All what is needed is a clear description of the modeling of the SR/SR-TE LSP as per comment above.

  For example, let's apply the procedures in this section to the fault scenario I had discussed in comment 1).

  5.1. R1 initiates Echo Request with TTL=1 carrying Targeted FEC stack 9123 + 9136 + 9167 + 9178. From the procedures it is not clear  whether R1 would send DSMAP/DDMAP TLV
         containing the Label stack. IMO, it MUST send Label stack - without it R2 can't validate if received data plane label stack is same as in received DSMAP/DDMAP (see later in 5.5).

  5.2  R2 responds with Echo reply containing FEC stack change/pop for 9123.

  5.3. R1 initiates Echo Request with TTL=2 carrying Targeted FEC stack 9136 + 9167 + 9178 and DSMAP/DDMAP containing corresponding label stack
       9136 + 9167 + 9178. The data plane label stack is 9123 + 9136 + 9167 + 9178.

  5.4. The malfunctioning node R2 forwards the packet to R3 with data-plane label stack 9167 + 9178.

  5.5. R3 validates from received Targeted FEC stack that 9136 is the indeed an advertised Adjacency ID and corresponding label in DSMAP/DDMAP is correct. However the label stack
          received in data plane does not correspond to the label stack in DSMAP - this is a key point and there is no mention of it in the draft. Thus R3 responds with label_stack_validation
         failure which indicates a data plane fault in R2.

<Author>Yes. We agree that the traceroute section is not new. We got a similar comment from other reviewer as well. We modified it as below:

"As defined in section 4.3.1.2 of RFC6424, When a received echo reply
contains FEC Stack Change TLV with one or more of original segment(s)
 being popped, initiator MAY remove corresponding FEC(s) from Target
FEC Stack TLV in the next (TTL+1) traceroute request."


Will this be ok?.

</Author>

6.      Section 7.2: the popping of the adjacency SID label is performed by the node which assigned it and it is this node which generates the FEC stack change sub-TLV with the operation of POP.

<Authors> We had this explicitly defined this way. If the node assigning the adjacency SID will signal teh POP stack change TLV, the downstream will not have any FEC to validate if it is the right downstream node.

7.      Section 7.3: while I agree that the implicit NULL label value for the adjacency SID should not be used because the downstream LSR has no context for the adjacency SID of his upstream neighbor (adjacency SIDs are locally significant only) but for node SID with PHP, the downstream node has context and actually signaled PHP flag in the prefix SID sub-TLV. Implicit-Null value is thus valid for node SID.

<Authors> Reading RFC4379, section 3.3, I think it is reasonable to include imp-null for Node SID. We got a similar comment from other reviewers. Accordingly, we will remove this sentence. The modified one will be as below:

"The forwarding semantic of Node Segment ID with PHP flag is
equivalent to usage of implicit Null in MPLS protocols. Adjacency
Segment ID is also similar in a sense that it can be thought as next
hop destined locally allocated segment that has PHP enabled.
Procedures described in Section 4.4 of [RFC4379] <https://tools.ietf.org/html/rfc4379#section-4.4> relies on Stack-D
and Stack-R explicitly having Implicit Null value. It may simplify
implementations to reuse Implicit Null for Node Segment ID PHP and
Adjacency Segment ID cases.”

8.      Section 7.4: This section needs to be written to cover the cases of regular swapping of node/prefix SID and the popping of node SID or adjacency SID when receiving the FEC stack change sub-TLV. Also, what is exactly “Best return code to 10”?

<Authors>This section is basically an extension of FEC Validation (section 4.4 of RFC4379). The other procedure of handling during swap operation is same as defined in RFC4379. One of the comment from other review mail is to include a point highlighting that this updates section 4.4 of RFC4379. Accordingly we will be including the below:

7.4.  Segment ID Check

This section updates the procedure defined in Step 6 of Section 4.4 of [RFC4379].
"

Let us know if this is fine. THis will help avoid redundant information that is already available in RFC4379.

9.      Section 7.5: I do not think this section belongs here. If there are recommendations for TTL setting for hierarchical LSPs, they sure are not specific to SR/SR-TE LSP.

<Authors>Since hierarchical LSP is defined in RFC6424, should we update that this draft will update RFC6424 as well?. Will it help to retain this section here?.
</Authors>

10.  In Section 5

“Three new sub-TLVs are defined for TLVs type 1, 16 and 21.”
It is not clear what is meant by TLVs type 1,16 and 21. Suggest to make explicit references.

<Authors>Ok. This has been modified as below:

"
Three new sub-TLVs are defined for Target FEC Stack TLVs (Type 1),
Reverse-Path Target FEC Stack TLV (Type 16) and Reply Path TLV (Type 21).
"
Is the above fine?.
</Authors>

11. One missing point in MPLS-OAM so far is to let the originator of a Traceroute know that responding node is currently exercising FRR backup next-hop (because primary has failed).
     AFAIK, this is not covered in any MPLS OAM extensions so far. It is good to address this in SR context.

 <Author> Yes. This point was raised by Nobo earlier, but as you rightly mentioned, this is not specific to SR or this document. THis might need to be addressed in a different document.
 </Author>
“

Thanks,
Nagendra (for authors)


From: "Dutta, Pranjal K (Pranjal)" <pranjal.dutta@alcatel-lucent.com<mailto:pranjal.dutta@alcatel-lucent.com>>
Date: Friday, September 25, 2015 at 7:58 PM
To: Loa Andersson <loa@pi.nu<mailto:loa@pi.nu>>, Curtis Villamizar <curtis@occnc.com<mailto:curtis@occnc.com>>, "vishwas.manral@gmail.com<mailto:vishwas.manral@gmail.com>" <vishwas.manral@gmail.com<mailto:vishwas.manral@gmail.com>>, Lizhong Jin <lizho.jin@gmail.com<mailto:lizho.jin@gmail.com>>, "draft-kumarkini-mpls-spring-lsp-ping@tools.ietf.org<mailto:draft-kumarkini-mpls-spring-lsp-ping@tools.ietf.org>" <draft-kumarkini-mpls-spring-lsp-ping@tools.ietf.org<mailto:draft-kumarkini-mpls-spring-lsp-ping@tools.ietf.org>>, "mpls-chairs@tools.ietf.org<mailto:mpls-chairs@tools.ietf.org>" <mpls-chairs@tools.ietf.org<mailto:mpls-chairs@tools.ietf.org>>
Cc: "mpls@ietf.org<mailto:mpls@ietf.org>" <mpls@ietf.org<mailto:mpls@ietf.org>>
Subject: RE: MPLS-RT review of draft-kumarkini-mpls-spring-lsp-ping
Resent-From: <pranjal.dutta@alcatel-lucent.com<mailto:pranjal.dutta@alcatel-lucent.com>>
Resent-To: <draft-kumarkini-mpls-spring-lsp-ping@ietf.org<mailto:draft-kumarkini-mpls-spring-lsp-ping@ietf.org>>, <mpls-chairs@ietf.org<mailto:mpls-chairs@ietf.org>>
Resent-Date: Friday, September 25, 2015 at 7:58 PM


Hi,

     I have been asked by the WG chairs for MPLS-RT review on this draft. I have reviewed the version  https://tools.ietf.org/html/draft-kumarkini-mpls-spring-lsp-ping-04 and following are my review comments.



1.      Section 4.1 on the problem definition: This section falls short of discussing various critical fault scenarios in detail.



For example, following is an important case.





                  +--------+

                  |   L2   |

                  R3-------R6

                 /           \

                /             \

        R1----R2               R7----R8

                \             /

                 \           /

                  R4-------R5



    9136 --> Adjacency Segment ID from R3 to R6 over link L1.

    9236 --> Adjacency Segment ID from R3 to R6 over link L2.

    9124 --> Adjacency segment ID from R2 to R4.

    9123 --> Adjacency Segment ID from R2 to R3.

    9145 --> Adjacency Segment ID from R4 to R5.

    9157 --> Adjacency segment ID from R5 to R7.

    9178 --> Adjacency segment ID from R7 to R8.

    9167 --> Adjacency segment ID from R6 to R7.



Let's say R1 originates a packet with the following label stack:



   9123 + 9136 + 9167 + 9178 + Payload



   R2 pops Adjacency Segment ID 9123 and forwards the packet to the correct next-hop link R2-R3. But R2 is malfunctioning such that it also pops 9136.

   Thus R3 receives the Adjacency Segment ID 9167. By quirk of fate Label/9167 = label/9236 because both labels are locally significant to advertising nodes.

   As a result, R3 forwards the packet to R6 over link L2. R6 receives 9178 and drops the packet after finding no state programmed for 9178. The packet

   traverses the intended path till R6 whereas the problem is at R2.



   Similarly, instead of POPPing unwanted labels the malfunctioning node could PUSH unwanted labels. Such issues may not be due to wrong programming by control plane (or data
   plane out of sync) and can happen due to a few bit flips on faulty h/w or memory.



2.      Sections 5.1 and 5.2: the target FEC stack TLV for a prefix SID MUST include the SID index value and not just the address to be sure this gets checked for overlaps or errors of assigning the SID index value.



3.      Section 6: The DSMAP should not be supported with SR and SR-TE LSP. The DDMAP is required because of the hierarchical nature of the LSP. See next comment for more details.



4.      Section 7.1: I think what is missing upfront in the document is the modeling in MPLS OAM of a SR or SR-TE LSP. Basically, it should be modeled as a hierarchical LSP which MUST use the DDMAP TLV with the FEC Stack Change sub-TLV to operate correctly. The following operations are supported:



a.       A node/prefix SID label that is swapped at an LSR results in the normal return code of 8  "Label switched at stack-depth <RSC>" as per RFC 4379.

b.      A node/prefix SID label which is popped at an LSR results in a FEC stack change TLV operation of “POP” as per RFC 6424.

c.       An adjacency SID label popped at an LSR results in a FEC stack change TLV operation of “POP” as per RFC 6424. In other words, we are modeling the swap operation into a implicit NULL label as a POP to simplify the tracing operation with DDMAP.



5.      Section 7.1: The text under paragraph titled “Traceroute” is very ambiguous and confusing and it may suggest that new behavior is being described. In fact, there is nothing new to add here and the behavior of the FEC stack change sub-TLV is as per RFC 6424. All what is needed is a clear description of the modeling of the SR/SR-TE LSP as per comment above.



  For example, let's apply the procedures in this section to the fault scenario I had discussed in comment 1).



  5.1. R1 initiates Echo Request with TTL=1 carrying Targeted FEC stack 9123 + 9136 + 9167 + 9178. From the procedures it is not clear  whether R1 would send DSMAP/DDMAP TLV
         containing the Label stack. IMO, it MUST send Label stack - without it R2 can't validate if received data plane label stack is same as in received DSMAP/DDMAP (see later in 5.5).



  5.2  R2 responds with Echo reply containing FEC stack change/pop for 9123.



  5.3. R1 initiates Echo Request with TTL=2 carrying Targeted FEC stack 9136 + 9167 + 9178 and DSMAP/DDMAP containing corresponding label stack

       9136 + 9167 + 9178. The data plane label stack is 9123 + 9136 + 9167 + 9178.



  5.4. The malfunctioning node R2 forwards the packet to R3 with data-plane label stack 9167 + 9178.



  5.5. R3 validates from received Targeted FEC stack that 9136 is the indeed an advertised Adjacency ID and corresponding label in DSMAP/DDMAP is correct. However the label stack
          received in data plane does not correspond to the label stack in DSMAP - this is a key point and there is no mention of it in the draft. Thus R3 responds with label_stack_validation
         failure which indicates a data plane fault in R2.



6.      Section 7.2: the popping of the adjacency SID label is performed by the node which assigned it and it is this node which generates the FEC stack change sub-TLV with the operation of POP.



7.      Section 7.3: while I agree that the implicit NULL label value for the adjacency SID should not be used because the downstream LSR has no context for the adjacency SID of his upstream neighbor (adjacency SIDs are locally significant only) but for node SID with PHP, the downstream node has context and actually signaled PHP flag in the prefix SID sub-TLV. Implicit-Null value is thus valid for node SID.



8.      Section 7.4: This section needs to be written to cover the cases of regular swapping of node/prefix SID and the popping of node SID or adjacency SID when receiving the FEC stack change sub-TLV. Also, what is exactly “Best return code to 10”?



9.      Section 7.5: I do not think this section belongs here. If there are recommendations for TTL setting for hierarchical LSPs, they sure are not specific to SR/SR-TE LSP.





10.  In Section 5



“Three new sub-TLVs are defined for TLVs type 1, 16 and 21.”

It is not clear what is meant by TLVs type 1,16 and 21. Suggest to make explicit references.



11. One missing point in MPLS-OAM so far is to let the originator of a Traceroute know that responding node is currently exercising FRR backup next-hop (because primary has failed).
     AFAIK, this is not covered in any MPLS OAM extensions so far. It is good to address this in SR context.



Summary

-------------



1) Whether the document is coherent

  - Yes



2) is it useful (i.e, is it likely to be actually useful in operational networks)



  - Yes



3) Is the document technically sound?



  - Need precise modeling of MPLS-OAM of a SR/SR-TE LSP. Need to precisely describe procedures in the context of  SR/SR-TE LSP and applicability of RFC 4379, 6424.



4) Whether the document is ready to be considered for WG adoption

  - It is a good start but I would like to see the concerns addressed before publishing the WG draft.



Thanks,

Pranjal





-----Original Message-----
From: Loa Andersson [mailto:loa@pi.nu]
Sent: Wednesday, September 09, 2015 3:00 AM
To: Curtis Villamizar; vishwas.manral@gmail.com<mailto:vishwas.manral@gmail.com>; Dutta, Pranjal K (Pranjal); Lizhong Jin; draft-kumarkini-mpls-spring-lsp-ping@tools.ietf.org<mailto:draft-kumarkini-mpls-spring-lsp-ping@tools.ietf.org>; mpls-chairs@tools.ietf.org<mailto:mpls-chairs@tools.ietf.org>
Subject: Fwd: MPLS-RT review of draft-kumarkini-mpls-spring-lsp-ping



Resending, Vishwas mail bounced and forgot to include the authors and my co-chairs.



/Loa



Curtis, Vishwas, Pranjal, and Lizhong,



You have be selected as MPLS-RT reviewers for draft-kumarkini- mpls-spring-lsp-ping.



Note to authors: You have been CC'd on this email so that you can know that this review is going on. However, please do not review your own document.



Reviews should comment on whether the document is coherent, is it useful (ie, is it likely to be actually useful in operational networks), and is the document technically sound?



We are interested in knowing whether the document is ready to be considered for WG adoption (ie, it doesn't have to be perfect at this point, but should be a good start).



Reviews should be sent to the document authors, WG co-chairs and WG secretary, and CC'd to the MPLS WG email list. If necessary, comments may be sent privately to only the WG chairs.



If you have technical comments you should try to be explicit about what needs to be resolved before adopting it as a working group document, and what can wait until the document is a working group document and the working group has the revision control.



Are you able to review this draft by September 25, 2015? Please respond in a timely fashion.



Thanks, Loa

(as MPLS WG chair)







--





Loa Andersson                        email: loa@mail01.huawei.com<mailto:loa@mail01.huawei.com>

Senior MPLS Expert                          loa@pi.nu<mailto:loa@pi.nu>

Huawei Technologies (consultant)     phone: +46 739 81 21 64



--





Loa Andersson                        email: loa@mail01.huawei.com<mailto:loa@mail01.huawei.com>

Senior MPLS Expert                          loa@pi.nu<mailto:loa@pi.nu>

Huawei Technologies (consultant)     phone: +46 739 81 21 64