Subject: Re: [RTG-DIR] Routing Area Directorate Review of draft-ietf-mpls-tp-ring-protection-05

From: Eric Gray <[email-masked]>
Date: Tue, 14 May 2013 16:24:09 +0000

Yaacov,

                I didn't see this response until I specifically went looking for it.

                Sorry to have taken so long to get back to you.

                For the most part, your counter proposal is good enough.  See my
replies in line below...

                Thanks for addressing most of my comments.

--
Eric

From: Yaacov Weingarten [mailto:[email-masked]]
Sent: Wednesday, April 17, 2013 8:56 AM
To: Eric Gray
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: Routing Area Directorate Review of draft-ietf-mpls-tp-ring-protection-05
Importance: High

Eric, hi

Thank you for your review and very in-depth comments, I will try to address some of them inline below (indicated by "yw>>" before the comment.

Hope this helps,
yaacov
On Tue, Apr 16, 2013 at 5:18 PM, Eric Gray <[email-masked]<mailto:[email-masked]>> wrote:
Hello,

I have been selected as the Routing Directorate reviewer for this draft.

The Routing Directorate seeks to review all routing or routing-related drafts
as they pass through IETF last call and IESG review, and sometimes on special
request. The purpose of the review is to provide assistance to  the Routing ADs.

For more information about the Routing Directorate, please see
http://www.ietf.org/iesg/directorate/routing.html

Although these comments are primarily for the use of the Routing ADs, it would
be helpful if you could consider them along with any other comments that you
receive, and strive to resolve them through discussion or by updating the draft.

Document: http://tools.ietf.org/html/draft-ietf-mpls-tp-ring-protection-05
Reviewer: Eric Gray
Review Date: 17 April, 2013
Intended Status: Informational

There is at least one major issue with this document, as it is now written.

Comments/Questions:
=================

The "disclaimer" at the end of the Introduction misses a case related to the cases
excluded from the scope of this document - which is itself presumably out of scope.

yw>> Assume that you are referring to the disclaimer at the end of section 1.1 (as opposed to the one at the end of section 1)

I did not refer to section 1, I referred to the Introduction.  Since this was the name of
section 1, I thought that referring to it by name would be sufficiently unambiguous,
since all of section 1 is the Introduction...

The text currently talks to protection of a path prior to entry to the ring, or after
exit from the ring.  The missing case is when the path is part of a protected service
that involves one or more alternative paths external to the ring.  It is not difficult
to think of a scenario in which a protection event outside of the ring will require
that data forwarded across the ring will need to enter the ring at a different point,
leave the ring at a different point, or both.

While this would seem to impact the protection of the ring itself (possibly requiring
setup of similar protection for the new path traversing the ring), it should be quite
easy to represent such an occurrence as a set of discrete event/operations that
would not be significantly different when compared to initial setup of protection for
the previous path in the ring.

If for any reason folks feel that this may not be the case under some circumstances
this document should either address those cases or explicitly state that they will not
be addressed by this document.

Alternatively, the issue may be addressed by simply removing the 2nd sentence of
the "disclaimer" paragraph, or the cases explicitly stated should be expressed as
"examples."

yw>> How about if I change the text of the second sentence to read:  "Protection triggers on the transport path
   prior to the ring ingress node or beyond the egress nodes may be protected by some other mechanism."?

Fine.

-------------------------------------------------------------------------------------------------------------

Bullet 4 of section 1.3 is confusing as written.  The meaning of "LI" is clear enough,
but "LE" presents some problems.  Suppose that PHP is used; in this case, there is
no label "expected" at the egress point from the ring (although a label may be
present and will be used by the LSR at that point, that label may not always be the
same label).

Is PHP never permitted?

yw>> regarding this, I seem to recall such a discussion regarding MPLS-TP and PHP.  However, in any case if there is no such label, why couldn't LE=null? It is just being presented for discussion, not as an actual label.

Okay.  Even as an item for discussion, the text seems to imply that one would always find a label.
With PHP, the egress LSR can signal that PHP is to e used by using the appropriate NULL label.
However, this label never actually shows up on the wire, so the egress LSR does not expect to
see it.

My concern is that someone reading this may look to see this as an object to be managed.  I
suppose that it could be read as NULL, so that may not be an issue.

And any LSR that signals PHP and then expects to see a specific label is a darwin candidate.

So, fine.

Also, under what circumstances would the ring egress point SPME exit LSR not
be the same?  Based on subsequent reading, I believe this would be the case for
use of an SPME to provide "Wrapping" protection - it would probably therefore
be a good idea to either say something to this effect (if that is the case) or provide
a forward reference (to section 2.3.2, 2.3.3 and 2.3.4, for example, or possibly
just to section 2.3).

I would suggest adding a sentence to this bullet, along the lines of:

"See section 2.3 for examples of where the SPME egress and ring exit might not
be the same."

yw>> How about if I add ", for example as described in Section 2.3" to the parenthetical phrase?

Fine.

-------------------------------------------------------------------------------------------------------------

Section 2 appears to ignore 1+1 protection, which would (similar to "Steering")
use pre-established protection paths from an ingress LSR/node to each egress
LSR/node but would send that traffic both ways at all times.

The main differences between this approach and Steering are:

o             the need to notify the ingress node is eliminated as a consideration for
                protection switching latency
o             there is (therefore) no reliance on the existence of a failure detection
                method that is able to notify the ingress of a failure in the ring
o             double bandwidth is required

This is carried forward in all subsequent sections/subsections.

yw>> 1+1 protection is a linear protection methodology, and Section 2 is describing basic Transport Network ring protection as defined in  the ITU - which include Steering and Wrapping.  1+1 does not seem to be popular in rings, since historically SDH seemed to shun this alternative. We do reference 1+1 transmission in section 3.2 and in the conclusions.

Your recollection of ring protection schemes is probably far fresher than mine.  I distinctly recall
ring protection methodologies that provide hitless protection by always sending traffic both
ways around the ring.  In fact, it is hard for me to imagine how one could get hitless protection
without this sort of scheme.

Because this requires sending traffic on both the working and protection path, it is 1+1 and it
requires double bandwidth.

I am not certain that ignoring 1+1 protection in section 2 and lightly glossing it over in later
sections addresses my comment, but - if it is too late at this point to fix it - then I imagine
we will just have to live with it.

-------------------------------------------------------------------------------------------------------------

Sections 2.1 and 2.2 do not exactly provide an "apples-to-apples" comparison
basis in the bullets relating to "considerations" in each subsection.  In order to
allow this comparison, both sections would need to provide an indication of the
order of protection paths required in a protection domain.

Because - in the "Wrapping" case - it is necessary to provide protection SPME
for each node and link (in a ring the number of links is exactly the same as the
number of nodes), the number of protection SPME is O(2N).

For the "Steering" case, however, it is necessary to provide protection SPME
for each ingress node to each egress node (except for the last one) - which is
O(N^2).  This statement is actually made in the introductory text in section 2.4.

I would suggest either adding a bullet in section 2.2 and including forward
references in these bullets to the analysis in section 2.4, or removing the bullet
in section 2.1.

yw>> Could you please specify which bullet you are suggesting to delete? Thanx

I hope you worked this out on your own.  The target bullet is both obvious and unambiguous,
given the first paragraph of this comment.  I don't even have to look back at the draft to see
it in context.

Ths two section compare aspects of protection schemes.  One apparently includes a statement
about the order of the number of required protection paths, while the other does not.

The comment suggests either adding the missing information as a bullet in section 2.2, or
removing the corresponding bullet in section 2.1.

Are you saying that you cannot determine from my comment which bullet that is?

... now looking at the latest draft ...

I see (based on the -06 version) that you did not figure this out.

Look at the bullets in section 2.1.  Then look at the bullets in section 2.2.  What you should see
is that the 2nd bullet in section 2.2 has no counterpart in section 2.2.

While this is true of other bullets as well, the comment I made shows that it is relatively easy
to determine the (order of the) number of protection paths required to use steering as the
protection scheme.  For other bullets, I can see why they were omitted.  A bullet that talks
about the order of the number of protection paths required for steering is simply not there,
for no good reason that I can determine.

-------------------------------------------------------------------------------------------------------------

Section 2.3 appears to assume that the desired protection scheme will be based
on "Steering" rather than "Wrapping."  This assumption is made without any
effort/analysis to justify why this assumption is made (at least as far as I can see).

If that is the intention, minimally, section 2.3 should start with a statement that
this is the assumption made.

Reading further, however, subsequent subsection 2.3.2 describes how the SPME
concept - as outlined in the introductory text of section 2.3 - may be used for the
"Wrapping" approach.

The confusion arises as a result of figure 3 and the text that describes it in the
preceding paragraph, as this figure/text is what most contributes to an impression
that an SPME would start at the ingress and end at an egress.

I would suggest that this figure and the preceding paragraph would find a better
home on section 2.3.1.  This would also align subsections of section 2.3 better as
there is a similar figure in section 2.3.2, 2.3.3 and 2.3.4.

yw>> Will move the paragraph and figure, as you suggest.

-------------------------------------------------------------------------------------------------------------

The last paragraph in introductory text in section 2.3 (immediately prior to the
start of section 2.3.1) appears to ignore the case where the egress LSR would
use labels to "steer" delivery of labeled packets it receives over the SPME to
specific egress ports (of the egress LSR).

These labels would most likely not be a part of the label stack received by the
ingress LSR (there is no need for these labels to be known outside of the ring)
and would have to be pushed onto the stack before pushing on the label for an
SPME to the egress LSR/node.

yw>> Do you have a suggestion on how better to include this consideration?

For thatI need to re-read the draft.

... now looking at the latest draft ...

Okay, the last paragraph actually ignores a few things:
1) If the ingress and egress LSRs on the ring are adjacent nodes on the ring, no swapping occurs.
2) in any case where there are more than 3 LSRs involved in the LSP at the hierarchical layer of
    the SPME, there will be N-2 label swaps that ultimately result in the LE label attached to the
    PDU arriving at the egress LSR.
