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

From: Gregory Mirsky <[email-masked]>
Date: Sun, 12 Jul 2015 06:29:51 +0000

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:[email-masked]]
Sent: Friday, July 10, 2015 8:11 AM
To: Gregory Mirsky; Ross Callon; [email-masked]; [email-masked]; [email-masked]
Cc: weiqiang cheng; WANG Lei; Han Li; [email-masked]; [email-masked]; Dongjie (Jimmy); [email-masked]; lifang; [email-masked]; [email-masked]; [email-masked]
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:[email-masked]> 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:[email-masked]]
Sent: Wednesday, July 08, 2015 8:48 AM
To: Ross Callon; [email-masked]<mailto:[email-masked]>; Rajiv Asati (rajiva); Yimin Shen
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; Hejia (Jia); [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
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:[email-masked]]
Sent: Wednesday, June 24, 2015 8:41 AM
To: Gregory Mirsky; [email-masked]<mailto:[email-masked]>; Rajiv Asati (rajiva); Yimin Shen
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; Hejia (Jia); [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
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)

---

From: Huub van Helvoort <[email-masked]>
Date: Sun, 12 Jul 2015 12:46:40 +0200

Hello Greg,

Please find in-line some more responses [Huub]

on behalf of the authors.

Note that I snipped agreed proposals.

Regards, Huub.

---8<---

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.

[Huub] draft-cui-mpls-tp-mfp-use-case-and-requirements describes use
cases

for end-to-end linear protection only, although that is not
specifically mentioned

in that draft. It is not applicable to ring protection.

The multiple failure condition in rings is related to link or node
failures along the ring.

---8<---

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

[Huub] we are considering removing bullet 4, it is indeed confusing.

·
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;

[Huub] in RFC6371 the term CC-V is used. The CC and CV function are
combined in the same

OAM packet that is used in pro-active mode.

The SF detected by the CC-V will trigger protection switch.

---8<---

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

[Huub] note that wrapping is performed based on the source and
destination node information

in the RPS packet and the information in the ring-map present in
each ring node.

This will prevent infinite loop.

---8<---

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

[Huub] we will use the same IANA request as was used for linear
protection.

Section 5 of RFC6378. (for consistency).

--
*****************************************************************
请记住，你是独一无二的，就像其他每一个人一样