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

[Eric Gray <[e-mail]>]

Sounds like we are reaching convergence.  Please post a revision as described.  Thanks!
--
Eric

From: Huub van Helvoort [mailto:[e-mail]]
Sent: Monday, October 31, 2016 6:51 PM
To: Eric Gray <[e-mail]>
Cc: [e-mail]; [e-mail]; [e-mail]
Subject: Response: Working Group Last Call for draft-ietf-mpls-tp-shared-ring-protection-02
Importance: High

Hello Eric,
You write:

                The document is much improved, but not quite there yet.
[Huub]  Thank you Eric for the thorough review.
                I have noticed a few NITs in the revised wording that can be dealt with via instructions to the RFC Editor (no action required by the Authors or Contributors unless addressing other issues anyway).
[Huub]  OK. no revision needed.
                I have a pair of minor questions: you now define a “Ring Node” as a node that actively participates in ring protection; this suggests that there might be nodes that either passively participate in ring protection, or do not participate in ring protection – so

-          is it possible for any such node to exist in a ring topology and still have ring protection work correctly?

-          are their well understood requirements of such nodes (my concern is to understand if there is anything that such a node might do that would conceal the link status between Ring Nodes)?
I strongly suspect that there is no hole here, but just want to make sure.
[Huub] All nodes in the ring are Ring nodes and MUST actively participate in
the ring protection. Additional text should make this clear.
[Huub] this will require a revision.


I have had some difficulty in determining if the comments I made earlier are entirely addressed by the changes you’ve made.  I interleave the comments I made and the way they seem to have been addressed below (hopefully nobody in this discussion suffers from red-green color blindness).
[Huub] unfortunately I do have a slight red-green defect, but the difference in
contrast allowed me to see the difference.

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

-3- the concern regarding the presence of different protection modes is
       removed by including a statement that all nodes in the ring MUST be
       provisioned in the same protection mode.
       To detect possible misconfiguration two bits are used in the RPS PDU
       that identify the protection switching mode which allows detection of
       any mis-configuration during provisioning.

This change fully addresses this ambiguity.  I would note that what you actually said in the draft is not quite the same as what you say in the mail below (repeated directly above), because – in the draft – it says that rings on a node “MUST use” (as opposed to “MUST be provisioned in”).  This is a minor point, however, and the draft wording is most likely more correct.
[Huub] OK, no revision needed.

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

-2- the referencing to RFC5654 has been improved

What it looks like in comparing the two documents is that – for your first step – you have removed the summary versions of the optimization requirements.  This is one (and most likely the simplest) way to get rid of inconsistencies.

You then go on to be a lot more explicit about which requirements this document is specifically addressing.  This fully addresses my comments with respect to RFC 5654.  It also – incidentally – eliminates a few grammatical NITs.

Note that this took some looking into, because (for instance) of the way that you have re-ordered sections 2 and 3, thus requiring a detailed review of both the old and the new text to determine the real changes.
[Huub] OK, resolved, no revision needed.

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


As near as I can tell, you did not identify how the above comment was addressed.  The wording appears to have been changed in minor ways.  From this set of minor changes, it looks as if we are not necessarily talking about the same thing as “a port.”  I think I understand what you mean in your wording, now, so I feel this comment is adequately addressed by the minor changes made.
[Huub] OK, no revision needed.


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.

Again, as near as I can tell, you did not identify how this comments was addressed.  However, I see that you now use both notations, making it at least obvious how one maps to the other, therefore I feel that this comment is fully addressed by your changes.
[Huub] OK, no revision needed.

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.

I see no indication that this comment has been addressed.  Most of it was intended as a suggestion, hence addressing those portions was not absolutely necessary.

I do, however, feel that section 2 (the re-ordered section that now addresses Notation) should include the way that tunnel naming in section 4.1.1 is derived (see the accentuated part of the comment repeated above).
[Huub] the Ring Tunnel naming convention should be added to section 2.
this requires a revision


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.

Again, as near as I can tell, you did not identify how this comments was addressed.  However, I see that the wording in question has been clarified.  This comment is fully addressed by your changes.
[Huub] OK, no revision needed.

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.

Again, as near as I can tell, you did not identify how this comments was addressed.  However, I see that you removed the word “end” and this should reduce the possibility for misinterpretation. This comment is adequately addressed by the minor change made.
[Huub] OK, no revision needed.

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