3) the point I was trying to make - which was that the ingress LSR may have been given a label
    stack (which would not be what you refer to as "LI", and would consist of more than one label
    where only the top level label would be seen anywhere in the LSP but at the ingress, where it
     is pushed on, and the egress LSR).

In re-looking at this, it seems to me that you are trying to avoid this level of detail, so it would
be sufficient to "qualify" this description by inserting "in the simplest case" before "packets that
arrive..."

-------------------------------------------------------------------------------------------------------------

I believe the text in the last paragraph of section 2.3.4 is incorrect in stating that
protected traffic might not share the same protection path in both directions.

If both LSR-B and LSR-F detect that LSR-A is not available, then both will use the
protection SPME between LSR-B and LSR-F.

If both LSR-A and LSR-E detect that LSR-F is not available, then both will use the
protection SPME between LSR-A and LSR-E.

If both LSR-A and LSR-F detect that the link between them is not available, then
both will use the protection SPME between them.

All that is required is that both LSRs in each case agree as to the nature of the
failure (node or link) - which may be easily and consistently determined by
monitoring the status of the working and protection SPME.

While it is possible for the end-point LSRs in each case to have an inconsistent
view of the nature of the failure, this inconsistency should be short lived (based
on the periodicity of OAM monitoring of SPMEs).

