Return-Path: 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 86C261B3936 for ; Wed, 3 Feb 2016 19:56:24 -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 S2uAh4_ymcop for ; Wed, 3 Feb 2016 19:56:22 -0800 (PST) Received: from alln-iport-5.cisco.com (alln-iport-5.cisco.com [173.37.142.92]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DA7F11B3935 for ; Wed, 3 Feb 2016 19:56:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=16481; q=dns/txt; s=iport; t=1454558181; x=1455767781; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=d/7PUaF72b0O+bs38RBk8zB8IbA3hN51rBhszlZuOj8=; b=EPmDxYF0ZGVzyAwZuXmjj9tlaBi+bHdbSiPfmCm1hA5N75B3DWfla1rt hzH3pfZuQOanQxIs4nj8g/FIA4kPw/mmElcZsCmAdhNE4qk9jB2qdIEkQ G5PrgZ5Z45LxBXDacU6ID82wJ98YYJJ7nwuBuqiHEWUM9OajxXSpwvNA8 4=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0ACAgCVy7JW/4ENJK1egm5MgT8GiFWuc?= =?us-ascii?q?YITAQ2BZoYNAoFFOBQBAQEBAQEBgQqEQQEBAQRrHAICAQgOAwMBAigHGwYRFAk?= =?us-ascii?q?IAgQBEogGAxK8Lw2EPwEBAQEBAQEDAQEBAQEBAQEBFwSKRYI3gUsRASMBGhaEB?= =?us-ascii?q?AWHU4sZhAUBi1mBc4FbhEKIVIZ/g2+DUQEeAQFCg2RqiDs0fAEBAQ?= X-IronPort-AV: E=Sophos;i="5.22,393,1449532800"; d="scan'208,217";a="232918689" Received: from alln-core-9.cisco.com ([173.36.13.129]) by alln-iport-5.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 04 Feb 2016 03:56:20 +0000 Received: from XCH-RCD-012.cisco.com (xch-rcd-012.cisco.com [173.37.102.22]) by alln-core-9.cisco.com (8.14.5/8.14.5) with ESMTP id u143uK9B005061 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 4 Feb 2016 03:56:20 GMT Received: from xch-aln-015.cisco.com (173.36.7.25) by XCH-RCD-012.cisco.com (173.37.102.22) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Wed, 3 Feb 2016 21:56:20 -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:56:20 -0600 From: "Nagendra Kumar Nainar (naikumar)" To: Lizhong Jin , "draft-kumarkini-mpls-spring-lsp-ping@tools.ietf.org" , "mpls-chairs@tools.ietf.org" , Curtis Villamizar , Loa Andersson , "Dutta, Pranjal K (Pranjal)" , Vishwas Manral , "mpls@ietf.org" Thread-Topic: [mpls] Fwd: MPLS-RT review of draft-kumarkini-mpls-spring-lsp-ping Thread-Index: AQHQ96WxBIquyEzZkUOJKjL6qr++WJ8cIXeA Date: Thu, 4 Feb 2016 03:56:20 +0000 Message-ID: References: <55F0006E.2000906@pi.nu> In-Reply-To: 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_D2D835EFE219Dnaikumarciscocom_" MIME-Version: 1.0 Archived-At: Subject: Re: [mpls] Fwd: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Feb 2016 03:56:24 -0000 --_000_D2D835EFE219Dnaikumarciscocom_ Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable 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"? Good Catch. We changed it. 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. We probably will be removing this section and leave "Service segm= ent" for future study. We will take it back once there is some colear conse= nsus on how service segment will be handled. =93 Thanks, Nagendra (for authors) From: mpls > on behalf = of Lizhong Jin > Date: Friday, September 25, 2015 at 10:19 AM To: "draft-kumarkini-mpls-spring-lsp-ping@tools.ietf.org" >, "mpls-chairs@tools.ietf.org" >, Curtis Villam= izar >, Loa Andersson >, "Dutta, Pranjal K (Pranjal)" >, Vishwas Manral >, "mpls@ietf.org" > 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 > Date: Fri, Sep 25, 2015 at 11:17 PM Subject: Re: MPLS-RT review of draft-kumarkini-mpls-spring-lsp-ping To: Loa Andersson > Cc: Curtis Villamizar >, vishwas@= ionosnetworks.com, "Dutta, Pranjal K (Pra= njal)" > 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 >= 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), an= d 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 Senior MPLS Expert loa@pi.nu Huawei Technologies (consultant) phone: +46 739 81 21 64 --_000_D2D835EFE219Dnaikumarciscocom_ Content-Type: text/html; charset="Windows-1252" Content-ID: <8E7020922BF2A148AFC1A9853B46149D@emea.cisco.com> Content-Transfer-Encoding: quoted-printable
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" M= UST 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 labe= l 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 priorit= y
queue after service processing, while the packet without service label=
will enqueue to lowest priority queue. Then it is possible the packet&= nbsp;
may go through a different internal data path before reaching the trac= ed
 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 j= udge
whether the problem is happened on the traced tunnel points, or on&nbs= p;
the path ahead of it.

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

Thanks,
Nagendra (for authors)


From: mpls <mpls-bounces@ietf.org> on behalf of Lizhong Jin= <lizho.jin@gmail.com>
Date: Friday, September 25, 2015 at= 10:19 AM
To: "draft-kumarkini-mpls-spring-l= sp-ping@tools.ietf.org" <draft-kumarkini-mpls-spring-lsp-ping@tools= .ietf.org>, "mpls-chairs@tools.ietf= .org" <mpls-chair= s@tools.ietf.org>, Curtis Villamizar <curtis@occnc.com>, Loa Andersson <loa@pi.nu>, "Dutta, Pranjal K (Pranjal)" <pranjal.dutta@alcatel-lucent.com>, Vishwas Manr= al <vishwas.manral@gmail.com= >, "mpls@ietf.org" <mpls@ietf.org>
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 <<= a href=3D"mailto:lizho.jin@gmail.com" target=3D"_blank">lizho.jin@gmail.com= >
Date: Fri, Sep 25, 2015 at 11:17 PM
Subject: Re: MPLS-RT review of draft-kumarkini-mpls-spring-lsp-ping
To: Loa Andersson <loa@pi= .nu>
Cc: Curtis Villamizar <curtis@occnc.com>, vishwas@iono= snetworks.com, "Dutta, Pranjal K (Pranjal)" <pranjal.dutta@alca= tel-lucent.com>


Hi,
Overall, this document is useful and technically sound, and is ready t= o 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" M= UST 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 labe= l 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 priorit= y
queue after service processing, while the packet without service label=
will enqueue to lowest priority queue. Then it is possible the packet&= nbsp;
may go through a different internal data path before reaching the trac= ed
 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 j= udge
whether the problem is happened on the traced tunnel points, or on&nbs= p;
the path ahead of it.

Regards
Lizhong


On Wed, Sep 9, 2015 at 5:48 PM, Loa Andersson <loa@pi.nu>= 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), an= d 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
Senior MPLS Expert                &= nbsp;         loa@pi.nu
Huawei Technologies (consultant)     phone: +46 739 81 21 64


--_000_D2D835EFE219Dnaikumarciscocom_--