Re: AD review for draft-ietf-rtgwg-multihomed-prefix-lfa-06

[Martin Vigoureux <[e-mail]>]

Authors,

am I right in thinking that the ball is still in your camp and you need 
Shraddha to look at some of the comments?
The draft has been in Revised I-D Needed for 5 months now.

-m

Le 2018-06-19 à 11:00, Pushpasis Sarkar a écrit :
> Hi Martin,
> 
> Once again sorry for the delay. Please find answers to some of your 
> points inline.
> 
> Hi Shraddha,
> 
> Please find attached the XML draft for the next revision with changes 
> taken care by Uma and myself. Please add your changes and reply back on 
> the comments on OSPF sections that I have requested you to take look at.
> 
> Thanks
> -Pushpasis
> 
> 
> 
> 
> On Wed, Mar 28, 2018 at 3:29 AM Martin Vigoureux 
> <[e-mail] <mailto:[e-mail]>> wrote:
> 
>     Hello Authors, WG.
> 
>     Thank you for putting together this Document. Thanks also to all those
>     that reviewed it. It is well written and pretty clear (more the first
>     part than the second though).
> 
>     I have a few comments, all of them minor and mainly intended for
>     clarification.
> 
>     However, I'd like these to be addressed before moving to IETF LC, just
>     to avoid them being picked up again.
> 
>     thanks
>     -m
> 
>     Abstract
>     s/This documents/This document/
> 
> [Uma] Done
> 
>     Requirements Language
>     Please switch from 2119 to 8174
> 
> [Pushpasis] Done
> 
>     Section 3
>     I am under the impression that few clarifications are needed here.
>     The Document says:
>               Link-Protection + Downstream-paths-only :
>               =========================================
>               1. Evaluate the link-protecting + downstream-only LFA
>     inequality
> 
>     and:
>          When computing a downstream-only LFA, in addition to being a
>     prefix-
>          originator of P, router N MUST also satisfy the downstream-only LFA
>          inequality specified in Figure 1.
> 
>     * do you mean: MUST be prefix originator of P and MUST also satisfy?
>     * this paragraph basically says (taking out the prefix originator
>     part):
>     if one wants a downstream path only LFA then the downstream path
>     inequality must be satisfied. This seems like stating the obvious. Is
>     that needed?
>     * step 1 above makes no reference to N having to be prefix
>     originator of
>     P. There is thus an ambiguity between this last paragraph and
>     description of the steps.
>     * Also, strictly speaking there is no "downstream-only LFA inequality"
>     in Figure 1. That inequality is in RFC 5286. Figure 1 shows the
>     "Link-Protection + Downstream-paths-only" inequality.
> 
>     [Pushpasis] As far as I understand LFA.. 'Downstream-paths-only'
>     implies link-protection.. A alternate neighbor N which satisfies the
>     Downstream-path-only criteria also always satisfies the
>     link-protection inequality. Nevertheless I will modify the text to
>     be specific.
> 
>     The Document also says:
>          In case an alternate neighbor N is also one of the
>     prefix-originators
>          of prefix P, N MAY be selected as a valid LFA for P since being a
>          prefix-originator it is guaranteed that N will not loop back
>     packets
>          destined for prefix P to computing router S.
> 
>          However, if N is not a prefix-originator of P, the computing router
>          SHOULD evaluate one of the corresponding LFA inequalities, as
>          mentioned in Figure 1, once for each remote node that
>     originated the
>          prefix.  In case the inequality is satisfied by the neighbor N
>     router
>          S MUST choose neighbor N, as one of the valid LFAs for the
>     prefix P.
> 
>     These two paragraphs are in the main body of the section, giving the
>     impression that their applicability is global to the three cases. It
>     looks to me that they are only valid for node and link protection
>     cases.
>     I would clarify that.
> 
>     Also, in the first of these two paragraphs, the use of MAY suggests
>     that
>     one may not select N as the LFA, but the description of the algorithm
>     does not give this degree of freedom (If .. select ...). So, is that
>     a MAY?
> 
> [Pushpasis]
> 
> I have re-structured the 3 paragraphs into following 2 paragraph.. Hope 
> it addresses all your concerns..
> 
> "
> 
>     In case an alternate neighbor N is also one of the prefix-originators
>     of prefix P, N being a prefix-originator it is guaranteed that N will
>     not loop back packets destined for prefix P to computing router S.
>     So N MUST be chosen as a valid LFA for prefix P, without evaluating
>     any of the inequalities in Figure 1 as long as downstream-paths-only
>     LFA is not desired.  To ensure such a neighbor N also provides a
>     downstream-paths-only LFA, router S MUST also evaluate the
>     downstream-only LFA inequality specified in Figure 1 for neighbor N
>     and ensure router N satisfies the inequality.
> 
>     However, if N is not a prefix-originator of P, the computing router
>     SHOULD evaluate one of the corresponding LFA inequalities, as
>     mentioned in Figure 1, once for each remote node that originated the
>     prefix.  In case the inequality is satisfied by the neighbor N router
>     S MUST choose neighbor N, as one of the valid LFAs for the prefix P.
> 
> "
> 
>     Section 3.1
>     This looks like a duplicate compared to the paragraph which sits above
>     it in the Document:
>          The approach specified in [RFC5286] Section 6.1 last paragraph,
>     is to
>          simplify the MHP as solely attached to the router that was its pre-
>          failure optimal point of attachment; though it is a scalable
>     approach
>          and simplifies computation, [RFC5286] notes this MAY result in
>     little
>          less coverage.
> 
> [Uma] Taken care of.
> 
>     Section 4.2 (and subsections) is (are) a bit difficult to
>     read/understand because of the typos but also because of the way it's
>     written.
> 
>     Section 4.2.1.
>     Do you mean ECMP FRR rather than simply ECMP (as section 4.2.3.
>     seems to
>     suggest)?
>     If so, please take this into account while addressing typos listed
>     below.
> 
> [Pushpasis] 4.2.1 is for ECMP. ECMPs do not count as alternates. These 
> rules cover all scenarios but related to alternates only.
> But, I will let Shraddha confirm that..
> 
>     Sections 4.2.2., 4.2.3., and 4.2.5, seem to be linked to 4.2.1..
>     Wouldn't it be better to switch 4.2.4. and 4.2.5.? Alternatively can't
>     these three sections in fact be subsections of 4.2.1 ?
> 
> [Pushpasis] Shraddha can you take look and let us know if that is okay.
> 
> 
>     Although Sections 4.2.2., 4.2.3., and 4.2.5 seem to paraphrase
>     4.2.1., I
>     read one sentence which does not appear in the pseudo algorithm:
>          If there are two ASBRs with different type2 cost, the higher cost
>          ASBR is pruned.
>     So I am not sure to understand when this condition/action comes into
>     play. Could you clarify?
> 
> [Pushpasis] Again will let Shraddha comment on it.
> 
> 
>     Section 4.2.4
>     It is not clear which inequalities will apply in that case.
> 
>     In the same way as above, Section 4.2.5 seems to say a more than Step 5
>     of the pseudo algorithm. Could you clarify when the extra conditions it
>     describes come into play? Or said differently, shouldn't step 5 be
>     reworked to be more complete? If you do so, please rework that step
>     incorporating the types of changes/rephrasing I have suggested for the
>     other steps (see typos below).
> 
>     Section 9
>     I don't disagree with what is written here, but do you think this is
>     sufficient?
> 
> [Uma]: Added bit more specific to ISIS and OSPF security docs. Check 
> that out.
> 
>     Section 10
>     Shouldn't rfc5714 be referenced since the inequalities use the
>     principles set forth in that rfc?
> 
> [Uma]: Done. Added a sentence in the first paragraph too.
> 
> 
>     Typos/Editorial comments:
>     s/for a multi-homed prefixes/for multi-homed prefixes/
> 
> [Uma] Done.
> 
>     s/This document also provide/This document also provides/
> 
> [Uma] Done
> 
>     indentation on second line:
>             Cost (X,P)   - Cost of reaching the prefix P from prefix
>                           originating node X.
> 
> [Pushpasis] Done
> 
>     s/Else, evaluate the link-protecting/Else, evaluate the Link-Protection/
> 
>     s/Evaluate the link-protecting + downstream-only/Evaluate the
>     Link-Protection + Downstream-paths-only/
> 
>     s/Else, evaluate the appropriate node-protecting/Else, evaluate the
>     Node-Protection/
> 
>     s/one of the corresponding LFA inequalities/the corresponding LFA
>     inequality/ ?
> 
>     s/a router compute/a router computes/
> 
> [Uma]: Done.
> 
> In Section 3.1, please capitalize 'p' in text and figure to be
> consistent with the rest of the Document and the Terminology section.
> 
> [Uma]: Done.
> 
>     In Section 3.1, please capitalize 'p' in text and figure to be
>     consistent with the rest of the Document and the Terminology section.
> 
>     s/a MHP/an MHP/ (not sure about that though)
> 
>     may be it's only me but these sentences are hard to parse:
>          This document specifies, potentially
>          a node MAY consider a default route is being advertised from the
>          border L1/L2 router where ATT bit is set and can do LFA computation
>          for the default route.  But, when multiple ECMP L1/L2 routers are
>          reachable in an L1 area corresponding best LFAs SHOULD be given for
>          each primary next-hop associated with default route.
> 
> 
> [Uma]: Done.
> 
>     s/Inequalities described in sec 2 would also apply to multi-homed
>     external prefixes as well./Inequalities described in Section 2 would
>     also apply to multi-homed external prefixes./
> 
> [Uma]: Done.
> 
>     s/Loop free Alternates/Loop Free Alternates/
> 
>          For the selection of alternate ASBR for LFA consideration,
>     additional
>          rules have to be applied in selecting the alternate ASBR due to the
>          external route calculation rules imposed by [RFC2328].
>     remove "in selecting the alternate ASBR"
> 
> [Uma] Done.
> 
>     OLD
>          This document also defines the inequalities defined in [RFC5286]
>          specifically for the alternate loop-free ASBR evaluation.
>     NEW
>          This document defines inequalities specifically for the alternate
>          loop-free ASBR evaluation, based on those [RFC5286].
> 
> [Uma] Done.
> 
>          1a. if primary ASBR and alternate ASBR are intra area
>              non-backbone path go to step 2.
>     do you mean "belong to" rather than "are"?
> 
>         2. If cost type (type1/type2) advertised by alternate
>            ASBR same as primary
>     Do you mean:
>         2. Compare cost types (type1/type2) advertised by alternate ASBR and
>            by the primary ASBR
> 
> [Pushpasis] Shraddha, please take  a look.
> 
>     s/If not, same /If not the same type/
> 
> [Uma] Done.
> 
>         3. If cost type is type1
>                   3a. If cost is same, program ECMP and return.
>                   3b. else go to step 5.
>     Do you mean:
>         3. If cost types are type1, compare costs advertised by
>     alternate ASBR
>            and by the primary ASBR
>                   3a. If costs are the same then program ECMP and return.
>                   3b. else go to step 5.
> 
> [Pushpasis] Shraddha, please take  a look.
> 
>         4  If cost type is type 2
>                   4a. If cost is different, skip alternate ASBR and
>                           consider next ASBR.
>                   4b. If type2 cost is same, proceed to step 4c to compare
>                           compare type 1 cost.
>                   4c. If type1 cost is also same program ECMP and return.
>                   4d. If type 1 cost is different go to step 5.
>     Do you mean:
>         4  If cost types are type2, compare costs advertised by
>     alternate ASBR
>            and by the primary ASBR
>                   4a. If costs are different, skip alternate ASBR and
>                           consider next ASBR.
>                   4b. If cost are the same, proceed to step 4c to compare
>                           compare type1 costs.
>                   4c. If type1 costs are also same program ECMP and return.
>                   4d. If type1 costs are different go to step 5.
> 
> [Pushpasis] Shraddha, please take  a look.
> 
>          While selecting alternate ASBR for loop evaluation for LFA, these
>          rules should be applied and ensured that the alternate neighbor
>     does
>          not loop the traffic back.
>     I'm not sure about the meaning of the latter part of that sentence
>     ("and
>     ensured ...")
> 
> [Pushpasis] Shraddha, please take  a look. I think it means.. "... these 
> rules should be applied and to ensure that the alternate neighbor does 
> not loop ..."
> 
>     Figures 6 and 7, please add:
>             P            - The multi-homed prefix being evaluated for
>                            computing alternates
> 
> [Uma] done.
> 
>     s/Section 3.5 and 3.6 of [RFC5286] describes/Sections 3.5 and 3.6 of
>     [RFC5286] describe/
> 
> [Uma] done.
> 
>     s/as defined in for IS-IS/as defined for IS-IS/
> 
> [Uma] done.
> 
>     s/destined to D2 continue/destined to D2 continues/
> 
> [Uma] done.
> 
>     s/ISIS/IS-IS/
> 
> [Uma] done.