Depending on the OAM monitoring periodicity used - and the length of links in
the ring - this inconsistency may exist for a period of time that is less than the
latency to be expected for "Steering" based protection.

Note that this is a major issue with the current text as it impacts on analysis in
subsequent section 2.4 and the conclusion/recommendations of this document.

yw>> This statement is the result of review comments that we received during an earlier review of the document, and I am wary of removing it from the document at this late stage in the review process.  In any case, there are other considerations for limiting both types of protection.  I am sure that your analysis is correct although I am not sure that I understand your emphatic objection to the text and how it is related to the analysis in section 2.4.

The analysis appears to be missing information.  Yet the analysis is presumably the basis on
which the conclusions of the draft are based.

However, if the WG feels that the conclusions of this draft are correct, then there may not
be much point in addressing this comment.

-------------------------------------------------------------------------------------------------------------

The analysis in section 2.4 is incomplete or based on an incorrect assertion made
in section 2.3.4.

If the alternative suggested in section 2.3.4 were used, the number of SPME that
will be required would be O(4N) - which is still O(N) and would be less than O(N^2)
for fewer than the 16-node limit assumption made for the analysis.

yw>> This is correct and is certainly correct when the comparison is between O(2N) and O(N^2).  Therefore whether the statement (reiterated in parenthesis here) is correct or not does not really affect the conclusions.  This is based on the simplicity of Steering and the avoidance of wasted resources by transmitting the traffic twice over certain links.

Fine

-------------------------------------------------------------------------------------------------------------

In the 1st sentence of the last paragraph in the introductory text of section 2.4,
the sentence mentions the use of additional resources but does not mention the
additional latency.

Is there any reason for the omission?

yw>> not really

I suggest removing the text in this sentence that starts with "even though" as
it might otherwise be necessary to attempt an exhaustive list of detractions.

yw>> I have no problem with this suggestion

-------------------------------------------------------------------------------------------------------------

Also in the last paragraph of the introductory text in section 2.4, I imagine that
the case where one or more pairs of SPME may be eliminated because of LSRs
that are not ingress-egress pairs is most likely of trivial value in any deployment
involving a ring topology.

Perhaps the last sentence in the last paragraph of this text in section 2.4 could be
removed?

yw>> Again, I have no problem with this

NITs:
====

In the Introduction section, 5th bullet in (or after) the 2nd paragraph -

   " Impact of signaling and routing information exchanged during
      protection, in presence of control plane."

