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

[Pushpasis Sarkar <[e-mail]>]

Hi Martin,

I am extremely sorry. I forgot to follow up with co-authors on this. Buried
with day job. I will try to close it with co-authors at the earliest
possible.

Best regards,
-Pushpasis

On Wed, Sep 12, 2018 at 9:33 PM Martin Vigoureux <[e-mail]>
wrote:

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