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

From: Huub van Helvoort <[email-masked]>
Date: Mon, 31 Oct 2016 23:51:13 +0100

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