- the phrase "in presence of control plane" should probably be "in the
presence of a control plane."

yw>> will fix

-------------------------------------------------------------------------------------------------------------

In the 2nd bullet in section 2.1, I believe it is the case that O(2N) = O(N).

yw>> while this is true, I think it is significant to mention the 2N

-------------------------------------------------------------------------------------------------------------

In the 1st paragraph of section 2.3.1, where it says "there is always an alternative
path ..." - at the SPME level (as described in this document), there's always exactly
one  alternative path.
yw>> This is not 100% true.  What is true is that there is exactly on alternative path within the ring (there may be additional alternatives that go outside the ring). This is why I did not originally add the "exactly" in the first place.

Paths outside of the ring are explicitly out-of-scope.  However, this is fine.
-------------------------------------------------------------------------------------------------------------

In the 1st bullet in section 2.4, I believe it is the case that O(2N^2) = O(N^2).

yw>> see above, same applies to next statement.

-------------------------------------------------------------------------------------------------------------

In the 1st and 2nd bullets in section 2.4, I believe it is the case that O(2N) = O(N).
-------------------------------------------------------------------------------------------------------------

--
Thanx and BR,
yaacov

Still looking for new opportunity

---

From: Yaacov Weingarten <[email-masked]>
Date: Tue, 21 May 2013 10:15:38 +0300

Eric, hi

I guess I am happy to say that this is out of my hands now as the document
has been approved by the IESG. Unless you think that these issues are
critical, I do not think that I can address them without approval from the
ADs.

If you know of a different process, I am willing to be enlightened!

Thanx anyway,
yaacov

On Tue, May 14, 2013 at 7:24 PM, Eric Gray <[email-masked]> wrote:

