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

[Yaacov Weingarten <[e-mail]>]

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 <[e-mail]> 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:[e-mail]]
> *Sent:* Wednesday, April 17, 2013 8:56 AM
> *To:* Eric Gray
> *Cc:* [e-mail];
> [e-mail]; [e-mail]
> *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 <[e-mail]> 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 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.****
>
>  ****
>
> 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*****
>



-- 
Thanx and BR,
yaacov

*Still looking for new opportunity*