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

"Nagendra Kumar Nainar (naikumar)" <naikumar@cisco.com> Thu, 11 February 2016 14:25 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 6DAD01B3252 for <mpls@ietfa.amsl.com>; Thu, 11 Feb 2016 06:25:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -13.52
X-Spam-Level:
X-Spam-Status: No, score=-13.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_FONT_FACE_BAD=0.981, 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 gPO12haIavTm for <mpls@ietfa.amsl.com>; Thu, 11 Feb 2016 06:25:11 -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 6A4CE1B324E for <mpls@ietf.org>; Thu, 11 Feb 2016 06:25:11 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=21353; q=dns/txt; s=iport; t=1455200711; x=1456410311; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=e6XpKPgFMO+LXHPA002p/KU2r0+srK/EEuf/gqHnOuo=; b=fcmUUlsFyn8g51wWQFeA+qysaxfXiskuJmxGoX4woH0FmAps/PEbR0TX Sa6ixpRl5gQqh3B1TiuE+5+SDq827/JcircpycZ8F1yArEzXMzdTF1lTG 4Us68y61eCzUJIlnEdjClhB/ZZooIGuzf3hcjkeUS0pw+iLxYmYAYCbbk o=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: =?us-ascii?q?A0D+AQA/mbxW/5NdJa1egm5MgT8GiFWvB?= =?us-ascii?q?IITAQ2BZ4YNAoEwOBQBAQEBAQEBgQqEQQEBAQQhAUkODgICAQgOAwMBAhAYAgM?= =?us-ascii?q?CGwYRFAkIAgQOBYgFAxKVB50OAYoODYREAQEBAQEBAQEBAQEBAQEBAQEBAQEBF?= =?us-ascii?q?QSKRII3gUsRASMBGhaCR4E9BYdTixuECQGLX4FzgV2EQ4hVhn6HPwEeAQFCg2V?= =?us-ascii?q?qhyM0fAEBAQ?=
X-IronPort-AV: E=Sophos;i="5.22,431,1449532800"; d="scan'208,217";a="237317317"
Received: from rcdn-core-11.cisco.com ([173.37.93.147]) by alln-iport-6.cisco.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 11 Feb 2016 14:25:10 +0000
Received: from XCH-RCD-013.cisco.com (xch-rcd-013.cisco.com [173.37.102.23]) by rcdn-core-11.cisco.com (8.14.5/8.14.5) with ESMTP id u1BEPAOs019011 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Thu, 11 Feb 2016 14:25:10 GMT
Received: from xch-rcd-015.cisco.com (173.37.102.25) by XCH-RCD-013.cisco.com (173.37.102.23) with Microsoft SMTP Server (TLS) id 15.0.1104.5; Thu, 11 Feb 2016 08:25:09 -0600
Received: from xch-rcd-015.cisco.com ([173.37.102.25]) by XCH-RCD-015.cisco.com ([173.37.102.25]) with mapi id 15.00.1104.009; Thu, 11 Feb 2016 08:25:09 -0600
From: "Nagendra Kumar Nainar (naikumar)" <naikumar@cisco.com>
To: Lizhong Jin <lizho.jin@gmail.com>
Thread-Topic: [mpls] Fwd: MPLS-RT review of draft-kumarkini-mpls-spring-lsp-ping
Thread-Index: AQHRZNgCIxkU2oCtv0+2/4XymLTqCg==
Date: Thu, 11 Feb 2016 14:25:09 +0000
Message-ID: <D2E203E7.F1D62%naikumar@cisco.com>
References: <55F0006E.2000906@pi.nu> <CAH==cJxgDcfkoDyeZhw0cZT8AL9JN_-tjKTAtBGCsvzxLL05dg@mail.gmail.com> <CAH==cJy=g-V2=-rpxCU=D9pV9hOyroodK-jhvtiDfZQ+7C=emg@mail.gmail.com> <3F459F22-38A2-43A4-9813-D1BFB43938F6@gmail.com>
In-Reply-To: <3F459F22-38A2-43A4-9813-D1BFB43938F6@gmail.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.150.54.118]
Content-Type: multipart/alternative; boundary="_000_D2E203E7F1D62naikumarciscocom_"
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/mpls/9wX-fG_eiDZTcUEsWPqX8iHOX70>
Cc: "mpls@ietf.org" <mpls@ietf.org>, "mpls-chairs@tools.ietf.org" <mpls-chairs@tools.ietf.org>, Vishwas Manral <vishwas.manral@gmail.com>, "draft-kumarkini-mpls-spring-lsp-ping@tools.ietf.org" <draft-kumarkini-mpls-spring-lsp-ping@tools.ietf.org>, Curtis Villamizar <curtis@occnc.com>
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 <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, 11 Feb 2016 14:25:14 -0000

Thanks Lizhong.

Regards,
Nagendra

From: mpls <mpls-bounces@ietf.org<mailto:mpls-bounces@ietf.org>> on behalf of Lizhong Jin <lizho.jin@gmail.com<mailto:lizho.jin@gmail.com>>
Date: Thursday, February 11, 2016 at 9:04 AM
To: Nagendra Kumar Nainar <naikumar@cisco.com<mailto:naikumar@cisco.com>>
Cc: "mpls@ietf.org<mailto:mpls@ietf.org>" <mpls@ietf.org<mailto:mpls@ietf.org>>, Vishwas Manral <vishwas.manral@gmail.com<mailto:vishwas.manral@gmail.com>>, Curtis Villamizar <curtis@occnc.com<mailto:curtis@occnc.com>>, "mpls-chairs@tools.ietf.org<mailto:mpls-chairs@tools.ietf.org>" <mpls-chairs@tools.ietf.org<mailto:mpls-chairs@tools.ietf.org>>, "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>>
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:naikumar@cisco.com> 写道:
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 <mpls-bounces@ietf.org<mailto:mpls-bounces@ietf.org>> on behalf of Lizhong Jin <lizho.jin@gmail.com<mailto:lizho.jin@gmail.com>>
Date: Friday, September 25, 2015 at 10:19 AM
To: "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>>, Curtis Villamizar <curtis@occnc.com<mailto:curtis@occnc.com>>, Loa Andersson <loa@pi.nu<mailto:loa@pi.nu>>, "Dutta, Pranjal K (Pranjal)" <pranjal.dutta@alcatel-lucent.com<mailto:pranjal.dutta@alcatel-lucent.com>>, Vishwas Manral <vishwas.manral@gmail.com<mailto:vishwas.manral@gmail.com>>, "mpls@ietf.org<mailto:mpls@ietf.org>" <mpls@ietf.org<mailto: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 <lizho.jin@gmail.com<mailto: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<mailto:loa@pi.nu>>
Cc: Curtis Villamizar <curtis@occnc.com<mailto:curtis@occnc.com>>, vishwas@ionosnetworks.com<mailto:vishwas@ionosnetworks.com>, "Dutta, Pranjal K (Pranjal)" <pranjal.dutta@alcatel-lucent.com<mailto:pranjal.dutta@alcatel-lucent.com>>


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 <loa@pi.nu<mailto: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), 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<tel:%2B46%20739%2081%2021%2064>