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

[Gregory Mirsky <[e-mail]>]

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

Thank you for your careful consideration of my comments.

                Regards,
                                Greg

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

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

B.R.
weiqiang cheng




On 2015-07-09 22:29 , Weiqiang Cheng<mailto:[e-mail]> 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.

B.R.
Weiqiang Cheng

From: Gregory Mirsky [mailto:[e-mail]]
Sent: Wednesday, July 08, 2015 8:48 AM
To: Ross Callon; [e-mail]<mailto:[e-mail]>; Rajiv Asati (rajiva); Yimin Shen
Cc: [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]>; [e-mail]<mailto:[e-mail]>; Hejia (Jia); [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
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 4.3.1.1

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

·         s/runnel/tunnel/

[Authors] Sure, we will change it.

·         Section 4.3.1.2 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.

                Regards,
                                Greg

From: Ross Callon [mailto:[e-mail]]
Sent: Wednesday, June 24, 2015 8:41 AM
To: Gregory Mirsky; [e-mail]<mailto:[e-mail]>; Rajiv Asati (rajiva); Yimin Shen
Cc: [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]>; [e-mail]<mailto:[e-mail]>; Hejia (Jia); [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>
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
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 July 9, 2015? Please respond in a
timely fashion.

Thanks, Ross
(as MPLS WG chair)