>  Yaacov,****
>
> ** **
>
>                 I didn't see this response until I specifically went
> looking for it.****
>
> ** **
>
>                 Sorry to have taken so long to get back to you.****
>
> ** **
>
>                 For the most part, your counter proposal is good enough.
> See my****
>
> replies *in line below…*****
>
> ** **
>
>                 Thanks for addressing most of my comments. ****
>
> ** **
>
> --****
>
> Eric****
>
> ** **
>
> *From:* Yaacov Weingarten [mailto:[email-masked]]
> *Sent:* Wednesday, April 17, 2013 8:56 AM
> *To:* Eric Gray
> *Cc:* [email-masked];
> [email-masked]; [email-masked]
> *Subject:* Re: Routing Area Directorate Review of
> draft-ietf-mpls-tp-ring-protection-05
> *Importance:* High****
>
> ** **
>
> Eric, hi****
>
>  ****
>
> Thank you for your review and very in-depth comments, I will try to
> address some of them inline below (indicated by "yw>>" before the comment.
> ****
>
>  ****
>
> Hope this helps,****
>
> yaacov****
>
> On Tue, Apr 16, 2013 at 5:18 PM, Eric Gray <[email-masked]> wrote:
> ****
>
> Hello,****
>
>  ****
>
> I have been selected as the Routing Directorate reviewer for this draft. *
> ***
>
>  ****
>
> The Routing Directorate seeks to review all routing or routing-related
> drafts ****
>
> as they pass through IETF last call and IESG review, and sometimes on
> special ****
>
> request. The purpose of the review is to provide assistance to  the
> Routing ADs. ****
>
>  ****
>
> For more information about the Routing Directorate, please see ****
>
> http://www.ietf.org/iesg/directorate/routing.html****
>
>  ****
>
> Although these comments are primarily for the use of the Routing ADs, it
> would ****
>
> be helpful if you could consider them along with any other comments that
> you ****
>
> receive, and strive to resolve them through discussion or by updating the
> draft. ****
>
>  ****
>
> ****
> Reviewer: Eric Gray****
> Review Date: 17 April, 2013****
>
> Intended Status: Informational****
>
>  ****
>
> ****
>  ****
> Comments/Questions:****
> =================****
>  ****
> The "disclaimer" at the end of the Introduction misses a case related to
> the cases****
>
> excluded from the scope of this document – which is itself presumably out
> of scope.  ****
>
>  ****
>
> yw>> Assume that you are referring to the disclaimer at the end of section
> 1.1 (as opposed to the one at the end of section 1) ****
>
> ** **
>
> *I did not refer to section 1, I referred to the Introduction.  Since
> this was the name of*
>
> *section 1, I thought that referring to it by name would be sufficiently
> unambiguous,*
>
> *since all of section 1 is the Introduction…*
>
>   ****
>
>  ****
>
> The text currently talks to protection of a path prior to entry to the
> ring, or after ****
>
> exit from the ring.  The missing case is when the path is part of a
> protected service****
>
> that involves one or more alternative paths external to the ring.  It is
> not difficult****
>
> to think of a scenario in which a protection event outside of the ring
> will require****
>
> that data forwarded across the ring will need to enter the ring at a
> different point,****
>
> leave the ring at a different point, or both.****
>
>  ****
>
> While this would seem to impact the protection of the ring itself
> (possibly requiring****
>
> setup of similar protection for the new path traversing the ring), it
> should be quite****
>
> easy to represent such an occurrence as a set of discrete event/operations
> that ****
>
> would not be significantly different when compared to initial setup of
> protection for****
>
> the previous path in the ring.****
>
>  ****
>
> If for any reason folks feel that this may not be the case under some
> circumstances****
>
> this document should either address those cases or explicitly state that
> they will not****
>
> be addressed by this document.****
>
>  ****
>
> Alternatively, the issue may be addressed by simply removing the 2ndsentence of
> ****
>
> the "disclaimer" paragraph, or the cases explicitly stated should be
> expressed as****
>
> "examples."****
>
>  ****
>
>  yw>> How about if I change the text of the second sentence to read:
> "Protection triggers on the transport path
>    prior to the ring ingress node or beyond the egress nodes may be
> protected by some other mechanism."?****
>
> ** **
>
> *Fine.*
>
>   ****
>
>
> ****
>  ****
> Bullet 4 of section 1.3 is confusing as written.  The meaning of "LI" is
> clear enough,****
>
> but "LE" presents some problems.  Suppose that PHP is used; in this case,
> there is ****
>
> no label "expected" at the egress point from the ring (although a label
> may be ****
>
> present and will be used by the LSR at that point, that label may not
> always be the****
>
> same label).****
>
>  ****
>
> Is PHP never permitted?****
>
>  ****
>
>  yw>> regarding this, I seem to recall such a discussion regarding
> MPLS-TP and PHP.  However, in any case if there is no such label, why
> couldn't LE=null? It is just being presented for discussion, not as an
> actual label. ****
>
> ** **
>
> *Okay.  Even as an item for discussion, the text seems to imply that one
> would always find a label.*
>
> *With PHP, the egress LSR can signal that PHP is to e used by using the
> appropriate NULL label.*
>
> *However, this label never actually shows up on the wire, so the egress
> LSR does not expect to*
>
> *see it.*
>
> * *
>
> *My concern is that someone reading this may look to see this as an
> object to be managed.  I*
>
> *suppose that it could be read as NULL, so that may not be an issue.*
>
> * *
>
> *And any LSR that signals PHP and then expects to see a specific label is
> a darwin candidate.*
>
> * *
>
> *So, fine.*
>
>   ****
>
>  ****
>
> Also, under what circumstances would the ring egress point SPME exit LSR
> not****
>
> be the same?  Based on subsequent reading, I believe this would be the
> case for****
>
> use of an SPME to provide "Wrapping" protection – it would probably
> therefore****
>
> be a good idea to either say something to this effect (if that is the
> case) or provide****
>
> a forward reference (to section 2.3.2, 2.3.3 and 2.3.4, for example, or
> possibly****
>
> just to section 2.3).****
>
>  ****
>
> I would suggest adding a sentence to this bullet, along the lines of:****
>
>  ****
>
> "See section 2.3 for examples of where the SPME egress and ring exit might
> not****
>
> be the same."****
>
>  ****
>
>  yw>> How about if I add ", for example as described in Section 2.3" to
> the parenthetical phrase?****
>
> ** **
>
> *Fine.*
>
>   ****
>
>
> ****
>  ****
> Section 2 appears to ignore 1+1 protection, which would (similar to
> "Steering")****
>
> use pre-established protection paths from an ingress LSR/node to each
> egress****
>
> LSR/node but would send that traffic both ways at all times.  ****
>
>  ****
>
> The main differences between this approach and Steering are:****
>
>  ****
>
> o             the need to notify the ingress node is eliminated as a
> consideration for ****
>
>                 protection switching latency****
>
> o             there is (therefore) no reliance on the existence of a
> failure detection ****
>
>                 method that is able to notify the ingress of a failure in
> the ring****
>
> o             double bandwidth *is* required ****
>
>  ****
>
> This is carried forward in all subsequent sections/subsections.****
>
>  ****
>
>  yw>> 1+1 protection is a linear protection methodology, and Section 2 is
> describing basic Transport Network ring protection as defined in  the ITU -
> which include Steering and Wrapping.  1+1 does not seem to be popular in
> rings, since historically SDH seemed to shun this alternative. We do
> reference 1+1 transmission in section 3.2 and in the conclusions.****
>
> ** **
>
> *Your recollection of ring protection schemes is probably far fresher
> than mine.  I distinctly recall*
>
> *ring protection methodologies that provide hitless protection by always
> sending traffic both*
>
> *ways around the ring.  In fact, it is hard for me to imagine how one
> could get hitless protection*
>
> *without this sort of scheme.*
>
> * *
>
> *Because this requires sending traffic on both the working and protection
> path, it is 1+1 and it*
>
> *requires double bandwidth.*
>
> * *
>
> *I am not certain that ignoring 1+1 protection in section 2 and lightly
> glossing it over in later*
>
> *sections addresses my comment, but – if it is too late at this point to
> fix it – then I imagine *
>
> *we will just have to live with it.*
>
>   ****
>
>
> ****
>  ****
> Sections 2.1 and 2.2 do not exactly provide an "apples-to-apples"
> comparison****
>
> basis in the bullets relating to "considerations" in each subsection.  In
> order to ****
>
> allow this comparison, both sections would need to provide an indication
> of the****
>
> order of protection paths required *in a protection domain*. ****
>
>  ****
>
> Because – in the "Wrapping" case – it is necessary to provide protection
> SPME****
>
> for each node and link (in a ring the number of links is exactly the same
> as the ****
>
> number of nodes), the number of protection SPME is O(2N).****
>
>  ****
>
> For the "Steering" case, however, it is necessary to provide protection
> SPME****
>
> for each ingress node to each egress node (except for the last one) –
> which is****
>
> O(N^2).  This statement is actually made in the introductory text in
> section 2.4.****
>
>  ****
>
> ****
> references in these bullets to the analysis in section 2.4, or removing
> the bullet****
>
> in section 2.1.****
>
>  ****
>
>  yw>> Could you please specify which bullet you are suggesting to delete?
> Thanx ****
>
> ** **
>
> *I hope you worked this out on your own.  The target bullet is both
> obvious and unambiguous,*
>
> *given the first paragraph of this comment.  I don't even have to look
> back at the draft to see*
>
> *it in context.*
>
> * *
>
> *Ths two section compare aspects of protection schemes.  One apparently
> includes a statement*
>
> *about the order of the number of required protection paths, while the
> other does not.*
>
> * *
>
> *The comment suggests either adding the missing information as a bullet
> in section 2.2, or *
>
> *removing the corresponding bullet in section 2.1.*
>
> * *
>
> *Are you saying that you cannot determine from my comment which bullet
> that is?*
>
> * *
>
> *… now looking at the latest draft …*
>
> * *
>
> *I see (based on the -06 version) that you did not figure this out.*
>
> * *
>
> *Look at the bullets in section 2.1.  Then look at the bullets in section
> 2.2.  What you should see*
>
> *is that the 2nd bullet in section 2.2 has no counterpart in section 2.2.*
>
> * *
>
> *While this is true of other bullets as well, the comment I made shows
> that it is relatively easy*
>
> *to determine the (order of the) number of protection paths required to
> use steering as the*
>
> *protection scheme.  For other bullets, I can see why they were omitted.
> A bullet that talks*
>
> *about the order of the number of protection paths required for steering
> is simply not there,*
>
> *for no good reason that I can determine.*
>
>   ****
>
>
> ****
>  ****
> Section 2.3 appears to assume that the desired protection scheme will be
> based****
>
> ****
> effort/analysis to justify why this assumption is made (at least as far as
> I can see). ****
>
>  ****
>
> If that is the intention, minimally, section 2.3 should start with a
> statement that ****
>
> this is the assumption made.****
>
>  ****
>
> Reading further, however, subsequent subsection 2.3.2 describes how the
> SPME****
>
> concept – as outlined in the introductory text of section 2.3 – may be
> used for the****
>
> "Wrapping" approach.****
>
>  ****
>
> The confusion arises as a result of figure 3 and the text that describes
> it in the ****
>
> preceding paragraph, as this figure/text is what most contributes to an
> impression****
>
> that an SPME would start at the ingress and end at an egress.****
>
>  ****
>
> I would suggest that this figure and the preceding paragraph would find a
> better ****
>
> home on section 2.3.1.  This would also align subsections of section 2.3
> better as ****
>
> there is a similar figure in section 2.3.2, 2.3.3 and 2.3.4.****
>
>  ****
>
>  yw>> Will move the paragraph and figure, as you suggest. ****
>
>   ****
>
>
> ****
>  ****
> The last paragraph in introductory text in section 2.3 (immediately prior
> to the****
>
> start of section 2.3.1) appears to ignore the case where the egress LSR
> would****
>
> use labels to "steer" delivery of labeled packets it receives over the
> SPME to****
>
> specific egress ports (of the egress LSR).  ****
>
>  ****
>
> These labels would most likely not be a part of the label stack received
> by the ****
>
> ingress LSR (there is no need for these labels to be known outside of the
> ring)****
>
> and would have to be pushed onto the stack before pushing on the label for
> an****
>
> SPME to the egress LSR/node.****
>
>   ****
>
> ****
> ** **
> *For thatI need to re-read the draft.*
>
> * *
>
> *… now looking at the latest draft …*
>
> * *
>
> *Okay, the last paragraph actually ignores a few things:*
>
> *1) If the ingress and egress LSRs on the ring are adjacent nodes on the
> ring, no swapping occurs.*
>
> *2) in any case where there are more than 3 LSRs involved in the LSP at
> the hierarchical layer of*
>
> *    the SPME, there will be N-2 label swaps that ultimately result in
> the LE label attached to the*
>
> *    PDU arriving at the egress LSR.*
>
> *3) the point I was trying to make – which was that the ingress LSR may
> have been given a label*
>
> *    stack (which would not be what you refer to as "LI", and would
> consist of more than one label *
>
> *    where only the top level label would be seen anywhere in the LSP but
> at the ingress, where it *
>
> *     is pushed on, and the egress LSR).*
>
> * *
>
> *In re-looking at this, it seems to me that you are trying to avoid this
> level of detail, so it would*
>
> *be sufficient to "qualify" this description by inserting "in the
> simplest case" before "packets that*
>
> *arrive…"*
>
> * *
>
> **
>
>
> ****
>  ****
> I believe the text in the last paragraph of section 2.3.4 is incorrect in
> stating that****
>
> protected traffic might not share the same protection path in both
> directions.****
>
>  ****
>
> If both LSR-B and LSR-F detect that LSR-A is not available, then both will
> use the****
>
> protection SPME between LSR-B and LSR-F.****
>
>  ****
>
> If both LSR-A and LSR-E detect that LSR-F is not available, then both will
> use the****
>
> protection SPME between LSR-A and LSR-E.****
>
>  ****
>
> If both LSR-A and LSR-F detect that the link between them is not
> available, then****
>
> both will use the protection SPME between them.****
>
>  ****
>
> All that is required is that both LSRs in each case agree as to the nature
> of the ****
>
> failure (node or link) – which may be easily and consistently determined by
> ****
>
> monitoring the status of the working and protection SPME. ****
>
>  ****
>
> While it is possible for the end-point LSRs in each case to have an
> inconsistent****
>
> view of the nature of the failure, this inconsistency should be short
> lived (based****
>
> on the periodicity of OAM monitoring of SPMEs).****
>
>  ****
>
> Depending on the OAM monitoring periodicity used – and the length of links
> in ****
>
> the ring – this inconsistency may exist for a period of time that is less
> than the ****
>
> latency to be expected for "Steering" based protection.****
>
>  ****
>
> *Note that this is a major issue with the current text as it impacts on
> analysis in*****
>
> *subsequent section 2.4 and the conclusion/recommendations of this
> document.*****
>
>  ****
>
>  yw>> This statement is the result of review comments that we received
> during an earlier review of the document, and I am wary of removing it from
> the document at this late stage in the review process.  In any case, there
> are other considerations for limiting both types of protection.  I am sure
> that your analysis is correct although I am not sure that I understand your
> emphatic objection to the text and how it is related to the analysis in
> section 2.4.****
>
> ** **
>
> *The analysis appears to be missing information.  Yet the analysis is
> presumably the basis on*
>
> *which the conclusions of the draft are based.*
>
> * *
>
> *However, if the WG feels that the conclusions of this draft are correct,
> then there may not*
>
> *be much point in addressing this comment.*
>
>   ****
>
>
> ****
>  ****
> The analysis in section 2.4 is incomplete or based on an incorrect
> assertion made****
>
> in section 2.3.4.****
>
>  ****
>
> If the alternative suggested in section 2.3.4 were used, the number of
> SPME that****
>
> will be required would be O(4N) – which is still O(N) and would be less
> than O(N^2)****
>
> for fewer than the 16-node limit assumption made for the analysis. ****
>
>  ****
>
>  yw>> This is correct and is certainly correct when the comparison is
> between O(2N) and O(N^2).  Therefore whether the statement (reiterated in
> parenthesis here) is correct or not does not really affect the
> conclusions.  This is based on the simplicity of Steering and the avoidance
> of wasted resources by transmitting the traffic twice over certain links.*
> ***
>
> ** **
>
> *Fine*
>
>   ****
>
>
> ****
>  ****
> In the 1st sentence of the last paragraph in the introductory text of
> section 2.4,****
>
> the sentence mentions the use of additional resources but does not mention
> the****
>
> additional latency.****
>
>  ****
>
> Is there any reason for the omission?****
>
>  ****
>
>  yw>> not really ****
>
>   ****
>
>  ****
>
> I suggest removing the text in this sentence that starts with "even
> though" as****
>
> it might otherwise be necessary to attempt an exhaustive list of
> detractions. ****
>
>  ****
>
>  yw>> I have no problem with this suggestion ****
>
>   ****
>
>
> ****
>  ****
> Also in the last paragraph of the introductory text in section 2.4, I
> imagine that****
>
> ****
> that are not ingress-egress pairs is most likely of trivial value in any
> deployment****
>
> involving a ring topology.  ****
>
>  ****
>
> Perhaps the last sentence in the last paragraph of this text in section
> 2.4 could be****
>
> removed?****
>
>  ****
>
>  yw>> Again, I have no problem with this ****
>
>   ****
>
>  ****
>
> NITs:****
>
> ====****
>
>  ****
>
> In the Introduction section, 5th bullet in (or after) the 2nd paragraph –
> ****
>
>  ****
>
>    " Impact of signaling and routing information exchanged during****
>
>       protection, in presence of control plane."****
>
>  ****
>
> - the phrase "in presence of control plane" should probably be "in *the* *
> ***
>
> presence of *a* control plane." ****
>
>  ****
>
>  yw>> will fix ****
>
>   ****
>
>
> ****
>  ****
> In the 2nd bullet in section 2.1, I believe it is the case that O(2N) =
> O(N).****
>
>   ****
>
> yw>> while this is true, I think it is significant to mention the 2N ****
>
>    ****
>
>
> ****
>  ****
> In the 1st paragraph of section 2.3.1, where it says "there is always an
> alternative****
>
> path …" – at the SPME level (as described in this document), there's
> always *exactly *****
>
> *one*  alternative path.****
>
>  yw>> This is not 100% true.  What is true is that there is exactly on
> alternative path within the ring (there may be additional alternatives that
> go outside the ring). This is why I did not originally add the "exactly" in
> the first place. ****
>
> ** **
>
> *Paths outside of the ring are explicitly out-of-scope.  However, this is
> fine.*
>
>
> ****
>  ****
> In the 1st bullet in section 2.4, I believe it is the case that O(2N^2) =
> O(N^2). ****
>
>  ****
>
>  yw>> see above, same applies to next statement. ****
>
>   ****
>
>
> ****
>  ****
> In the 1st and 2nd bullets in section 2.4, I believe it is the case that
> O(2N) = O(N). ****
>
>
> ****
>  ****
>  ****
>  ****
>  ****
> -- ****
> Thanx and BR,****
> yaacov****
> ** **
> *Still looking for new opportunity*****
>

