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 protected]>
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.
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="4"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<rfc category="std" docName="draft-ietf-rtgwg-multihomed-prefix-lfa-07" updates="5286" ipr="trust200902">
<!-- ***** FRONT MATTER ***** -->
<front>
<title>LFA selection for Multi-Homed Prefixes</title>
<!-- add 'role="editor"' below for the editors if appropriate -->
<author initials="P." surname="Sarkar" fullname="Pushpasis Sarkar" role="editor">
<organization>Arrcus, Inc.</organization>
<address>
<!-- postal><street/><city/><region/><code/><country/></postal -->
<!-- <phone/> -->
<!-- <facsimile/> -->
<email>[email protected]</email>
</address>
</author>
<author fullname="Uma Chunduri" initials="U.C." surname="Chunduri" role="editor">
<organization>Huawei USA</organization>
<address>
<postal>
<street>2330 Central Expressway</street>
<city>Santa Clara</city>
<region>CA</region>
<code>95050</code>
<country>USA</country>
</postal>
<email>[email protected]</email>
</address>
</author>
<author initials="S." surname="Hegde" fullname="Shraddha Hegde">
<organization>Juniper Networks, Inc.</organization>
<address>
<postal>
<street>Electra, Exora Business Park</street>
<city>Bangalore</city>
<region>KA</region>
<code>560103</code>
<country>India</country>
</postal>
<email>[email protected]</email>
</address>
</author>
<author fullname="Jeff Tantsura" initials="J.T." surname="Tantsura">
<organization>Nuage Networks</organization>
<address>
<postal>
<street>755 Ravendale Drive</street>
<city>Mountain View</city>
<region>CA</region>
<code>94043</code>
<country>USA</country>
</postal>
<email>[email protected]</email>
</address>
</author>
<author fullname="Hannes Gredler" initials="H." surname="Gredler">
<organization>RtBrick, Inc.</organization>
<address>
<!-- postal><street/><city/><region/><code/><country/></postal -->
<!-- <phone/> -->
<!-- <facsimile/> -->
<email>[email protected]</email>
<!-- <uri/> -->
</address>
</author>
<date year="2018"/>
<area>Routing</area>
<workgroup>Routing Area Working Group</workgroup>
<keyword>LFA</keyword>
<keyword>Multi-homed Prefix</keyword>
<keyword>IGP</keyword>
<abstract>
<t>This document shares experience gained from implementing algorithms to
determine Loop-Free Alternates for multi-homed prefixes. In particular,
this document provides explicit inequalities that can be used to evaluate
neighbors as a potential alternates for multi-homed prefixes. It also provides
detailed criteria for evaluating potential alternates for external prefixes
advertised by OSPF ASBRs. This documents updates and expands some of the "Routing Aspects" as
specified in Section 6 of RFC 5286. </t>
</abstract>
<note title="Requirements Language">
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in <xref
target="RFC8174">RFC8174</xref>.</t>
</note>
</front>
<middle>
<section title="Introduction">
<t> A framework for the development of IP fast-
reroute mechanisms is detailed in <xref target="RFC5714"></xref>. The use of Loop-Free Alternates (LFA) for IP Fast Reroute is specified in
<xref target="RFC5286"></xref>. Section 6.1 of <xref target="RFC5286"></xref> describes a method to
determine loop-free alternates for multi-homed prefixes (MHPs). This document describes
a procedure using explicit inequalities that can be used by a computing router to evaluate
a neighbor as a potential alternate for a multi-homed prefix. The results obtained are
equivalent to those obtained using the method described in Section 6.1 of <xref target="RFC5286"></xref>.
However, some may find this formulation useful.</t>
<t>Section 6.3 of <xref target="RFC5286"></xref> discusses complications associated with computing LFAs for
multi-homed prefixes in OSPF. This document provides detailed criteria for evaluating
potential alternates for external prefixes advertised by OSPF ASBRs, as well as explicit
inequalities.</t>
<t>This document also provides clarifications, additional considerations to
<xref target="RFC5286"></xref>, to address a few coverage and operational observations.
These observations are in the area of handling IS-IS attach (ATT) bit in Level-1 (L1) area,
links provisioned with MAX_METRIC for traffic engineering (TE) purposes and in the area of
Multi Topology (MT) IGP deployments. These are elaborated in detail in
<xref target="ATT_BIT"> </xref> and <xref target="LFA_minor_extensions"> </xref>.</t>
<section title="Acronyms">
<t><list hangIndent="7" style="hanging">
<t hangText="AF –">Address Family </t>
<t hangText="ATT –">IS-IS Attach Bit </t>
<t hangText="ECMP –">Equal Cost Multi Path </t>
<t hangText="IGP –">Interior Gateway Protocol </t>
<t hangText="IS-IS –">Intermediate System to Intermediate System</t>
<t hangText="LSP –">IS-IS Link State PDU</t>
<t hangText="OSPF –">Open Shortest Path First </t>
<t hangText="MHP –">Multi-homed Prefix </t>
<t hangText="MT –">Multi Topology </t>
<t hangText="SPF –">Shortest Path First PDU</t>
</list></t>
</section>
</section>
<section title="LFA inequalities for MHPs">
<t>This document proposes the following set of LFA inequalities for selecting the most appropriate
LFAs for multi-homed prefixes (MHPs). They can be derived from the inequalities in <xref target="RFC5286"></xref> combined
with the observation that
D_opt(N,P) = Min (D_opt(N,PO_i) + cost(PO_i,P)) over all PO_i</t>
<figure anchor="mhp-lfa-eval-appr-ineq"
title="LFA inequalities for MHPs">
<artwork>
Link-Protection:
D_opt(N,PO_i)+ cost(PO_i,P) < D_opt(N,S) +
D_opt(S,PO_best) + cost(PO_best,P)
Link-Protection + Downstream-paths-only:
D_opt(N,PO_i)+ cost(PO_i,P) < D_opt(S,PO_best) + cost(PO_best,P)
Node-Protection:
D_opt(N,PO_i)+ cost(PO_i,P) < D_opt(N,E) +
D_opt(E,PO_best) + cost(PO_best,P)
Where,
P - The multi-homed prefix being evaluated for
computing alternates
S - The computing router
N - The alternate router being evaluated
E - The primary next-hop on shortest path from S to
prefix P.
PO_i - The specific prefix-originating router being
evaluated.
PO_best - The prefix-originating router on the shortest path
from the computing router S to prefix P.
Cost (X,P) - Cost of reaching the prefix P from prefix
originating node X.
D_opt(X,Y) - Distance on the shortest path from node X to node
Y.
</artwork>
</figure>
</section>
<section anchor="LFA_SELECTION_FOR_MHPs"
title="LFA selection for the multi-homed prefixes">
<t>To compute a valid LFA for a given multi-homed prefix P, a computing
router S MUST follow one of the appropriate procedures below, for each
alternate neighbor N.</t>
<figure anchor="flow_chart1"
title="Rules for selecting LFA for MHPs">
<artwork>
Link-Protection :
=================
1. If alternate neighbor N is also prefix-originator of P,
1.a. Select N as a LFA for prefix P (irrespective of
the metric advertised by N for the prefix P).
2. Else, evaluate the link-protecting LFA inequality for P with
the N as the alternate neighbor.
2.a. If LFA inequality condition is met,
select N as a LFA for prefix P.
2.b. Else, N is not a LFA for prefix P.
Link-Protection + Downstream-paths-only :
=========================================
1. Evaluate the link-protecting + downstream-only LFA inequality
for P with the N as the alternate neighbor.
1.a. If LFA inequality condition is met,
select N as a LFA for prefix P.
1.b. Else, N is not a LFA for prefix P.
Node-Protection :
=================
1. If alternate neighbor N is also prefix-originator of P,
1.a. Select N as a LFA for prefix P (irrespective of
the metric advertised by N for the prefix P).
2. Else, evaluate the appropriate node-protecting LFA inequality
for P with the N as the alternate neighbor.
2.a. If LFA inequality condition is met,
select N as a LFA for prefix P.
2.b. Else, N is not a LFA for prefix P.
</artwork>
</figure>
<t>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 <xref target="mhp-lfa-eval-appr-ineq"/> 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
<xref target="mhp-lfa-eval-appr-ineq"/> for neighbor N and ensure router N satisfies the inequality.</t>
<t>However, if N is not a prefix-originator of P, the computing router SHOULD evaluate one of the
corresponding LFA inequalities, as mentioned in <xref target="mhp-lfa-eval-appr-ineq"/>, 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.</t>
<t>For more specific rules please refer to the later sections of this document.</t>
<section anchor="ISIS_MHPs" title="Improved coverage with simplified approach to MHPs">
<t>
LFA base specification <xref target="RFC5286"></xref> Section 6.1 recommends that a router computes the alternate next-hop for an IGP multi-homed prefix by
considering alternate paths via all routers that have announced that prefix and the same has been elaborated with appropriate inequalities in the above
section. However, <xref target="RFC5286"></xref> Section 6.1 also allows for the router to simplify the multi-homed prefix
calculation by assuming that the MHP is solely attached to the router that was its pre-failure optimal point of attachment, at the expense of potentially
lower coverage. If an implementation chooses to simplify the multi-homed prefix calculation by assuming that the MHP is solely attached to the router that was
its pre-failure optimal point of attachment, the procedure described in this memo can potentially improve coverage for equal cost multi
path (ECMP) MHPs without incurring extra computational cost.
</t>
<t>
This document improves the above approach to provide loop-free alternatives without any additional cost for ECMP MHPs as described through
the below example network. The approach specified here MAY also be applicable for handling default routes as explained in <xref target="ATT_BIT"> </xref>.
</t>
<figure align="center" anchor="ECMP_MHPs" title="MHP with same ECMP Next-hop"><preamble></preamble>
<artwork align="left">
5 +---+ 8 +---+ 5 +---+
+-----| S |------| A |-----| B |
| +---+ +---+ +---+
| | |
| 5 | 5 |
| | |
+---+ 5 +---+ 4 +---+ 1 +---+
| C |---| E |-----| M |-------| F |
+---+ +---+ +---+ +---+
| 10 5 |
+-----------P---------+
</artwork>
<postamble></postamble>
</figure>
<t>
In the above network a prefix p, is advertised from both Node E and Node F. With simplified approach taken as specified in
<xref target="RFC5286"></xref> Section 6.1, prefix P will get only link protection LFA through the neighbor C while a node
protection path is available through neighbor A. In this scenario, E and F both are pre-failure optimal points of attachment
and share the same primary next-hop.
Hence, an implementation MAY compare the kind of protection A provides to F (link-and-node protection) with the kind of
protection C provides to E (link protection) and inherit the better alternative to prefix P and here it is A.
</t>
<t>
However, in the below network prefix P has an ECMP through both node E and node F with cost 20. Though it has 2 pre-failure optimal
points of attachment, the primary next-hop to each pre-failure optimal point of attachment is different. In this case, prefix P MUST
inherit corresponding LFAs of each primary next-hop calculated for the router advertising the
same respectively. In the below diagram that would be node E's and node F's LFA i.e., node N1 and node N2 respectively.
</t>
<figure align="center" anchor="Different_NH_ECMP_MHPs" title="MHP with different ECMP Next-hops">
<preamble></preamble>
<artwork align="left">
4 +----+
+------------------| N2 |
| +----+
| | 4
10 +---+ 3 +---+
+------| S |----------------| B |
| +---+ +---+
| | |
| 10 | 1 |
| | |
+----+ 5 +---+ 16 +---+
| N1 |----| E |-----------------| F |
+----+ +---+ +---+
| 10 16 |
+-----------P---------+
</artwork>
<postamble></postamble>
</figure>
<t>
In summary, if there are multiple pre-failure points of attachment for a MHP and primary next-hop of a MHP is same as that of
the primary next-hop of the router that was pre-failure optimal point of attachment, an implementation MAY provide a better
protection to MHP without incurring any additional computation cost.
</t>
</section>
<section anchor="ATT_BIT" title="IS-IS ATT Bit considerations">
<t>
Per <xref target="RFC1195"></xref> a default route needs to be added in Level1 (L1) router to the closest reachable Level1/Level2 (L1/L2)
router in the network
advertising ATT (attach) bit in its LSP-0 fragment. All L1 routers in the area would do this during the decision process with the next-hop of
the default route set to the adjacent router through which the closest L1/L2 router is reachable. The base LFA specification
<xref target="RFC5286"></xref> does not specify any procedure for computing LFA for a default route in IS-IS L1 area. This document specifies,
a node can consider a default route is being advertised from the border L1/L2 router where ATT bit is set, and can do LFA computation
for that 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. Considerations as specified in
<xref target="LFA_SELECTION_FOR_MHPs"> </xref> and <xref target="ISIS_MHPs"> </xref>
are applicable for default routes, if the default route is considered as ECMP MHP.
Note that, this document doesn't alter any ECMP handling rules or computation of LFAs for ECMP in general as laid out in <xref target="RFC5286"></xref>.
</t>
</section>
</section>
<section title="LFA selection for the multi-homed external prefixes">
<t>Redistribution of external routes into IGP is required in case of two different networks getting
merged into one or during protocol migrations. External routes could be distributed into an IGP
domain via multiple nodes to avoid a single point of failure.</t>
<t>During LFA calculation, alternate LFA next-hops to reach the best ASBR could be used as LFA
for the routes redistributed via that ASBR. When there is no LFA available to the best ASBR,
it may be desirable to consider the other ASBRs (referred to as alternate ASBR hereafter)
redistributing the external routes for LFA selection as defined in <xref target="RFC5286"/>
and leverage the advantage of having multiple re-distributing nodes in the network.</t>
<section title="IS-IS">
<t>LFA evaluation for multi-homed external prefixes in IS-IS is similar to the multi-homed
internal prefixes. Inequalities described in Section 2 would also apply to multi-homed
external prefixes.</t>
</section>
<section title="OSPF">
<t>Loop Free Alternates <xref target="RFC5286"></xref> describes mechanisms to apply inequalities to find the loop
free alternate neighbor. 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 <xref target="RFC2328"></xref>.</t>
<t>
This document defines inequalities specifically for the alternate
loop-free ASBR evaluation, based on those in <xref target="RFC5286"></xref>. </t>
<section anchor="RULES_FOR_ASBR" title="Rules to select alternate ASBR">
<t>The process to select an alternate ASBR is best explained using the rules below.
The below process is applied when primary ASBR for the concerned prefix is chosen and
there is an alternate ASBR originating same prefix.</t>
<figure anchor="flow_chart2"
title="Rules for selecting alternate ASBR in OSPF">
<artwork>
1. If RFC1583Compatibility is disabled
1a. if primary ASBR and alternate ASBR are intra area
non-backbone path go to step 2.
1b. If primary ASBR and alternate ASBR belong to
intra-area backbone and/or inter-area path go
to step 2.
1c. for other paths, skip this alternate ASBR and
consider next ASBR.
2. If cost type (type1/type2) advertised by alternate
ASBR same as primary
2a. If not the same type skip alternate ASBR and consider next ASBR.
2b. If same proceed to step 3.
3. If cost type is type1
3a. If cost is same, program ECMP and return.
3b. else go to step 5.
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.
5. If route type (type 5/type 7)
5a. If route type is same, check route p-bit,
forwarding address field for routes from both
ASBRs match. If p-bit matches proceed to step 6.
If not, skip this alternate ASBR and consider
next ASBR.
5b. If route type is not same, skip this alternate ASBR
and consider next alternate ASBR.
6. Apply inequality on the alternate ASBR.
</artwork>
</figure>
</section>
<section anchor="MULTIPLE_ASBRS" title="Multiple ASBRs belonging different area">
<t>When "RFC1583compatibility" is set to disabled, OSPF <xref target="RFC2328"></xref> defines certain rules of
preference to choose the ASBRs. 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.</t>
<t>When there are multiple ASBRs belonging to different area advertising the same prefix,
pruning rules as defined in <xref target="RFC2328"></xref> section 16.4.1 are applied. The alternate ASBRs pruned
using above rules are not considered for LFA evaluation.</t>
</section>
<section title="Type 1 and Type 2 costs">
<t>If there are multiple ASBRs not pruned via rules defined in <xref target="MULTIPLE_ASBRS"> </xref>, the cost type advertised
by the ASBRs is compared. ASBRs advertising Type1 costs are preferred and the type2 costs are
pruned. If two ASBRs advertise same type2 cost, the alternate ASBRs are considered along with
their type1 cost for evaluation. If the two ASBRs with same type2 as well as type1 cost, ECMP
FRR is programmed. If there are two ASBRs with different type2 cost, the higher cost ASBR is
pruned. The inequalities for evaluating alternate ASBR for type 1 and type 2 costs are same,
as the alternate ASBRs with different type2 costs are pruned and the evaluation is based on
equal type 2 cost ASBRS.</t>
</section>
<section title="RFC1583compatibility is set to enabled">
<t>When RFC1583Compatibility is set to enabled, multiple ASBRs belonging to different area
advertising same prefix are chosen based on cost and hence are valid alternate ASBRs
for the LFA evaluation.</t>
</section>
<section title="Type 7 routes">
<t>Type 5 routes always get preference over Type 7 and the alternate ASBRs chosen for LFA
calculation should belong to same type. Among Type 7 routes, routes with p-bit and forwarding
address set have higher preference than routes without these attributes. Alternate ASBRs
selected for LFA comparison should have same p-bit and forwarding address attributes.</t>
</section>
<section title= "Inequalities to be applied for alternate ASBR selection">
<t>The alternate ASBRs selected using above mechanism described in <xref target="RULES_FOR_ASBR"> </xref>,
are evaluated for Loop free criteria using below inequalities.</t>
<section title= "Forwarding address set to non-zero value">
<figure anchor="mhp_fadd_zero" title="LFA inequality definition when forwarding address is non-zero">
<artwork>
Link-Protection:
F_opt(N,PO_i)+ cost(PO_i,P) < D_opt(N,S) +
F_opt(S,PO_best) + cost(PO_best,P)
Link-Protection + Downstream-paths-only:
F_opt(N,PO_i)+ cost(PO_i,P) < F_opt(S,PO_best) + cost(PO_best,P)
Node-Protection:
F_opt(N,PO_i)+ cost(PO_i,P) < D_opt(N,E) +
F_opt(E,PO_best) + cost(PO_best,P)
Where,
P - The multi-homed prefix being evaluated for
computing alternates
S - The computing router
N - The alternate router being evaluated
E - The primary next-hop on shortest path from S to
prefix P.
PO_i - The specific prefix-originating router being
evaluated.
PO_best - The prefix-originating router on the shortest path
from the computing router S to prefix P.
cost(X,Y) - External cost for Y as advertised by X
F_opt(X,Y) - Distance on the shortest path from node X to Forwarding
address specified by ASBR Y.
D_opt(X,Y) - Distance on the shortest path from node X to node Y.
</artwork>
</figure>
</section>
<section title= "ASBRs advertising type1 and type2 cost">
<figure anchor="mhp_type1_type2" title="LFA inequality definition for type1 and type 2 cost">
<artwork>
Link-Protection:
D_opt(N,PO_i)+ cost(PO_i,P) < D_opt(N,S) +
D_opt(S,PO_best) + cost(PO_best,P)
Link-Protection + Downstream-paths-only:
D_opt(N,PO_i)+ cost(PO_i,P) < D_opt(S,PO_best) + cost(PO_best,P)
Node-Protection:
D_opt(N,PO_i)+ cost(PO_i,P) < D_opt(N,E) +
D_opt(E,PO_best) + cost(PO_best,P)
Where,
P - The multi-homed prefix being evaluated for
computing alternates
S - The computing router
N - The alternate router being evaluated
E - The primary next-hop on shortest path from S to
prefix P.
PO_i - The specific prefix-originating router being
evaluated.
PO_best - The prefix-originating router on the shortest path
from the computing router S to prefix P.
cost(X,Y) - External cost for Y as advertised by X.
D_opt(X,Y) - Distance on the shortest path from node X to node Y.
</artwork>
</figure>
</section>
</section>
</section>
</section>
<section anchor="LFA_minor_extensions" title="LFA Extended Procedures">
<t>
This section explains the additional considerations in various aspects as listed below to the base LFA specification <xref target="RFC5286"></xref>.
</t>
<section anchor="IGP_MAX_METRIC" title="Links with IGP MAX_METRIC">
<t>
Section 3.5 and 3.6 of <xref target="RFC5286"></xref> describe procedures for excluding nodes and links from use in alternate paths based
on the maximum link metric (as defined for IS-IS in <xref target="RFC5305"></xref> or as defined in <xref target="RFC6987"></xref> for OSPF).
If these procedures are strictly followed, there are situations, as described below, where the only potential alternate available which satisfies
the basic loop-free condition will not be considered as alternative.
</t>
<figure align="center" anchor="MAX_METRIC" title="Link with IGP MAX_METRIC">
<preamble></preamble>
<artwork align="left">
+---+ 10 +---+ 10 +---+
| S |------|N1 |-----|D1 |
+---+ +---+ +---+
| |
10 | 10 |
|MAX_MET(N2 to S) |
| |
| +---+ |
+-------|N2 |--------+
+---+
10 |
+---+
|D2 |
+---+
</artwork>
<postamble></postamble>
</figure>
<t>
In the simple example network, all the link costs have a cost of 10 in both directions, except for the link between S and N2. The S-N2 link has a cost
of 10 in the forward direction i.e., from S to N2, and a cost of MAX_METRIC (0xffffff /2^24 - 1 for IS-IS and 0xffff for
OSPF) in the reverse direction i.e., from N2 to S for a specific end-to-end Traffic Engineering (TE) requirement of the operator. At node S, D1 is reachable through N1 with cost 20, and D2 is reachable
through N2 with cost 20. Even though neighbor N2 satisfies basic loop-free condition (inequality 1 of <xref target="RFC5286"></xref>) for D1, S's neighbor N2 could be
excluded as a potential alternative because of the current exclusions as specified in section 3.5 and 3.6 procedure of <xref target="RFC5286"></xref>.
But, as the primary traffic destined to D2 continues to use the link and hence irrespective of the reverse metric in this case, same link MAY be used
as a potential LFA for D1.
</t>
<t>
Alternatively, reverse metric of the link MAY be configured with MAX_METRIC-1, so that the link can be used as an alternative while meeting the operator's TE requirements and without having to
update the router to fix this particular issue.
</t>
</section>
<section anchor="IGP_MT" title="Multi Topology Considerations">
<t>
Section 6.2 and 6.3.2 of <xref target="RFC5286"></xref> state that multi-topology OSPF and IS-IS are out of scope for that specification.
This memo clarifies and describes the applicability.
</t>
<t>
In Multi Topology (MT) IGP deployments, for each MT ID, a separate shortest path tree (SPT) is built with topology specific adjacencies, the
LFA principles laid out
in <xref target="RFC5286"></xref> are actually applicable for MT IS-IS <xref target="RFC5120"></xref> LFA SPF. The primary difference in this
case is, identifying the eligible-set of neighbors for each LFA computation which is done per MT ID. The eligible-set for each MT ID is determined
by the presence of IGP adjacency
from Source to the neighboring node on that MT-ID apart from the administrative restrictions and other checks laid out in
<xref target="RFC5286"></xref>. The same is also applicable for MT-OSPF <xref target="RFC4915"></xref> or different AFs in
multi instance OSPFv3 <xref target="RFC5838"></xref>.
</t>
<t>
However for MT IS-IS, if a "standard topology" is used with MT-ID #0 <xref target="RFC5286"></xref> and both IPv4 <xref target="RFC5305"></xref>
and IPv6 routes/AFs <xref target="RFC5308"></xref> are present, then the condition of network congruency is applicable for LFA computation as well.
Network congruency here refers to, having same address families provisioned on all the links and all the nodes of the network with MT-ID #0.
Here with single decision process both IPv4 and IPv6 next-hops are computed for all the prefixes in the network and similarly with one LFA
computation from all eligible neighbors per <xref target="RFC5286"></xref>, all potential alternatives can be computed.
</t>
</section>
</section>
<section anchor="IANA_CONSIDERATIONS" title="IANA Considerations">
<t>This document has no actions for IANA.
</t>
</section>
<section anchor="Acknowledgements" title="Acknowledgements">
<t>Thanks to Alia Atlas and Salih K A for their useful feedback and inputs.
Thanks to Stewart Bryant for being document shepherd and providing detailed review comments.</t>
</section>
<section anchor="CONTRIBUTING_AUTH" title="Contributing Authors">
<t>The following people contributed substantially to the content of this
document and should be considered co-authors. </t>
<t><figure>
<artwork><![CDATA[Chris Bowers
Juniper Networks, Inc.
1194 N. Mathilda Ave,
Sunnyvale, CA 94089, USA
Email: [email protected]
Bruno Decraene
Orange,
France
Email: [email protected]]]></artwork>
</figure></t>
</section>
<section anchor="Security" title="Security Considerations">
<t>
Existing OSPF security considerations
and stronger authentication and manual key management
mechanisms are specified in <xref target="RFC7474"></xref> SHOULD be considered for OSPF deployments. Security concerns for IS-IS are addressed in <xref target="RFC5304"></xref> and <xref target="RFC5310"></xref>.
Further security analysis for IS-IS protocol is done in <xref target="RFC7645"></xref> SHOULD be considered for IS-IS deployments.
This document does not introduce any change in any of the
protocol <xref target="RFC1195"></xref> <xref target="RFC5120"></xref> <xref target="RFC2328"></xref> <xref target="RFC5838"></xref> specifications discussed here and also this does not introduce
any new security issues other than as noted in the LFA
base specification <xref target="RFC5286"></xref>.
</t>
</section>
</middle>
<!-- *****BACK MATTER ***** -->
<back>
<references title="Normative References">
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.8174.xml";?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.5286.xml";?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.5714.xml";?>
</references>
<references title="Informative References">
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.1195.xml";?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.2328.xml";?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.5305.xml";?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.5308.xml";?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.5120.xml";?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.6987.xml";?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.4915.xml";?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.5838.xml";?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.7474.xml";?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.5304.xml";?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.5310.xml";?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.7645.xml";?>
</references>
</back>
</rfc>
_______________________________________________
rtgwg mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/rtgwg
