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

From: Lizhong Jin <[email-masked]>
Date: Fri, 25 Sep 2015 23:19:56 +0800

Sorry, forget to send to the authors and the list.

---------- Forwarded message ----------
From: Lizhong Jin <[email-masked]>
Date: Fri, Sep 25, 2015 at 11:17 PM
Subject: Re: MPLS-RT review of draft-kumarkini-mpls-spring-lsp-ping
To: Loa Andersson <[email-masked]>
Cc: Curtis Villamizar <[email-masked]>, [email-masked],
"Dutta, Pranjal K (Pranjal)" <[email-masked]>

Hi,
Overall, this document is useful and technically sound, and is ready to be
considered for WG adoption. Besides comments from Curtis, two more in below:
1. Section 7.4
If the Label-stack-depth is 0 and Target FEC Sub-TLV at FEC-stack-
      depth is TBD2 (IPv6 Prefix Node Segment ID),
Lizhong: typo? should be "more than 0"?

2. Section8, it says:
To avoid this
   problem, the originator of the "echo request" MUST NOT include the
   service label in the label stack of an echo request above the tunnel
   label of the tunnel that is being currently traced.  In other words
   the ingress must remove all service-labels above the label of the
   tunnel being currently traced, but retain service labels below it
   when sending the echo request.
It seems there is some risk to remove servicing label. In some case,
e.g., the packet with service label may enqueue to the highest priority
queue after service processing, while the packet without service label
will enqueue to lowest priority queue. Then it is possible the packet
may go through a different internal data path before reaching the traced
 tunnel points, because of the lack of the service label. What if this
packet in lowest prioirity queue is dropped? Then it is difficult to judge
whether the problem is happened on the traced tunnel points, or on
the path ahead of it.

Regards
Lizhong

On Wed, Sep 9, 2015 at 5:48 PM, Loa Andersson <[email-masked]> wrote:

> 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: [email-masked]
> Senior MPLS Expert                          [email-masked]
> Huawei Technologies (consultant)     phone: +46 739 81 21 64
>

---

From: "Dutta, Pranjal K (Pranjal)" <[email-masked]>
Date: Sat, 26 Sep 2015 00:58:38 +0000

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:[email-masked]]
Sent: Wednesday, September 09, 2015 3:00 AM
To: Curtis Villamizar; [email-masked]; Dutta, Pranjal K (Pranjal); Lizhong Jin; [email-masked]; [email-masked]
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

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: [email-masked]<mailto:[email-masked]>

Senior MPLS Expert                          [email-masked]<mailto:[email-masked]>

--

Loa Andersson                        email: [email-masked]<mailto:[email-masked]>

Senior MPLS Expert                          [email-masked]<mailto:[email-masked]>

---

From: "Nagendra Kumar Nainar (naikumar)" <[email-masked]>
Date: Sat, 26 Sep 2015 14:24:06 +0000

Hi Pranjal,

Thanks for the review and comments. We will address the same and will update back.

Thanks,
Nagendra

From: <Dutta>, "Pranjal K (Pranjal)" <[email-masked]<mailto:[email-masked]>>
Date: Friday, September 25, 2015 at 8:58 PM
To: Loa Andersson <[email-masked]<mailto:[email-masked]>>, Curtis Villamizar <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, Lizhong Jin <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: RE: MPLS-RT review of draft-kumarkini-mpls-spring-lsp-ping
Resent-From: <[email-masked]<mailto:[email-masked]>>
Resent-To: <[email-masked]<mailto:[email-masked]>>, <[email-masked]<mailto:[email-masked]>>
Resent-Date: Friday, September 25, 2015 at 8:58 PM

Hi,

                  +--------+

                  |   L2   |

                  R3-------R6

                 /           \

                /             \

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

                \             /

                 \           /

                  R4-------R5

10.  In Section 5

Summary

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

  - Yes

  - Yes

Thanks,

Pranjal

-----Original Message-----
From: Loa Andersson [mailto:[email-masked]]
Sent: Wednesday, September 09, 2015 3:00 AM
To: Curtis Villamizar; [email-masked]<mailto:[email-masked]>; Dutta, Pranjal K (Pranjal); Lizhong Jin; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Fwd: MPLS-RT review of draft-kumarkini-mpls-spring-lsp-ping

/Loa

Thanks, Loa

(as MPLS WG chair)

--

--

---

From: Loa Andersson <[email-masked]>
Date: Sun, 27 Sep 2015 16:00:06 +0800

Authors,

We now have three MPLS-RT reviews. Please feel free to go ahead
and consider the comments and to the updates you think is necessary.

As you do so close the loop with the authors and make sure they are
comfortable to go forward to the wg adoption poll.

I personal twist on this that I learnt that the comments you address
now the easier it is too get through the adoption poll.

Carlos,

About the new registry, think about where you want to define it, here
or in smack (if there were no timing issues I'd say smack).

/Loa
mpls wg co-chair

On 2015-09-26 08:58, Dutta, Pranjal K (Pranjal) wrote:
> 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.
>
>     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
>
>     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
> 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.
>
>    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.3. R1 initiates Echo Request with TTL=2 carrying Targeted FEC stack
> 9136 + 9167 + 9178 and DSMAP/DDMAP containing corresponding label stack
>
>    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
> 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
>
> 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).
>    - 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.
>
> To: Curtis Villamizar; [email-masked]; Dutta, Pranjal K
> (Pranjal); Lizhong Jin;
> [email-masked];
> [email-masked]
> 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?
>
> <mailto:[email-masked]>
>
> Senior MPLS Expert [email-masked] <mailto:[email-masked]>
>
> <mailto:[email-masked]>
>
> Senior MPLS Expert [email-masked] <mailto:[email-masked]>
>

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Sun, 27 Sep 2015 18:43:33 +0000

Loa,

Regarding the new registry, the most sensible thing is the smack document
‹ however, from a timing perspective it might not. Either way should be
fine, and yet another alternative is to pull out the LSP Ping IANA
considerations outside into its own doc.

Thanks,

Carlos.

-----Original Message-----
From: Loa Andersson <[email-masked]>
Date: Sunday, September 27, 2015 at 4:00 AM
To: "Dutta, Pranjal K (Pranjal)" <[email-masked]>,
Curtis Villamizar <[email-masked]>, Vishwas Manral
<[email-masked]>, Lizhong Jin <[email-masked]>,
"[email-masked]"
<[email-masked]>,
"[email-masked]" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: MPLS-RT review of draft-kumarkini-mpls-spring-lsp-ping
Resent-From: Loa Andersson <[email-masked]>
Resent-To: <[email-masked]>,
<[email-masked]>
Resent-Date: Sunday, September 27, 2015 at 4:01 AM

>> stack change TLV operation of ³POP² as per RFC 6424.
>>
>> TLV operation of ³POP² as per RFC 6424. In other words, we are modeling
>> 5.Section 7.1: The text under paragraph titled ³Traceroute² is very
>> exactly ³Best return code to 10²?
>>
>> ³Three new sub-TLVs are defined for TLVs type 1, 16 and 21.²
>>

---

From: Loa Andersson <[email-masked]>
Date: Mon, 28 Sep 2015 12:38:02 +0800

Carlos,

I've another option, how about writing a short draft that does nothing
but define the new registry. We progress it ahead of the other two
drafts. When we get to this point in smack we pull it in as any other
"old" draft.

/Loa