Re: [mpls] MPLS-RT review of draft-cheng-mpls-tp-shared-ring-protection-05

Gregory Mirsky <> Sun, 12 July 2015 06:30 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 5CFF11A1B91 for <>; Sat, 11 Jul 2015 23:30:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -101.5
X-Spam-Status: No, score=-101.5 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, USER_IN_WHITELIST=-100] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id mWGvjL9oOeVN for <>; Sat, 11 Jul 2015 23:29:56 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 4E86A1A1B8A for <>; Sat, 11 Jul 2015 23:29:55 -0700 (PDT)
X-AuditID: c6180641-f794d6d000001dfb-23-55a1a1ddd81e
Received: from (Unknown_Domain []) by (Symantec Mail Security) with SMTP id FC.88.07675.DD1A1A55; Sun, 12 Jul 2015 01:08:13 +0200 (CEST)
Received: from ([]) by ([]) with mapi id 14.03.0210.002; Sun, 12 Jul 2015 02:29:52 -0400
From: Gregory Mirsky <>
To: Weiqiang Cheng <>, Ross Callon <>, "" <>, "" <>, "" <>
Thread-Topic: RE: MPLS-RT review of draft-cheng-mpls-tp-shared-ring-protection-05
Thread-Index: AQHQuyK6wPiOuwmPGk6b4QHIj0sV3p3XYKDQ
Date: Sun, 12 Jul 2015 06:29:51 +0000
Message-ID: <>
References: <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_7347100B5761DC41A166AC17F22DF11221850C24eusaamb106erics_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA02SWUwTURSGvbN0hgrJUEGu8GSNEU0MS9RcE2LcoiNGRQ1ITYw0cQRCWdJS xCeKKcYACQUKQllrEKRgEXgQEVkaRTCBNoALCCJQpIqCsgiERTvMC2/fOec79/wPl8Yls4Q3 HR2XyCnj5AqpSEzkqlsiDo4YjaH+8/WHUWFvNYbsOSYCaftsJNLqZ3BUUNRPIt0nDYZ6Vz7j KH/iCFrqqyDQ0ONqEq2vj+No/ckAgRp7SFQ0sSxCD/JwZBtrJtDzqr/EcXc27dsrki21GUWs frWeZNtqflPsC8MIxWpf/yLZiooVjP147z3FZhtnKXahf17E1rYuEyHbr4uDbnGK6CRO6Xcs Qhw1XdINEjQ/QXLXYBfQAPskSAcuNGQOQVP7KCXwTmj7UidKB2JawrwBsE3nAEJRBeCz3BqC t0RMIHTUZ1L8wINxAPjDnEnyBc5kETA9r0DEWzuYK3CgXe9k2mldhY+s8Xzbw7k83mHAeCaY vbC4Vbt52o25ABeLTDjPEuYcHDSsYfyqCxMMc8tkfBs40y29q91cxRkvOGQvw4TUDKxoseIC e8LvExukwFL4Z7WMEvx4+PBfOiaccofdhXZCBzwNW54ybNEMWzSDMwXO7Id1zX6CshvqM8Yo gX1hWnEJtbVfDigToNUqLik2MjCgATh/SCcUnWgC5XNHLYChgdTVrVxmDJWQ8iTV3VgL8KEJ qZebz8W4UAkTKU/kYjgugVPeVKoVnMoCMNrFWwPyK9d9ZzPO+E5xyzkzqY7btdoPowN7PDrC MsLNKdmZG6mXfWN0Tfdl9mDDgqXhK1Bbp+MW5S9NPbLTNXnDOehO8ltrlX+W68ZakKNS9zRc UzwszppJvdx5ree8WRGWcuqkXsMs3NhXmjg1mGOZjM0eGUEb5l1JIXON2zDd2UtSQhUlDziA K1Xy/7A1N1QCAwAA
Archived-At: <>
Cc: lifang <>, "" <>, weiqiang cheng <>, "" <>, "" <>, Han Li <>, "" <>, WANG Lei <>, "" <>
Subject: Re: [mpls] MPLS-RT review of draft-cheng-mpls-tp-shared-ring-protection-05
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: Sun, 12 Jul 2015 06:30:00 -0000

Hi Weiqiang,
apologies for missing to include the WG in my initial mail. Corrected.

Thank you for your careful consideration of my comments.


From: Weiqiang Cheng []
Sent: Friday, July 10, 2015 8:11 AM
To: Gregory Mirsky; Ross Callon;;;
Cc: weiqiang cheng; WANG Lei; Han Li;;; Dongjie (Jimmy);; lifang;;;
Subject: Re: RE: MPLS-RT review of draft-cheng-mpls-tp-shared-ring-protection-05

If it is fine for you, would you please forward the comments and discussions to the WG mailing list?

weiqiang cheng

