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

From: Martin Vigoureux <[email-masked]>
Date: Wed, 12 Sep 2018 17:58:09 +0200

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 
> <[email-masked] <mailto:[email-masked]>> 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.

---

From: Pushpasis Sarkar <[email-masked]>
Date: Thu, 13 Sep 2018 20:24:50 +0530

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

---

From: Shraddha Hegde <[email-masked]>
Date: Thu, 13 Sep 2018 17:32:07 +0000

Martin,

Apologise missing the e-mail from Pushpasis.
I'll look at the comments and update the draft in a day or two.

Rgds
Shraddha

-----Original Message-----
From: Pushpasis Sarkar <[email-masked]> 
Sent: Thursday, September 13, 2018 8:25 PM
To: Vigoureux, Martin (Nokia - FR) <[email-masked]>
Cc: [email-masked]; rtgwg-chairs <[email-masked]>; Stewart Bryant <[email-masked]>; RTGWG <[email-masked]>
Subject: Re: AD review for draft-ietf-rtgwg-multihomed-prefix-lfa-06

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 <[email-masked]>
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?
> > 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

---

From: Shraddha Hegde <[email-masked]>
Date: Wed, 19 Sep 2018 08:50:23 +0000

Martin,

I have fixed the typos and also added more description to clarify a few items.

Pls see details

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.. 
<shraddha> Fixed the text to read "ECMP FRR"

<shraddha> Thanks for the suggestion. Chaged the paraphasing sections to subsections of 4.2.1

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.
<Shraddha> Added more description to "type 1 type 2 cost" section.
Pls check if it looks better. 

Section 4.2.4
It is not clear which inequalities will apply in that case.
<Shraddha> Added statement to clarify the inequalities to be used.

<Shraddha> Updated step 5. pls check.

    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"?
<shraddha>if primary ASBR and alternate ASBR are intra area
                  and belong to non-backbone go to step 2.

<shraddha> Fixed

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

   4  If cost type is type 2
   4  If cost types are type2, compare costs advertised by alternate ASBR
<shraddha> Fixed

    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 ..." 
<shraddha> fixed the text

I have posted -07 version.Pls take a look and let me know if you have further comments.

Rgds
Shraddha

-----Original Message-----
From: Shraddha Hegde <[email-masked]> 
Sent: Thursday, September 13, 2018 11:02 PM
To: Pushpasis Sarkar <[email-masked]>; Vigoureux, Martin (Nokia - FR) <[email-masked]>
Cc: [email-masked]; rtgwg-chairs <[email-masked]>; Stewart Bryant <[email-masked]>; RTGWG <[email-masked]>
Subject: RE: AD review for draft-ietf-rtgwg-multihomed-prefix-lfa-06

Martin,

Rgds
Shraddha

-----Original Message-----
From: Pushpasis Sarkar <[email-masked]>
Sent: Thursday, September 13, 2018 8:25 PM
To: Vigoureux, Martin (Nokia - FR) <[email-masked]>
Cc: [email-masked]; rtgwg-chairs <[email-masked]>; Stewart Bryant <[email-masked]>; RTGWG <[email-masked]>
Subject: Re: AD review for draft-ietf-rtgwg-multihomed-prefix-lfa-06

Hi Martin,

Best regards,
-Pushpasis

---

From: Martin Vigoureux <[email-masked]>
Date: Tue, 25 Sep 2018 10:12:56 +0200

All,

thanks for the update, I'm pushing this forward.
Note that the quote for 8124 is not exactly that one but this can be 
handled at a later stage.

-m