This was (in part) addressed by the addition of a requirement for consistent protection modes in a ring.  With that, and the change from “can” to “MUST” and other clarifying text throughout section 4, this comment is fully addressed by your changes.
[Huub] OK, no revision needed.
There were a number of relatively minor comments/questions which I don’t believe have been answered or addressed:



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?"

Here it would be good to know if there is a difference between a “span” and a “link.”  If there is no difference, then why not use the same term?  If there is a difference, perhaps it should be defined in the terminology section.  Based on usage in the draft, I suspect there is a difference between a “span” and a “link.”
[Huub] because there is no difference between "span" and "link" I suggest to
replace all occurrences of "span" by "link". A revision is needed.

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


The set of questions above is both complicated and inter-related.  The main thrust of the issue is that Ring Nodes only know what they know about the state of the ring based on the most recently received set of RPS messages.  This information may be temporarily incorrect and there is no way for a Ring Node to know if this is (or is not) the case.  I am not certain that the text in section 5 properly addresses how a deterministic state is necessarily arrived at independent of the order in which RPS messages are received.

By having a strict prioritization between state indications, it should be the case that the “final” state arrived at would be deterministic based on an assumption that the RPS messages will provide a consistent “state of the ring” within some period of time (because all ring nodes should agree as to which indication has the highest priority).
[Huub] we understand your point, we propose to remove the sentence:
"nodes do not preempt existing RPS requests unless they have a higher-priority RPS request."
because it is actually the same as:
"Ring switches MUST be preempted by higher priority RPS requests?"
also we suggest to replace the sentence:
"knowledge of the state of the ring"
by "use their ring map to determine the state of the ring"
A revision is needed.


=====

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?
As near as I can tell, none of these comments and/or questions have resulted in any changes.
Possibly the questions were answered in separate E-Mail which I have not yet uncovered.  While I believe I know what (at least some of) these terms mean, it is important to have this knowledge exist somewhere other than in the minds of experienced operators and people (vendors, operators and standards developers) with SONET/SDH experience/awareness.
If the authors all feel that there is no ambiguity, need for further clarification or related issues with the way these issues are  currently addressed/specified, I am happy to withdraw these questions and comments at least until such time as I have a better understanding of the issues.
[Huub] if the MS (manual switch) comes from the same node, clockwise and
anticlockwise it should become active, if there is no higher priority  request
active. If they come from different ring nodes they should be ignored.
[Huub] this clarification requires a revision


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.
This comment was fully addressed in this version.
[Huub] OK, no revision needed.
Many NITs were not addressed:
"()" Are called "parentheses" - now in section 2 (previously in section 3).

"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

...").
So far, these are minor issues, and may be corrected by the RFC Editor.
[Huub] OK, we can leave it to RFC editors, but since a revision is needed we can fix these
As a question on how the following NIT was addressed:

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."
The text now reads: “protect both link failures and node failures.”
Intuitively, this seems incorrect, because (intuitively) we don’t “protect” failures (we protect services against failures).  I assume the authors chose this phrasing because (in this context) the meaning for “protect” differs slightly from the intuitive English meaning.  Is this correct?  If so, we might want to add “Protect” to the terminology section as well.
[Huub] the proper text is: "protect against both link failures and node failures"
a revision is needed


Section 4.3.2.1 - in the 4th sentence, "Rap_D" should be "RaP_D."
While this one may be corrected via instructions to the RFC Editor, this is not so much a spelling error as a Notation error and may not otherwise be picked up by the RFC Editor.
[Huub] can be changed in a revision

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

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

ring being ..." (now the 4th paragraph, from the top of page 25).
[Huub] indeed, we agree, it can be fixed in a revision

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

To be more specific, the 1st sentence in the section “A node in the switching state MUST source RPS request to adjacent node with its highest RPS request code in both directions when it detects a failure or receives an external command.”  When sourcing RPS messages in both directions I believe more than one node will be the target for the RPS request (except in the trivial case of a “ring” consisting of two nodes).
[Huub] I suggest to remove "to adjacent node" from the sentence, because the RPS request
has to be forwarded to all ring nodes.
This requires a revision


On the last line on page 28, "Node" should probably be "The node." (Now the last line before section 5.1.3.3 – though still on page 28)
A few NITs I missed previously:
In section 4.3, paragraph at the top of page 10, “impaced” should be “impacted” and “perform switching” should be “performs switching” (“the ingress node … performs switching …”).
[Huub] these can be fixed in a revision (or by the RFC editors).
--
Eric
We hope that we addresses all your comments this time.
Because text has to be added/changed we think a revision is required.

Best regards, Huub