On 2015-07-09 22:29 , Weiqiang Cheng<> Wrote:

Hi Greg,

Greatly appreciate your review and thoughtful comments.

Before we update the draft, I want to give you a quick reply at first.

Our answers are in-line and please check if your comments are addressed.

Weiqiang Cheng

From: Gregory Mirsky []
Sent: Wednesday, July 08, 2015 8:48 AM
To: Ross Callon;<>; Rajiv Asati (rajiva); Yimin Shen
Cc:<>;<>;<>;<>;<>;<>; Hejia (Jia);<>;<>;<>;<>
Subject: RE: MPLS-RT review of draft-cheng-mpls-tp-shared-ring-protection-05

Dear All,
I’ve been selected to review the  draft-cheng-mpls-tp-shared-ring-protection-05 document before the WG adoption call.
The document is coherent, well written and proposes solution to practical scenario. But I’ve found that the document has certain overlap with draft-cui-mpls-tp-mfp-use-case-and-requirements at least in large parts of Section 2 of the draft-cheng-mpls-tp-shared-ring-protection-05. I believe it would bebeneficial if both groups of authors work together  to have single informational draft on requirements towards protection in MPLS-TP under multi-failure condition and have Ring and Interconnected Ring discussed as use cases, including requirements toward Ring Switch Protection protocol.

[Authors] Thanks a lot for your suggestion. Draft-cui described general requirements of Multi-failure protection, and Draft-cheng addressed some multi-failure scenarios. We will contact authors of draft-cui to see if we can work together with them on a requirements and use cases draft or we can contribute some text to draft-cui.

Below are my comments, nits and recommendations to the draft that are non-blocking to WG adoption call:
·         I’d recommend to change terminology (starting from Section 4.1.1 and onwards) :
o   exit node -> egress node

[Authors] Agree, we will change it in the incoming version.

·         Section 4.1.3 bullet 4 is hard to parse and once I’ve interpreted it cannot see it fit logically with other comments to Fig.4

[Authors] We will rephrase the section, and make it more clear.

·         Section 4.2
o   I think that proposed protection mechanism uses link OAM and Continuity Check (CC) may be sufficient thus making Connectivity Verification unnecessary;

[Authors] Agree, we will change CC-V to CC.

o   “Three or more consecutive CC-V packets losses will be interpreted as a link failure.” Strictly speaking, it depends. If assumed that failure detection based on RFC 6428, then it mandates setting of Detect Multiplier to 3, thus making “more consecutive CC-V packets” into indication of OAM malfunction. Perhaps can re-word into “Three consecutive ….”

[Authors] Agree, we will change it.

·         suggest use consistent notation, e.g. either “LSP 1” or “LSP1” throughout the document

[Authors] Agree, we will change it.

·         it may benefit the document if Ring Protection Switch protocol defined before it’s referenced in section

[Authors]Agree, we give a brief introduction about RPS at the introduction section.

·         s/runnel/tunnel/

[Authors] Sure, we will change it.

·         Section discusses node failure scenario but, in fact, the scenario is not much different from link failure discussed already. I believe that the node failure scenario is most interesting to demonstrate behavior of protection mechanism and data flow when the egress (exit) node is the one that failed. Would wrapping prevent from forming infinite loop? Or wrapping without RSP protocol would create infinite loops? What about TTL handling?

[Authors]Agree, we will add some more text to make it more clear.

·         Section 5.1.2 What is scope of Node ID? I can assume that it MUST be unique per ring domain, single ring or interconnected. What would happen with Node IDs it two protected single rings get connected? Or are these questions related to constructing ring map which is outside the scope of the document? I think that constructing the map is rather important to the MSP and should be discussed (it even may be part of the MSP).
[Authors] The Node ID just need to be unique per single ring. We can use  both Ring ID and Node ID to identify unique node in the network domain. We will add some text to describe how to construct the map something like the description in G.841
·         Section 6. It may be beneficial to request IANA to create new registry RSP Request Code registry and allocate codes listed in the table on p.25. And define values not listed in the table as Reserved, e.g. 0b0010, 0b0100, 0b0111, etc.
[Authors]Agree, we will add it.


From: Ross Callon []
Sent: Wednesday, June 24, 2015 8:41 AM
To: Gregory Mirsky;<>; Rajiv Asati (rajiva); Yimin Shen
Cc:<>;<>;<>;<>;<>;<>; Hejia (Jia);<>;<>;<>;<>
Subject: MPLS-RT review of draft-cheng-mpls-tp-shared-ring-protection-05

Greg, Wim, Rajiv, Yimin;

You have be selected as MPLS-RT reviewers for draft-cheng-mpls-tp-shared-ring-protection-05.

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

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 July 9, 2015? Please respond in a
timely fashion.

Thanks, Ross
(as MPLS WG chair)