-- 
Thanx and BR,
yaacov

*Still looking for new opportunity*

---

From: Eric Gray <[email-masked]>
Date: Tue, 21 May 2013 13:53:19 +0000

This discussion is also addressed to the Ads.

If they feel that further changes may be required, you should hear from them.

If they do not, that is fine with me...

From: Yaacov Weingarten [mailto:[email-masked]]
Sent: Tuesday, May 21, 2013 3:16 AM
To: Eric Gray
Cc: [email-masked]; [email-masked]; [email-masked]
Subject: Re: Routing Area Directorate Review of draft-ietf-mpls-tp-ring-protection-05
Importance: High

Eric, hi

I guess I am happy to say that this is out of my hands now as the document has been approved by the IESG. Unless you think that these issues are critical, I do not think that I can address them without approval from the ADs.

Thanx anyway,
yaacov

On Tue, May 14, 2013 at 7:24 PM, Eric Gray <[email-masked]<mailto:[email-masked]>> wrote:
Yaacov,

--
Eric

From: Yaacov Weingarten [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Wednesday, April 17, 2013 8:56 AM
To: Eric Gray
Cc: [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>; [email-masked]<mailto:[email-masked]>
Subject: Re: Routing Area Directorate Review of draft-ietf-mpls-tp-ring-protection-05
Importance: High

Eric, hi

Hope this helps,
yaacov

Comments/Questions:
=================

Fine.

Is PHP never permitted?

So, fine.

Fine.

Fine

yw>> not really

NITs:
====

yw>> will fix

--
Thanx and BR,
yaacov

--
Thanx and BR,
yaacov