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

["Nagendra Kumar Nainar (naikumar)" <[e-mail]>]

Thanks Lizhong.

Regards,
Nagendra

From: mpls <[e-mail]<mailto:[e-mail]>> on behalf of Lizhong Jin <[e-mail]<mailto:[e-mail]>>
Date: Thursday, February 11, 2016 at 9:04 AM
To: Nagendra Kumar Nainar <[e-mail]<mailto:[e-mail]>>
Cc: "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, Vishwas Manral <[e-mail]<mailto:[e-mail]>>, Curtis Villamizar <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Subject: Re: [mpls] Fwd: MPLS-RT review of draft-kumarkini-mpls-spring-lsp-ping

Hi Nagendra
Sorry for the late reply. I am fine with the changes, thank you.

Regards
Lizhong
在2016年02月04日 11:56，Nagendra Kumar Nainar (naikumar)<mailto:[e-mail]> 写道:
Hi Lizhong,

Thanks for the comments and apologies for the delayed response. Please see 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"?

<Authors>Good Catch. We changed it.
</Authors>

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.

<Authors> We probably will be removing this section and leave "Service segment" for future study. We will take it back once there is some colear consensus on how service segment will be handled.
“

Thanks,
Nagendra (for authors)


From: mpls <[e-mail]<mailto:[e-mail]>> on behalf of Lizhong Jin <[e-mail]<mailto:[e-mail]>>
Date: Friday, September 25, 2015 at 10:19 AM
To: "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, Curtis Villamizar <[e-mail]<mailto:[e-mail]>>, Loa Andersson <[e-mail]<mailto:[e-mail]>>, "Dutta, Pranjal K (Pranjal)" <[e-mail]<mailto:[e-mail]>>, Vishwas Manral <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Subject: [mpls] Fwd: MPLS-RT review of draft-kumarkini-mpls-spring-lsp-ping

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


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


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 <[e-mail]<mailto:[e-mail]>> 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: [e-mail]<mailto:[e-mail]>
Senior MPLS Expert                          [e-mail]<mailto:[e-mail]>
Huawei Technologies (consultant)     phone: [phone]<tel:%2B46%20739%2081%2021%2064>