Subject: [mpls] Working Group Last Call for draft-ietf-mpls-tp-shared-ring-protection-02

From: Eric Gray <[email-masked]>
Date: Mon, 15 Aug 2016 14:31:53 +0000

MPLS Working Group,

I am the document shepherd for the following draft:

"MPLS-TP Shared-Ring protection (MSRP) mechanism for ring topology"

(https://datatracker.ietf.org/doc/draft-ietf-mpls-tp-shared-ring-protection  or

https://tools.ietf.org/html/draft-ietf-mpls-tp-shared-ring-protection) - draft

version 02.

This E-Mail is to initiate a two week working group last call on the above draft.

Please send comments to the MPLS working group mailing list ([email-masked]<mailto:[email-masked]>).

There are IPR disclosures for the individual draft that this document replaced.

They can be found here:

https://datatracker.ietf.org/ipr/search/?submit=draft&id=draft-ietf-mpls-tp-shared-ring-protection

All the authors and contributors have stated that they are not aware of any

additional IPR related to this draft.

The document shepherd and working group chairs are frequently asked about

working group discussion related to IPR disclosures.

Please remember that discussion on the content and validity of IPR disclosures

should not take place on IETF mailing lists.

However we are looking for simple statements as to whether or not you support

continued working group effort to progress the document, regardless of existing

IPR disclosures.

Please include this information when making comments, or indicating your

"support/do not support" when responding to this working group last call.

Note that the IETF works on the basis of "rough consensus" - hence, unless you

are convinced that a significant number of other participants will have similar

objections, it may be in your best interest to provide any comments you may have

on this Internet Draft, even if you do not support progressing this draft further.

This working group last call ends Monday, August 29, 2016.

--

Eric Gray

---

From: "Weiqiang Cheng" <[email-masked]>
Date: Mon, 15 Aug 2016 22:36:50 +0800

Support as co-author.

B.R.

Weiqiang Cheng

发件人: Eric Gray [mailto:[email-masked]] 
发送时间: 2016年8月15日 22:32
收件人: [email-masked]
抄送: [email-masked];
[email-masked]
主题: Working Group Last Call for
draft-ietf-mpls-tp-shared-ring-protection-02

MPLS Working Group,

"MPLS-TP Shared-Ring protection (MSRP) mechanism for ring topology” 

(https://datatracker.ietf.org/doc/draft-ietf-mpls-tp-shared-ring-protection
or

https://tools.ietf.org/html/draft-ietf-mpls-tp-shared-ring-protection) –
draft

version 02. 

This E-Mail is to initiate a two week working group last call on the above
draft.

Please send comments to the MPLS working group mailing list ([email-masked]).

There are IPR disclosures for the individual draft that this document
replaced.

They can be found here:

https://datatracker.ietf.org/ipr/search/?submit=draft
<https://datatracker.ietf.org/ipr/search/?submit=draft&id=draft-ietf-mpls-tp
-shared-ring-protection> &id=draft-ietf-mpls-tp-shared-ring-protection 

Please remember that discussion on the content and validity of IPR
disclosures 

However we are looking for simple statements as to whether or not you
support

continued working group effort to progress the document, regardless of
existing 

IPR disclosures. 

“support/do not support" when responding to this working group last call.

Note that the IETF works on the basis of “rough consensus” – hence,
unless you 

are convinced that a significant number of other participants will have
similar 

objections, it may be in your best interest to provide any comments you may
have 

on this Internet Draft, even if you do not support progressing this draft
further.

--

Eric Gray

---

From: Huub van Helvoort <[email-masked]>
Date: Tue, 16 Aug 2016 00:45:55 +0200

I support progressing this draft.

Cheers, co-author, Huub van Helvoort.

------
On 15-08-16 16:31, Eric Gray wrote:
> https://tools.ietf.org/html/draft-ietf-mpls-tp-shared-ring-protection)
> – draft version 02.
>
> Please send comments to the MPLS working group mailing list
> ([email-masked] <mailto:[email-masked]>).
>
> All the authors and contributors have stated that they are not aware
> of any additional IPR related to this draft.
>
> The document shepherd and working group chairs are frequently asked
> about working group discussion related to IPR disclosures.
>
> disclosures should not take place on IETF mailing lists.
>
> However we are looking for simple statements as to whether or not
> you support continued working group effort to progress the document,
 > regardless of existing IPR disclosures.
>
> Please include this information when making comments, or indicating
> your “support/do not support" when responding to this working group
 > last call.
>
> unless you are convinced that a significant number of other
 > participants will have similar objections, it may be in your best
 > interest to provide any comments you may have on this Internet Draft,
 > even if you do not support progressing this draft further.
>

-- 
================================================================
Always remember that you are unique...just like everyone else...

---

From: "Dongjie (Jimmy)" <[email-masked]>
Date: Tue, 16 Aug 2016 07:11:08 +0000

Hi Eric,

As a coauthor, I support the publication of this document.

Best regards,
Jie

From: Eric Gray [mailto:[email-masked]]
Sent: Monday, August 15, 2016 10:32 PM
To: [email-masked]
Cc: [email-masked]; [email-masked]
Subject: Working Group Last Call for draft-ietf-mpls-tp-shared-ring-protection-02

MPLS Working Group,

version 02.

They can be found here:

IPR disclosures.

--

Eric Gray

---

From: Loa Andersson <[email-masked]>
Date: Tue, 16 Aug 2016 12:02:25 +0200

Eric, working group, authors,

I've re-read this document and find it very clear and well organized.
It is possible to read also for a person that have not (like me) spent
much time on ring (protection) technologies.

I support publishing this document as a Standard Tracks RFC.

I also found a couple of minor nits.

At many places the concept "pass-trough" is used, I think this should
be "pass-through".

In the second paragraph of section 4.3
s/peform/perform

At the first line of the second paragraph of section 4.4.2
s/seperate/separate

At the first paragraph after the bulleted list in section 4.4.3
s/will terminated/be terminated or s/will terminated/will terminate

Third paragraph section 5.1
s/indentity/identify

I also have some comments on section 6.2, sorry I should have captured
this earlier, I would like it to read.

6.2.  RSP Request Codes

    IANA is requested to create a new sub-registry under the
    "Multiprotocol Label Switching (MPLS) Operations, Administration, and
    Management (OAM) Parameters" registry called the "MPLS RPS Request
    Code Registry".  All code points within this registry shall be
    allocated according to the "Standards Action" procedure as specified
    in [RFC5226].

    The RPS Request Field is 8 bits, the allocated values are as follows:

        Value       Description               Reference
       -------  --------------------------- ---------------
          0     Reserved                    this document
          1     No Request (NR)             this document
          2     Reverse Request (RR)        this document
          3     unassigned
          4     Exercise (EXER)             this document
          5     not assigned
          6     Wait-To-Restore (WTR)       this document
          7     Manual Switch (MS)          this document
         8-10   unassigned
         11     Signal Fail (SF)            this document
         12     not assigned
         13     Forced Switch (FS)          this document
         14     unassigned
         15     Lockout of Protection (LP)  this document
       16-254   unassigned
        255     Reserved

I understand that IANA prefer the "unassigned" rather than "not
assigned", I think there is some subtlety in English that I don't
really get.

Normally we want to reserve the first and last value. I'm not totally
sure that there is a significant difference between "No request" and
"reserved", but I think that "no request" would be a valid code, while
"reserved" would cause a failure to be reported, right?

/Loa

---

From: "Andrew G. Malis" <[email-masked]>
Date: Tue, 16 Aug 2016 17:03:25 +0100

Eric,

I support the draft being published.

Thanks,
Andy

On Mon, Aug 15, 2016 at 3:31 PM, Eric Gray <[email-masked]> wrote:

> https://datatracker.ietf.org/ipr/search/?submit=draft&id=
> draft-ietf-mpls-tp-shared-ring-protection
>
>
>
> Note that the IETF works on the basis of “rough consensus” – hence, unless
> you
>
> _______________________________________________
> mpls mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mpls
>
>

---

From: Eric Gray <[email-masked]>
Date: Tue, 16 Aug 2016 18:58:14 +0000

The below is my comments (as document shepherd) for the Working Group Last Call on 
this draft.

Comments:

I support progression of this document after addressing a number of issues.

I have already raised the issue with the (large) number of Authors listed on the first page.

====

As a general question, that affects a number of portions of the draft, is it the intention that 
all ring nodes in a ring operate in the _same_ protection switching mode (wrapping, short
wrapping or steering)?

One reason why this is important is that operating in inconsistent modes may result in 
unpredictable behavior - particularly in multiple failure scenarios.

Another reason why this is important, is that - if consistency is a requirement - then it is 
quite likely to be useful to have some way for ring nodes to verify that this is the case.

And one more reason why this is important is that - if consistency is required, and can be
verified by ring nodes participating in a ring - then RPS currently only seems to be needed
in a limited set of scenarios (to detect a unidirectional link failure in wrapping mode, or 
when using steering mode).  RPS is not otherwise mentioned in connection with modes of 
operation.  Note that this may be in error (it seems likely that RPS may be needed to detect 
a unidirectional link failure in all modes, but the current draft seems to only discuss this in 
connection with the wrapping protection switch mode).

Note that - if RPS is required only to provide support for a unidirectional link failure, there 
are other ways to do this.

The answer to this general question may affect some of my comments below.

Section 5.1 seems to indicate that the protection switching mode is a ring characteristic - 
which strongly supports the need for consistency in protection switching mode in a ring.
But I did not see an explicit statement to this effect elsewhere in the document.  

I would expect any such statement to occur at the point where the modes are introduced 
(i.e. - in section 4.3).

====

In the Introduction for this draft, you summarize optimization features from RFC 5654 as 
follows:
   a.  Minimize the number of OAM entities for protection
   b.  Minimize the number of elements of recovery
   c.  Minimize the required label number
   d.  Minimize the amount of control and management-plane transactions
       during maintenance operation
   e.  Minimize the impact on information exchange during protection if
       a control plane is supported

>From RFC 5654, the actual "optimization criteria" are:

   a.  Minimize the number of OAM entities that are needed to trigger
       the recovery operation, such that it is less than is required by
       other recovery mechanisms.
   b.  Minimize the number of elements of recovery in the ring, such
       that it is less than is required by other recovery mechanisms.
   c.  Minimize the number of labels required for the protection paths
       across the ring, such that it is less than is required by other
       recovery mechanisms.
   d.  Minimize the amount of control and management-plane transactions
       during a maintenance operation (e.g., ring upgrade), such that it
       is less than the amount required by other recovery mechanisms.
   e.  When a control plane is supported, minimize the impact on
       signaling and routing information exchange during protection,
       such that it is less than the impact caused by other recovery
       mechanisms.

The draft does not identify the list provided as a summary of the correlated "optimization
criteria" from RFC 5654, and the summarized versions leave a lot of information out.  

This could be misleading and it would be useful to suggest to a reader that they might look a
at the actual criteria in RFC 5654 for more information.

As an example of "missing information," the summarized versions do not indicate to what 
we would compare the minimizations in this draft to determine that they achieve their
(ambiguous) goals (i.e. "such that [the characteristic being minimized] is less than [that
same or similar characteristic] for other recovery mechanisms").

Additional "missing" information includes:
  a. "needed to trigger recovery" as opposed to "for protection."
  b. "in the ring" (possibly not important).
  c. "number of labels required for the protection paths across the ring" as opposed to 
      "required label number" (remember that - to some people - labels are numbers).
  d. an example is given of a maintenance operation (possibly not important).
  e. "signaling and routing information exchange" as opposed to "information exchange."

Minimally, some wording improvements are required to align the text in this draft with the
corresponding text in RFC 5654.

====

In the second paragraph after bullet "e" on page 4, you state that "the solution for 
point-to-multipoint transport paths is under study and will be presented in a separate 
document."  It is generally not a good idea for an Internet Draft to attempt to predict 
what may or may not happen in documents that are as yet unwritten.  It is sufficient 
to say that "a solution for anything other than point-to-point transport paths is out of 
scope in this document"  (specifically - replace "under study and will be presented in 
a separate" with "out of scope in this").

Note that this means this document does not satisfy Requirement 95 from RFC 5654.

====

When I see a statement along the lines of "This document elaborates on the requirements 
in detail" - my immediate concern is that what might actually happen is that requirements
are going to be "restated" in some way that supports a new (or different) interpretation or
agenda.

Please make it clearer what the intentions are for this document with respect to RFC 5654.

The Introduction claims that this document addresses ring protection requirements in
RFC 5654, yet - once we get into section 2, we jumps right over requirements 92-104A
to address the requirement that the protection mechanisms SHOULD protect against 
multiple failures.  Why is that?  

Perhaps the authors are already aware of an obvious set of mechanisms that satisfy 
these earlier requirements (many of which are ones that MUST be met) and it is then 
only necessary to delve more deeply into mechanisms that further satisfy this 
"SHOULD" be met requirement?  

If so, say so.  

If not, then provide some justification for why you want to address this somewhat soft 
requirement first.

====

Where - in RFC 5654 - does it state "recovery mechanisms which are optimized for ring 
topologies could be further developed if it can provide the following features" (I couldn't
discover that the word "developed" was used at all in RFC 5654, for instance)?  What it
seems to say is that the recovery mechanisms applicable to generic recovery may be 
optimized for specific topologies provided the optimizations meet the stated criteria,
and satisfy somewhat vague "cost-benefit" considerations.  Perhaps you meant to say:
"recovery mechanisms could be further optimized for ring topologies if those further
optimizations meet the following criteria" (or something along these lines)?

====

The first paragraph after bullet "e" on page 4 is awkward; I suggest replacing "those" with
"the."  Also note that the wording could use some minor improvement to avoid giving the
impression that the preceding list of "criteria" is not what you are referring to here as
"requirements on ring protection listed in RFC 5654."  Perhaps stating the actual number
range (i.e. - 92-94 and 96-109) of requirements this document addresses; or is the list of 
requirements this draft aims to address shorter than this?

====

Which requirements from RFC 5654 are addressed in section 2.2 (can you identify them
as part of this section).
 
====

Which requirements from RFC 5654 are addressed in section 2.3 (can you identify them
as part of this section).

====

Figure 1 (or at least part of the text describing it) appears to apply only to the ingress port
for Ring Tunnels; at an egress port, it is not a question of the port "can carry" multiple ring 
tunnels, because it _does_ carry exactly 4 (per description in section 4.1.1).

====

Having defined a notation for "label stack" in section 3, section 4 then falls back to a more
traditional notation.  Is there a reason why you do not use the same notation consistently?
Should you maybe include the possibility that the more traditional notation might also be 
used when defining a different notation in section 3?

The way I understand the notation defined in section 3, the label stack in figure 2 would be
shown as -

	[ Ring Tunnel Label | LSP Label | PW Label ] Payload

- which seems simpler than the way it is currently depicted.

====

Perhaps you should look again at the notation text in section 3.  One notation that you appear 
to be actually using is for an egress "<X>" to define 4 tunnels as:
	RcW_<X>
	RaP_<X>
	RaW_<X>
	RcP_<X>

For the first "reverse hop" in each tunnel, there is a label assigned by the egress corresponding
to that tunnel.

If you then construct a label-stack along the lines of the one above, the "Ring Tunnel Label"
would be whatever label corresponds to one of the above 4 tunnels (for that "hop" it might 
be unnecessary to use parentheses to add the "Node Name" of the assigning node to the 
label stack).

For each subsequent "reverse hop", the label could presumably be assigned by the downstream
end of the "hop" and the assigning node would be the same for RcW_<X> and RcP_<X> (the node
that is one "hop" clockwise from <X>), and a (probably different) assigning node would be the 
same for RaW_<X> and RaP_<X> (the node that is one "hop" counter-clockwise from <X>).

In any case, the notation used to name Ring tunnels is not described in section 3.

I assume that how LSP labels and PW labels are assigned is out of scope for this draft.

====

The wording in section 4.1.3 is unclear; because you have not described the mapping for Ring 
Tunnel Labels at each hop, it is not clear what it means when the "ingress node on the ring 
pushes the working ring tunnel label according to the egress node" (chances are pretty good the
actual label pushed on by the Ring Tunnel ingress may not be the same label that was assigned 
for the Ring Tunnel by the tunnel egress node (unless the particular tunnel is one "hop" from the
ingress to the egress node, or the labels are configured that way for all tunnels at all ring nodes 
- which may not be possible).

Section 4.1.2 should probably say a little bit more about assignment of Ring Tunnel Labels at
each transit node in the ring.

====

What is meant in section 4.2 by "Two end ports of a link"?  I assume this means the ports that are
used to connect two adjacent nodes on a ring, but "end ports" makes this unclear.

====

There are issues with use of (or non-use of) normative language in section 4.3.  Is it the case that
every node MUST obtain the ring topology (currently it says "can")?  

This seems important because it is not at all clear that ring-topology awareness is required to 
support either wrapping protection mode (this assumes that protection mode is required to be 
consistent in a ring), since it seems that wrapping occurs at points where the ring is broken, 
irrespective of the ring topology otherwise.

Where is there a statement to the effect that the protection switching mode in a single ring MUST
be consistent?

====

For Steering (section 4.3.3), there are a few places where the description might be easier to follow
if there was a term (or expression) for "the ring node on which an LSP enters the ring" - since this is 
(as I understand it) the ONLY ring node where the location of the failure determines which ring the 
LSP traffic will be forwarded on.

There may be an unwritten assumption associated with the use of Steering protection switching 
mode - that is particularly obvious in the 2nd paragraph.  As I understand it, Steering mode is the 
only mode where ring topology information is needed by every ring node.  

This seems to be the case because steering mode is the only mode where the decision as to which
ring to use in forwarding LSP traffic is made at each node depending on where that node is in the
ring and where in the ring the failure has occurred.  For the wrapping modes, the traffic is placed 
on the working ring by each node and only moved to a protection ring by the ring node directly 
adjacent to the link or node failure.

However, with respect to knowledge of ring-topology information, the draft says only that this 
information is either configured or learned "via some topology discovery mechanism" (in the 2nd 
paragraph, section 4.3).

If it is the case that ring-topology awareness is only explicitly required for steering mode, then the
assumption that this information is known should be explicitly stated here (if - as does not seem 
very likely, or possibly not necessary - this information is explicitly required for all modes, then that
should be made explicit in the use of normative language in section 4.3).

====

In section 5, I strongly suspect that - no matter how hard (or how often) we look at this section - 
there will very likely be issues that will only be discovered by implementers (especially those not
already involved in writing this section, as they will be the ones that discover hidden assumptions
or missing pieces).

====

Depending on a number of factors - chief among them is whether or not RPS is required to know
about unidirectional link failures in every protection switching mode - it may be the case that RPS
is NOT necessarily required to support MSRP.  Should that turn out to be the case, then you need 
to reconsider certain uses of normative language in section 5.1.

If the RPS process does not communicate between ring nodes via the G-ACh channel defined in this 
document, how would it do so?  Note that - in this document - you currently seem to require use of
RPS and define one mechanism (use of a G-ACh channel) for doing this.  Assuming both these facts
are true, it seems reasonable to mandate use of the defined mechanism.

Note that text in section 7 (Security Considerations) does explicitly state that G-ACh is used for RPS
protocol.

What does it mean to have no protection switching active on a ring (perhaps you mean no protection
switching in effect)?  Or is this something that is a common understanding among operators (i.e. - if
protection switching is "active" this means that the protection switching mechanisms enabled are in
use as a result of a failure)?

What exactly is a "failed span?"

What does it mean to say that "Ring switches MUST be preempted by higher priority RPS requests?"
I assume this means that it must be possible to change the protection switching state as a result of a
higher priority RPS request - but this is not necessarily obvious.

In the last paragraph of section 5.1 (immediately before section 5.1.1), you say that "nodes do not
preempt existing RPS requests unless they have a higher-priority RPS request."  Further, you imply
that "knowledge of the state of the ring" is required to make this determination.  

Exactly how does a ring node make this determination?  A ring node can make direct comparisons 
between an incoming RPS message type/priority and the RPS message type/priority it would make
based on local knowledge of the ring - but this does not require "knowledge of the state of the ring"
only knowledge of local ring-state.

Moreover, "knowledge of the state of the ring" is often less than perfect, if meant to apply to remote
portions of the ring (an incoming RPS message is likely to reflect better knowledge of the ring-state
than the ring node would otherwise likely have).

====

For section 5.1.1 - exactly how is the recommended interval between RPS message reflecting new 
information determined?  I can see that having an interval of 3.3 milliseconds would result in having
sent 3 of them in slightly less than 10 milliseconds, but this may not be particularly relevant in the 
goal of a 50 millisecond protection switch completion if the mechanism is relying on RPS propagation 
around the ring the long way in order to detect a unidirectional link failure.

===

On page 28, what does this paragraph mean?

"When multiple MS RPS requests over different spans exist at the same time, no switch SHOULD be 
executed and existing switches MUST be dropped.  The nodes MUST signal, anyway, the MS RPS 
request code."

After looking a bit, "MS" probably means "Manual Switch" and this would imply that the effect of
having multiple manual switch commands should be that they nullify each other.  But what is the 
expected behavior if there are multiple manual switch commands in a ring and a ring node sends 
a "Signal Fail"  RPS message?

====

Section 6 - in effect, this section determines  the value assignments that will be used in the rest of 
the document.  Therefore, the statement that "new values" are "defined in this document and 
summarized in this section" is not quite correct (because it implies that they are defined elsewhere
in this document and then summarized here).  I suggest replacing " and summarized in this section"
with "listed in the sections below" so that it would now read:

"IANA is requested to administer the assignments of new values defined in this document and listed
in the sections below."

I will grant you that this seems a minor point; the code points are defined here and their meaning
and use is defined elsewhere in the document.  But this section is about the code points and the 
need for IANA to create registries as needed and record these assignments.  Everything that IANA 
needs MUST be _included_ (not summarized) here.

=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=

NITs:
Section 3 - "()" Are called "parentheses" - "[]" are "brackets" and "{}" are "braces."

----

Section 4.2 - "Three consecutive CC packets losses ..." doesn't make sense - probably should be
"three consecutive lost CC packets ..."

----

Section 4.3 - in the last sentence of the 2nd paragraph, "use" should be "uses" and "peform" should 
be "perform."

Also, "(original data traffic carried by LSP1)" and "(data traffic carried by LSP1)" should both just be 
"Payload" to be consistent with Figure 2.  The same also applies (to "Original data traffic) later in 
section 4.3.1.1, (to "original data traffic carried by LSP1" and "data traffic carried by LSP1") in 
section 4.3.1.2 and anywhere else where you use similar phrasing.

"Then at node D ..." should start a separate paragraph.

"... node which detects a ..." should be "... the node which detects a ..."

"... and reach the egress node" should be "... and reaches the egress node"  (though "... and arrives
at the egress node" may be a slightly better wording).

""At the egress node, the traffic leave the ring ..." - "leave" should be "leaves" (even though "traffic"
may be (and often is) plural, it is a group name (like "herd") so if it is in the singular form, that is what
the verb ("leave" in this case) has to match.

Similar for the case with "... following sections describes ..." (should be "... following sections describe 
...").

----

Section 4.3.1 - "... tunnel can protect both the link failure and the node failure" should probably be "...
tunnel can protect against either a link failure or a node failure."

----

Section 4.3.2.1 - in the 4th sentence, "Rap_D" should be "RaP_D."

----

Section 4.3.3 - 1st sentence, "perform" should be "performs."

In the last sentence, "needs" should be "need" and "it" should be "the ring node."

----

Top of page 26, 2nd paragraph - "resulting the ring being ..." should probably be "resulting in the
ring being ..."

----

In section 5.1.3.2, "... to adjacent node ..." should probably be "... to adjacent nodes ..."

----

There are a great many places where "Pass-trough" should probably be "Pass-through" in sections
under 5.2 (i.e. 5.2.2 through 5.2.5).

----

On the last line on page 28, "Node" should probably be "The node."

----

Section 6.2 - in the section title, "RSP" probably was meant to be "RPS."

--
Eric Gray

PS - As a general (but mostly irrelevant) observation, I found it amusing that the acronym chosen 
for this specification (MSRP) just happens to be the common acronym in use for decades in 
the US to mean "Manufacturer's Suggested Retail Price."

:-)

_________________________________________________________________________________
From: mpls [mailto:[email-masked]] On Behalf Of Eric Gray
Sent: Monday, August 15, 2016 10:32 AM
To: [email-masked]
Cc: [email-masked]; [email-masked]
Subject: [mpls] Working Group Last Call for draft-ietf-mpls-tp-shared-ring-protection-02

MPLS Working Group,

Please send comments to the MPLS working group mailing list (mailto:[email-masked]).

--
Eric Gray

---

From: "Dongjie (Jimmy)" <[email-masked]>
Date: Wed, 24 Aug 2016 09:05:24 +0000

Hi Eric, 

Thanks a lot for your comments and sorry for the late reply. 

Recently the authors are discussing the possible improvements to the draft to solve your comments, and will come back to you soon.

Best regards,
Jie

> -----Original Message-----
> Sent: Wednesday, August 17, 2016 2:58 AM
> To: [email-masked]
> Subject: RE: Working Group Last Call for
> The below is my comments (as document shepherd) for the Working Group Last
> Call on this draft.
> 
> Comments:
> 
> As a general question, that affects a number of portions of the draft, is it the
> intention that all ring nodes in a ring operate in the _same_ protection switching
> mode (wrapping, short wrapping or steering)?
> 
> One reason why this is important is that operating in inconsistent modes may
> result in unpredictable behavior - particularly in multiple failure scenarios.
> 
> Another reason why this is important, is that - if consistency is a requirement -
> then it is quite likely to be useful to have some way for ring nodes to verify that
> this is the case.
> 
> And one more reason why this is important is that - if consistency is required, and
> can be verified by ring nodes participating in a ring - then RPS currently only
> seems to be needed in a limited set of scenarios (to detect a unidirectional link
> failure in wrapping mode, or when using steering mode).  RPS is not otherwise
> mentioned in connection with modes of operation.  Note that this may be in
> error (it seems likely that RPS may be needed to detect a unidirectional link
> failure in all modes, but the current draft seems to only discuss this in connection
> with the wrapping protection switch mode).
> 
> Note that - if RPS is required only to provide support for a unidirectional link
> failure, there are other ways to do this.
> 
> Section 5.1 seems to indicate that the protection switching mode is a ring
> characteristic - which strongly supports the need for consistency in protection
> switching mode in a ring.
> I would expect any such statement to occur at the point where the modes are
> introduced (i.e. - in section 4.3).
> 
> ====
> 
> The draft does not identify the list provided as a summary of the correlated
> "optimization criteria" from RFC 5654, and the summarized versions leave a lot of
> information out.
> 
> This could be misleading and it would be useful to suggest to a reader that they
> might look a at the actual criteria in RFC 5654 for more information.
> 
> As an example of "missing information," the summarized versions do not indicate
> to what we would compare the minimizations in this draft to determine that they
> achieve their
> (ambiguous) goals (i.e. "such that [the characteristic being minimized] is less than
> [that same or similar characteristic] for other recovery mechanisms").
> 
> Minimally, some wording improvements are required to align the text in this draft
> with the corresponding text in RFC 5654.
> 
> ====
> 
> In the second paragraph after bullet "e" on page 4, you state that "the solution
> for point-to-multipoint transport paths is under study and will be presented in a
> separate document."  It is generally not a good idea for an Internet Draft to
> attempt to predict what may or may not happen in documents that are as yet
> unwritten.  It is sufficient to say that "a solution for anything other than
> point-to-point transport paths is out of scope in this document"  (specifically -
> replace "under study and will be presented in a separate" with "out of scope in
> this").
> 
> When I see a statement along the lines of "This document elaborates on the
> requirements in detail" - my immediate concern is that what might actually
> happen is that requirements are going to be "restated" in some way that
> supports a new (or different) interpretation or agenda.
> 
> The Introduction claims that this document addresses ring protection
> requirements in RFC 5654, yet - once we get into section 2, we jumps right over
> requirements 92-104A to address the requirement that the protection
> mechanisms SHOULD protect against multiple failures.  Why is that?
> 
> Perhaps the authors are already aware of an obvious set of mechanisms that
> satisfy these earlier requirements (many of which are ones that MUST be met)
> and it is then only necessary to delve more deeply into mechanisms that further
> satisfy this "SHOULD" be met requirement?
> 
> If so, say so.
> 
> If not, then provide some justification for why you want to address this
> somewhat soft requirement first.
> 
> ====
> 
> Where - in RFC 5654 - does it state "recovery mechanisms which are optimized
> for ring topologies could be further developed if it can provide the following
> features" (I couldn't discover that the word "developed" was used at all in RFC
> 5654, for instance)?  What it seems to say is that the recovery mechanisms
> applicable to generic recovery may be optimized for specific topologies provided
> the optimizations meet the stated criteria, and satisfy somewhat vague
> "cost-benefit" considerations.  Perhaps you meant to say:
> "recovery mechanisms could be further optimized for ring topologies if those
> further optimizations meet the following criteria" (or something along these
> lines)?
> 
> ====
> 
> The first paragraph after bullet "e" on page 4 is awkward; I suggest replacing
> "those" with "the."  Also note that the wording could use some minor
> improvement to avoid giving the impression that the preceding list of "criteria" is
> not what you are referring to here as "requirements on ring protection listed in
> RFC 5654."  Perhaps stating the actual number range (i.e. - 92-94 and 96-109) of
> requirements this document addresses; or is the list of requirements this draft
> aims to address shorter than this?
> 
> ====
> 
> Which requirements from RFC 5654 are addressed in section 2.2 (can you identify
> them as part of this section).
> 
> ====
> 
> Which requirements from RFC 5654 are addressed in section 2.3 (can you identify
> them as part of this section).
> 
> ====
> 
> Figure 1 (or at least part of the text describing it) appears to apply only to the
> ingress port for Ring Tunnels; at an egress port, it is not a question of the port
> "can carry" multiple ring tunnels, because it _does_ carry exactly 4 (per
> description in section 4.1.1).
> 
> ====
> 
> Having defined a notation for "label stack" in section 3, section 4 then falls back to
> a more traditional notation.  Is there a reason why you do not use the same
> notation consistently?
> Should you maybe include the possibility that the more traditional notation might
> also be used when defining a different notation in section 3?
> 
> The way I understand the notation defined in section 3, the label stack in figure 2
> would be shown as -
> 
> Perhaps you should look again at the notation text in section 3.  One notation
> that you appear to be actually using is for an egress "<X>" to define 4 tunnels as:
> 	RcW_<X>
> 	RaP_<X>
> 	RaW_<X>
> 	RcP_<X>
> 
> For the first "reverse hop" in each tunnel, there is a label assigned by the egress
> corresponding to that tunnel.
> 
> would be whatever label corresponds to one of the above 4 tunnels (for that
> "hop" it might be unnecessary to use parentheses to add the "Node Name" of
> the assigning node to the label stack).
> 
> For each subsequent "reverse hop", the label could presumably be assigned by
> the downstream end of the "hop" and the assigning node would be the same for
> RcW_<X> and RcP_<X> (the node that is one "hop" clockwise from <X>), and a
> (probably different) assigning node would be the same for RaW_<X> and RaP_<X>
> (the node that is one "hop" counter-clockwise from <X>).
> 
> The wording in section 4.1.3 is unclear; because you have not described the
> mapping for Ring Tunnel Labels at each hop, it is not clear what it means when
> the "ingress node on the ring pushes the working ring tunnel label according to
> the egress node" (chances are pretty good the actual label pushed on by the Ring
> Tunnel ingress may not be the same label that was assigned for the Ring Tunnel
> by the tunnel egress node (unless the particular tunnel is one "hop" from the
> Section 4.1.2 should probably say a little bit more about assignment of Ring
> Tunnel Labels at each transit node in the ring.
> 
> ====
> 
> What is meant in section 4.2 by "Two end ports of a link"?  I assume this means
> the ports that are used to connect two adjacent nodes on a ring, but "end ports"
> makes this unclear.
> 
> ====
> 
> There are issues with use of (or non-use of) normative language in section 4.3.
> Is it the case that every node MUST obtain the ring topology (currently it says
> "can")?
> 
> This seems important because it is not at all clear that ring-topology awareness is
> required to support either wrapping protection mode (this assumes that
> protection mode is required to be consistent in a ring), since it seems that
> wrapping occurs at points where the ring is broken, irrespective of the ring
> topology otherwise.
> 
> Where is there a statement to the effect that the protection switching mode in a
> single ring MUST be consistent?
> 
> ====
> 
> For Steering (section 4.3.3), there are a few places where the description might
> be easier to follow if there was a term (or expression) for "the ring node on
> which an LSP enters the ring" - since this is (as I understand it) the ONLY ring node
> where the location of the failure determines which ring the LSP traffic will be
> forwarded on.
> 
> There may be an unwritten assumption associated with the use of Steering
> protection switching mode - that is particularly obvious in the 2nd paragraph.  As
> I understand it, Steering mode is the only mode where ring topology information
> is needed by every ring node.
> 
> This seems to be the case because steering mode is the only mode where the
> decision as to which ring to use in forwarding LSP traffic is made at each node
> depending on where that node is in the ring and where in the ring the failure has
> occurred.  For the wrapping modes, the traffic is placed on the working ring by
> each node and only moved to a protection ring by the ring node directly adjacent
> to the link or node failure.
> 
> However, with respect to knowledge of ring-topology information, the draft says
> only that this information is either configured or learned "via some topology
> discovery mechanism" (in the 2nd paragraph, section 4.3).
> 
> If it is the case that ring-topology awareness is only explicitly required for steering
> mode, then the assumption that this information is known should be explicitly
> stated here (if - as does not seem very likely, or possibly not necessary - this
> information is explicitly required for all modes, then that should be made explicit
> in the use of normative language in section 4.3).
> 
> ====
> 
> In section 5, I strongly suspect that - no matter how hard (or how often) we look
> at this section - there will very likely be issues that will only be discovered by
> implementers (especially those not already involved in writing this section, as
> they will be the ones that discover hidden assumptions or missing pieces).
> 
> ====
> 
> Depending on a number of factors - chief among them is whether or not RPS is
> required to know about unidirectional link failures in every protection switching
> mode - it may be the case that RPS is NOT necessarily required to support MSRP.
> Should that turn out to be the case, then you need to reconsider certain uses of
> normative language in section 5.1.
> 
> If the RPS process does not communicate between ring nodes via the G-ACh
> channel defined in this document, how would it do so?  Note that - in this
> document - you currently seem to require use of RPS and define one mechanism
> (use of a G-ACh channel) for doing this.  Assuming both these facts are true, it
> seems reasonable to mandate use of the defined mechanism.
> 
> Note that text in section 7 (Security Considerations) does explicitly state that
> G-ACh is used for RPS protocol.
> 
> What does it mean to have no protection switching active on a ring (perhaps you
> mean no protection switching in effect)?  Or is this something that is a common
> understanding among operators (i.e. - if protection switching is "active" this
> means that the protection switching mechanisms enabled are in use as a result of
> a failure)?
> 
> I assume this means that it must be possible to change the protection switching
> state as a result of a higher priority RPS request - but this is not necessarily
> obvious.
> 
> In the last paragraph of section 5.1 (immediately before section 5.1.1), you say
> that "nodes do not preempt existing RPS requests unless they have a
> higher-priority RPS request."  Further, you imply that "knowledge of the state of
> the ring" is required to make this determination.
> 
> Exactly how does a ring node make this determination?  A ring node can make
> direct comparisons between an incoming RPS message type/priority and the RPS
> message type/priority it would make based on local knowledge of the ring - but
> this does not require "knowledge of the state of the ring"
> Moreover, "knowledge of the state of the ring" is often less than perfect, if
> meant to apply to remote portions of the ring (an incoming RPS message is likely
> to reflect better knowledge of the ring-state than the ring node would otherwise
> likely have).
> 
> ====
> 
> For section 5.1.1 - exactly how is the recommended interval between RPS
> message reflecting new information determined?  I can see that having an
> interval of 3.3 milliseconds would result in having sent 3 of them in slightly less
> than 10 milliseconds, but this may not be particularly relevant in the goal of a 50
> millisecond protection switch completion if the mechanism is relying on RPS
> propagation around the ring the long way in order to detect a unidirectional link
> failure.
> 
> ===
> 
> "When multiple MS RPS requests over different spans exist at the same time, no
> switch SHOULD be executed and existing switches MUST be dropped.  The
> nodes MUST signal, anyway, the MS RPS request code."
> 
> After looking a bit, "MS" probably means "Manual Switch" and this would imply
> that the effect of having multiple manual switch commands should be that they
> nullify each other.  But what is the expected behavior if there are multiple
> manual switch commands in a ring and a ring node sends a "Signal Fail"  RPS
> message?
> 
> ====
> 
> Section 6 - in effect, this section determines  the value assignments that will be
> used in the rest of the document.  Therefore, the statement that "new values"
> are "defined in this document and summarized in this section" is not quite correct
> (because it implies that they are defined elsewhere in this document and then
> summarized here).  I suggest replacing " and summarized in this section"
> "IANA is requested to administer the assignments of new values defined in this
> document and listed in the sections below."
> 
> I will grant you that this seems a minor point; the code points are defined here
> and their meaning and use is defined elsewhere in the document.  But this
> section is about the code points and the need for IANA to create registries as
> needed and record these assignments.  Everything that IANA needs MUST be
> _included_ (not summarized) here.
> 
> Section 4.2 - "Three consecutive CC packets losses ..." doesn't make sense -
> probably should be "three consecutive lost CC packets ..."
> 
> ----
> 
> Section 4.3 - in the last sentence of the 2nd paragraph, "use" should be "uses"
> and "peform" should be "perform."
> 
> Also, "(original data traffic carried by LSP1)" and "(data traffic carried by LSP1)"
> should both just be "Payload" to be consistent with Figure 2.  The same also
> applies (to "Original data traffic) later in section 4.3.1.1, (to "original data traffic
> carried by LSP1" and "data traffic carried by LSP1") in section 4.3.1.2 and
> anywhere else where you use similar phrasing.
> 
> "... and reach the egress node" should be "... and reaches the egress node"
> (though "... and arrives at the egress node" may be a slightly better wording).
> 
> may be (and often is) plural, it is a group name (like "herd") so if it is in the
> singular form, that is what the verb ("leave" in this case) has to match.
> 
> Similar for the case with "... following sections describes ..." (should be "...
> following sections describe ...").
> 
> ----
> 
> Top of page 26, 2nd paragraph - "resulting the ring being ..." should probably be
> "resulting in the ring being ..."
> 
> ----
> 
> There are a great many places where "Pass-trough" should probably be
> "Pass-through" in sections under 5.2 (i.e. 5.2.2 through 5.2.5).
> 
> ----
> 
> PS - As a general (but mostly irrelevant) observation, I found it amusing that the
> acronym chosen for this specification (MSRP) just happens to be the common
> acronym in use for decades in the US to mean "Manufacturer's Suggested Retail
> Price."
> 
> :-)
> 
> Subject: [mpls] Working Group Last Call for
> (mailto:[email-masked]).
> have on this Internet Draft, even if you do not support progressing this draft
> further.
>

---

From: Eric Gray <[email-masked]>
Date: Wed, 31 Aug 2016 06:48:04 +0000

This WG Last Call is closed; there seemed to be support for - and no objections to - progressing the draft.  I have discussed this with the Working Group Chairs and they agree that there seems to be rough consensus to progress the draft.

Authors, please address the comments made on the mailing list and post a revised version for forwarding by the WG chairs to the IESG.

--
Eric

MPLS Working Group,

version 02.

They can be found here:

IPR disclosures.

--

Eric Gray