Re: Benjamin Kaduk's No Objection on draft-ietf-rtgwg-multihomed-prefix-lfa-08: (with COMMENT)
Benjamin Kaduk <kaduk@mit.edu> Sat, 17 November 2018 00:58 UTC
Return-Path: <kaduk@mit.edu>
X-Original-To: rtgwg@ietfa.amsl.com
Delivered-To: rtgwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A5975128CF2; Fri, 16 Nov 2018 16:58:20 -0800 (PST)
X-Quarantine-ID: <FcDfwMhe2suW>
X-Virus-Scanned: amavisd-new at amsl.com
X-Amavis-Alert: BAD HEADER SECTION, Non-encoded 8-bit data (char 9C hex): Received: ...s kaduk@ATHENA.MIT.EDU)\n\t\234by outgoing.mit[...]
X-Spam-Flag: NO
X-Spam-Score: 0.799
X-Spam-Level:
X-Spam-Status: No, score=0.799 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, GB_SUMOF=5, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=no autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FcDfwMhe2suW; Fri, 16 Nov 2018 16:58:16 -0800 (PST)
Received: from dmz-mailsec-scanner-3.mit.edu (dmz-mailsec-scanner-3.mit.edu [18.9.25.14]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9FA65126CB6; Fri, 16 Nov 2018 16:58:14 -0800 (PST)
X-AuditID: 1209190e-85bff700000023e3-1d-5bef67a44960
Received: from mailhub-auth-3.mit.edu ( [18.9.21.43]) (using TLS with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-3.mit.edu (Symantec Messaging Gateway) with SMTP id AB.D1.09187.4A76FEB5; Fri, 16 Nov 2018 19:58:13 -0500 (EST)
Received: from outgoing.mit.edu (OUTGOING-AUTH-1.MIT.EDU [18.9.28.11]) by mailhub-auth-3.mit.edu (8.14.7/8.9.2) with ESMTP id wAH0wAUo024269; Fri, 16 Nov 2018 19:58:11 -0500
Received: from kduck.kaduk.org (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) �by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id wAH0w5nS024261 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 16 Nov 2018 19:58:08 -0500
Date: Fri, 16 Nov 2018 18:58:05 -0600
From: Benjamin Kaduk <kaduk@mit.edu>
To: Uma Chunduri <uma.chunduri@huawei.com>
Cc: The IESG <iesg@ietf.org>, "draft-ietf-rtgwg-multihomed-prefix-lfa@ietf.org" <draft-ietf-rtgwg-multihomed-prefix-lfa@ietf.org>, Stewart Bryant <stewart.bryant@gmail.com>, "rtgwg-chairs@ietf.org" <rtgwg-chairs@ietf.org>, "rtgwg@ietf.org" <rtgwg@ietf.org>
Subject: Re: Benjamin Kaduk's No Objection on draft-ietf-rtgwg-multihomed-prefix-lfa-08: (with COMMENT)
Message-ID: <20181117005804.GD11132@kduck.kaduk.org>
References: <154023269405.6878.3055865813410489597.idtracker@ietfa.amsl.com> <25B4902B1192E84696414485F5726854136D9FDC@sjceml521-mbs.china.huawei.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <25B4902B1192E84696414485F5726854136D9FDC@sjceml521-mbs.china.huawei.com>
User-Agent: Mutt/1.9.1 (2017-09-22)
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprGKsWRmVeSWpSXmKPExsUixCmqrbs0/X20wZTNHBZ3375mtZjxZyKz xf61i5ktLrz5zWxx6kGixY47V9kc2Dx2zrrL7tFy5C2rx5IlP5kCmKO4bFJSczLLUov07RK4 MtbNvs1WsHAda8XF4yvYGxinP2bqYuTgkBAwkTjw166LkYtDSGANk8T5Td+ZIJyNjBI3v7ay djFyAjl3mSSO3XUEsVkEVCX+/tvEBmKzCahINHRfZgaxRQS0JBqnn2EGaWYWWMIkcXXvMyaQ hLBApsTFR+dYQbbxAm3be8QPYsEMRollX+ezg9TwCghKnJz5hAXEZgYadOPfS7DrmAWkJZb/ 4wAJcwqESUzpeQBWLiqgLLG37xD7BEaBWUi6ZyHpnoXQvYCReRWjbEpulW5uYmZOcWqybnFy Yl5eapGusV5uZoleakrpJkZwYEvy7WCc1OB9iFGAg1GJh7fi0btoIdbEsuLK3EOMkhxMSqK8 3FLvo4X4kvJTKjMSizPii0pzUosPMUpwMCuJ8P54AVTOm5JYWZValA+TkuZgURLn/SXyOFpI ID2xJDU7NbUgtQgmK8PBoSTBG58GNFSwKDU9tSItM6cEIc3EwQkynAdo+FqQGt7igsTc4sx0 iPwpRmOObWc6ZzBzvJn7YwazEEtefl6qlDivNkipAEhpRmke3DRQcpLI3l/zilEc6Dlh3l0g VTzAxAY37xXQKiagVSemvgZZVZKIkJJqYNRasarBqyj7htGcq0Z8Wy7L3XIvlw+RKYmafCN7 2plTJgr2H0JOsr3V2yn6vDYiYE7lN6VHAezXM7TnxFzsbI1/9dnk35cJxq/yDLu/nPzgkXQl 3kx6XpZTVqcXz4u2ozdN/DI1S6wW37rI/CXf8bahp/iWQ9F+KSt1F7mwFnGtt2p2V3l7XIml OCPRUIu5qDgRAJ3nebQpAwAA
Archived-At: <https://mailarchive.ietf.org/arch/msg/rtgwg/ZxQYsq324XuzCwJ9X_ySaSas8k4>
X-BeenThere: rtgwg@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Routing Area Working Group <rtgwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtgwg>, <mailto:rtgwg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/rtgwg/>
List-Post: <mailto:rtgwg@ietf.org>
List-Help: <mailto:rtgwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtgwg>, <mailto:rtgwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 17 Nov 2018 00:58:21 -0000
On Sat, Nov 17, 2018 at 12:38:58AM +0000, Uma Chunduri wrote: > Thanks Benjamin for your detailed review. Changes to address some of your comments are attached (diff file). > > Also please see replies in-line [Uma]: Thanks for the updates; they do help the readability (at least for me). Just a couple notes inline... > Hope this diff addresses your comments. > -- > Uma C. > > > -----Original Message----- > From: Benjamin Kaduk [mailto:kaduk@mit.edu] > Sent: Monday, October 22, 2018 11:25 AM > To: The IESG <iesg@ietf.org> > Cc: draft-ietf-rtgwg-multihomed-prefix-lfa@ietf.org; Stewart Bryant <stewart.bryant@gmail.com>; rtgwg-chairs@ietf.org; stewart.bryant@gmail.com; rtgwg@ietf.org > Subject: Benjamin Kaduk's No Objection on draft-ietf-rtgwg-multihomed-prefix-lfa-08: (with COMMENT) > > Benjamin Kaduk has entered the following ballot position for > draft-ietf-rtgwg-multihomed-prefix-lfa-08: No Objection > > When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.) > > > Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://datatracker.ietf.org/doc/draft-ietf-rtgwg-multihomed-prefix-lfa/ > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > I was forced to make lots of inferences while reading this document, so it's pretty likely that some of my comments will not make sense because I misunderstood the technology. My apologies in advance, and please help me to become un-confused. I think part of this is because the document relies very heavily on prior knowledge, and could be avoided by sprinkling a few more words here and there, such as "downstream-paths-only (for micro-loop avoidance)" or "alternate neighbor N of S". I've tried to note some more cases in the section-by-section comments. > > > The Abstract and Introduction sound like they should be attached to an Informational document; why is this going for PS? > > [Uma]: Made few changes to introduction to also address your comment above. But this has been made PS as it updates RFC5286, which is a PS. Would be happy to take care any further comments specifically. I think that starting off with "shares experience gained from implementing" is what primed me to think "informational". The key point for making it PS is the "updates and expands", and perhaps also the "provides detailed criteria". So if it started out more like "Deployment experience gained from [...] has revealed some avenues for potential impirovement. This document provides explicit inequalities [...]", that would change the tone to be more consistent throughout, in my opinion. (But of course, feel free to go ahead as-is or with other changes; this is a non-blocking comment and I have no attachment to my specific proposal.) > Section 1.1 > > SPF - Shortest Path First PDU > > Is the "PDU" really entirely silent in the acronym? > [Uma]: Good catch. PDU should not be there, fixed. > > Section 2 > > It might be nice to super-briefly reframe the situation, maybe: > > The scenario for LFA protection for MHPs involves protecting a node N in the path from source S to MHP prefix P, providing an alternate path subject to constraints on the distance metric, measured as the sum of the cost of the links traversed by the path. > > Perhaps also expand the inequality headers slightly, as "Link-Protection for PO_i to P is possible via N if:" > > Cost(X,P) - Cost of reaching the prefix P from prefix > originating node X. > > Isn't it important to note that the Cost differs from a D_opt in that the Cost is only defined for what we essentially model here as a link and not a multi-link path? > > [Uma]: This is addressed, please see section 2 changes. Thanks, this helps a lot. > Section 3 > > Are these procedures supposed to terminate when the first LFA is found, or produce multiple LFAs as output? (Perhaps this is just an editorial nit, but "for each alternate neighbor N" and "a valid LFA" would then be a singular/plural mismatch", and perhaps the "select N as" steps in the various procedures as well. > > The phrase "If alternate neighbor N is also prefix-originator of P" > confused me a fair amount -- the "also" makes me think that what N is a neighbor of should be the "primary" prefix-originator of P, i.e., PO_best, but text elsewhere in the document implies that N is a neighbor of *S*, to be used as the next-hop for forwarding to P. I guess the intended sense of the "also" could be more like "if, in addition to being a neighbor, N is also a prefix-originator of P", but as written it seems ambiguous to me. > > [Uma]: Thx. Made the suggested change (+ a slight variation to be consistent with rest of the document) > > However, if N is not a prefix-originator of P, the computing router > SHOULD evaluate one of the corresponding LFA inequalities, as > > Why is this a SHOULD? > > [Uma]: This should have been a "MUST" and it's fixed (Alvaro too pointed this). > > Section 3.1 > > 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. > > I find that this chunk makes more sense if I read it as "kind of protection A provides to E" (not F). Am I just confused? > > [Uma]: I re-reviewed the text and I see no change required here. Okay. Looking over it now, I think I see how it makes sense as-is, so I will chalk this up to my initial confusion. > In > this case, prefix P MUST inherit corresponding LFAs of each primary > next-hop calculated for the router advertising the same respectively. > > Is this MUST a new requirement imposed by this specification or a restatement of something from (e.g.) RFC 5286? > > [Uma]: This is a new requirement and it is explaining where and why only corresponding LFAs of each primary next-hop has to be inherited. Okay. (If it was a restatement of something that already existed I would have suggested rewording to avoid the 2119 MUST and referencing the existing definition.) -Benjamin > 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. > > I had a hard time understanding why this is the case, most likely because I don't have a clear picture about what the reference point is for computational cost (that this is not "additional" to). > > [Uma]: This section is expanding the simplified approach laid out in the RFC5286 for computing the MHP LFAs and while doing so it is explaining how an ECMP MHP gets a better alternative in some cases (as explained in this section) without having to resort to full computations. > > > Section 4.2.1 > > This procedure is not super-well-defined if a cost type other than 1 or 2 is encountered. > > 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. [...] > > nit: "check if the route p-bit and the forwarding address field for" > > [Uma]: Fixed. > > Section 4.2.1.2 > > If there are multiple ASBRs not pruned via rules defined in > Section 4.2.1.1, [...] > > nit: I wouldn't exactly say that the rules are *defined* in 4.2.1.1, rather that they are "described in" or "referred to by" it. > > [Uma]: Fixed. > > Section 4.2.2.1 > > Similarly to a previous comment, if we started out with "A neighbor N of S is a valid LFA to P under the named conditions when the corresponding inequality holds:", that would seem to help readability a lot. > > [Uma]: Kind of addressed by referring to Section 2 (which has been updated to take care multiple comments). > > Section 5.2 > > 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 [RFC5286] are actually applicable for > MT IS-IS [RFC5120] LFA SPF. [...] > > nit: I think this is formally a comma splice as written, and would be better by adding "so" after the last comma, and maybe expanding to "so the LFA principles laid out in [RFC5286] are actually applicable on a per-MT-ID basis for MT IS-IS [RFC5120] LFA SPF." > > [Uma]: Fixed. > > Section 9 > > I don't see any new security considerations to mention here, but would suggest a rewording of the current text for readability: > > The existing OSPF security considerations continue to apply, as do the > recommended manual key management mechanisms specified in [RFC7474]. The > existing security considerations for IS-IS also continue to apply, as > specified in [RFC5304] and [RFC5310] and extended by [RFC7645] for KARP. > This document does not change any of the discussed protocol specifications > [RFC1195] [RFC5120] [RFC2328] [RFC5838], and the security considerations of > the LFA base specification [RFC5286] therefore continue to apply. > > [Uma]: Thanks. Updated this section as per your suggestion. > > < draft-ietf-rtgwg-multihomed-prefix-lfa-08.txt draft-ietf-rtgwg-multihomed-prefix-lfa-09.txt > > Routing Area Working Group P. Sarkar, Ed. Routing Area Working Group P. Sarkar, Ed. > Internet-Draft Arrcus, Inc. Internet-Draft Arrcus, Inc. > Updates: 5286 (if approved) U. Chunduri, Ed. Updates: 5286 (if approved) U. Chunduri, Ed. > Intended status: Standards Track Huawei USA Intended status: Standards Track Huawei USA > Expires: April 19, 2019 S. Hegde Expires: May 20, 2019 S. Hegde > Juniper Networks, Inc. Juniper Networks, Inc. > J. Tantsura J. Tantsura > Apstra, Inc. Apstra, Inc. > H. Gredler H. Gredler > RtBrick, Inc. RtBrick, Inc. > October 16, 2018 November 16, 2018 > LFA selection for Multi-Homed Prefixes Loop-Free Alternates selection for Multi-Homed > Prefixes > draft-ietf-rtgwg-multihomed-prefix-lfa-08 draft-ietf-rtgwg-multihomed-prefix-lfa-09 > Abstract Abstract > This document shares experience gained from This document shares experience gained from > implementing algorithms implementing algorithms > to determine Loop-Free Alternates (LFAs) for to determine Loop-Free Alternates (LFAs) for > multi-homed prefixes. multi-homed prefixes. > In particular, this document provides explicit In particular, this document provides explicit > inequalities that can inequalities that can > be used to evaluate neighbors as a potential be used to evaluate neighbors as a potential > alternates for multi- alternates for multi- > homed prefixes. It also provides detailed homed prefixes. It also provides detailed > criteria for evaluating criteria for evaluating > potential alternates for external prefixes potential alternates for external prefixes > advertised by OSPF ASBRs. advertised by OSPF ASBRs. > This documents updates and expands some of the This documents updates and expands some of the > "Routing Aspects" as "Routing Aspects" as > skipping to change at page 2, line 7 P: skipping to change at page 2, line 7 P: > Internet-Drafts are working documents of the Internet-Drafts are working documents of the > Internet Engineering Internet Engineering > Task Force (IETF). Note that other groups may Task Force (IETF). Note that other groups may > also distribute also distribute > working documents as Internet-Drafts. The list working documents as Internet-Drafts. The list > of current Internet- of current Internet- > Drafts is at Drafts is at > https://datatracker.ietf.org/drafts/current/. https://datatracker.ietf.org/drafts/current/. > Internet-Drafts are draft documents valid for a Internet-Drafts are draft documents valid for a > maximum of six months maximum of six months > and may be updated, replaced, or obsoleted by and may be updated, replaced, or obsoleted by > other documents at any other documents at any > time. It is inappropriate to use Internet-Drafts time. It is inappropriate to use Internet-Drafts > as reference as reference > material or to cite them other than as "work in material or to cite them other than as "work in > progress." progress." > This Internet-Draft will expire on April 19, This Internet-Draft will expire on May 20, 2019. > 2019. > Copyright Notice Copyright Notice > Copyright (c) 2018 IETF Trust and the persons Copyright (c) 2018 IETF Trust and the persons > identified as the identified as the > document authors. All rights reserved. document authors. All rights reserved. > This document is subject to BCP 78 and the IETF This document is subject to BCP 78 and the IETF > Trust's Legal Trust's Legal > Provisions Relating to IETF Documents Provisions Relating to IETF Documents > (https://trustee.ietf.org/license-info) in (https://trustee.ietf.org/license-info) in > effect on the date of effect on the date of > publication of this document. Please review publication of this document. Please review > these documents these documents > skipping to change at page 2, line 30 P: skipping to change at page 2, line 30 P: > include Simplified BSD License text as described include Simplified BSD License text as described > in Section 4.e of in Section 4.e of > the Trust Legal Provisions and are provided the Trust Legal Provisions and are provided > without warranty as without warranty as > described in the Simplified BSD License. described in the Simplified BSD License. > Table of Contents Table of Contents > 1. Introduction . . . . . . . . . . . . . . . . 1. Introduction . . . . . . . . . . . . . . . . > . . . . . . . . 3 . . . . . . . . 3 > 1.1. Acronyms . . . . . . . . . . . . . . . . . 1.1. Acronyms . . . . . . . . . . . . . . . . . > . . . . . . . 3 . . . . . . . 3 > 2. LFA inequalities for MHPs . . . . . . . . . . 2. LFA inequalities for MHPs . . . . . . . . . . > . . . . . . . . 4 . . . . . . . . 4 > 3. LFA selection for the multi-homed prefixes . 3. LFA selection for the multi-homed prefixes . > . . . . . . . . 5 . . . . . . . . 5 > 3.1. Improved coverage with simplified approach 3.1. Improved coverage with simplified approach > to MHPs . . . 6 to MHPs . . . 7 > 3.2. IS-IS ATT Bit considerations . . . . . . . 3.2. IS-IS ATT Bit considerations . . . . . . . > . . . . . . . 8 . . . . . . . 8 > 4. LFA selection for the multi-homed external 4. LFA selection for the multi-homed external > prefixes . . . . . 8 prefixes . . . . . 9 > 4.1. IS-IS . . . . . . . . . . . . . . . . . . . 4.1. IS-IS . . . . . . . . . . . . . . . . . . . > . . . . . . . 8 . . . . . . . 9 > 4.2. OSPF . . . . . . . . . . . . . . . . . . . 4.2. OSPF . . . . . . . . . . . . . . . . . . . > . . . . . . . 8 . . . . . . . 9 > 4.2.1. Rules to select alternate ASBR . . . . . 4.2.1. Rules to select alternate ASBR . . . . . > . . . . . . 9 . . . . . . 9 > 4.2.1.1. Multiple ASBRs belonging different area 4.2.1.1. Multiple ASBRs belonging different area > . . . . . 11 . . . . . 11 > 4.2.1.2. Type 1 and Type 2 costs . . . . . . . . 4.2.1.2. Type 1 and Type 2 costs . . . . . . . . > . . . . . 11 . . . . . 11 > 4.2.1.3. RFC1583compatibility is set to enabled 4.2.1.3. RFC1583compatibility is set to enabled > . . . . . 11 . . . . . 11 > 4.2.1.4. Type 7 routes . . . . . . . . . . . . . 4.2.1.4. Type 7 routes . . . . . . . . . . . . . > . . . . . 11 . . . . . 11 > 4.2.2. Inequalities to be applied for alternate 4.2.2. Inequalities to be applied for alternate > ASBR ASBR > selection . . . . . . . . . . . . . . . . . . . selection . . . . . . . . . . . . . . . . . . . > . . . 12 . . . 12 > 4.2.2.1. Forwarding address set to non-zero 4.2.2.1. Forwarding address set to non-zero > value . . . . 12 value . . . . 12 > 4.2.2.2. ASBRs advertising type1 and type2 cost 4.2.2.2. ASBRs advertising type1 and type2 cost > . . . . . 12 . . . . . 13 > 5. LFA Extended Procedures . . . . . . . . . . . 5. LFA Extended Procedures . . . . . . . . . . . > . . . . . . . . 13 . . . . . . . . 13 > 5.1. Links with IGP MAX_METRIC . . . . . . . . . 5.1. Links with IGP MAX_METRIC . . . . . . . . . > . . . . . . . 13 . . . . . . . 13 > 5.2. Multi Topology Considerations . . . . . . . 5.2. Multi Topology Considerations . . . . . . . > . . . . . . . 14 . . . . . . . 14 > 6. IANA Considerations . . . . . . . . . . . . . 6. IANA Considerations . . . . . . . . . . . . . > . . . . . . . . 15 . . . . . . . . 15 > 7. Acknowledgements . . . . . . . . . . . . . . 7. Acknowledgements . . . . . . . . . . . . . . > . . . . . . . . 15 . . . . . . . . 15 > 8. Contributing Authors . . . . . . . . . . . . 8. Contributing Authors . . . . . . . . . . . . > . . . . . . . . 15 . . . . . . . . 15 > 9. Security Considerations . . . . . . . . . . . 9. Security Considerations . . . . . . . . . . . > . . . . . . . . 16 . . . . . . . . 16 > 10. References . . . . . . . . . . . . . . . . . 10. References . . . . . . . . . . . . . . . . . > . . . . . . . . 16 . . . . . . . . 16 > 10.1. Normative References . . . . . . . . . . . 10.1. Normative References . . . . . . . . . . . > . . . . . . . 16 . . . . . . . 16 > 10.2. Informative References . . . . . . . . . . 10.2. Informative References . . . . . . . . . . > . . . . . . . 16 . . . . . . . 16 > Authors' Addresses . . . . . . . . . . . . . . . Authors' Addresses . . . . . . . . . . . . . . . > . . . . . . . . 18 . . . . . . . . 18 > 1. Introduction 1. Introduction > A framework for the development of IP A framework for the development of IP > fast-reroute mechanisms is fast-reroute mechanisms is > detailed in [RFC5714]. The use of LFAs for IP detailed in [RFC5714]. The use of LFAs for IP > Fast Reroute is Fast Reroute is > specified in [RFC5286]. Section 6.1 of [RFC5286] specified in [RFC5286]. If a prefix is > describes a method advertised by more than one > to determine LFAs for multi-homed prefixes router that prefix is called as multi-homed > (MHPs). This document prefix(MHP). MHPs > describes a procedure using explicit generally occur for prefixes obtained from > inequalities that can be used by outside the routing domain > a computing router to evaluate a neighbor as a by multiple routers, for subnets on links where > potential alternate the subnet is > for a multi-homed prefix. The results obtained announced from multiple ends of the link, and > are equivalent to for prefixes advertised > those obtained using the method described in by multiple routers to provide resiliency. > Section 6.1 of > [RFC5286]. However, some may find this > formulation useful. > Section 6.1 of [RFC5286] describes a method to > determine LFAs for > 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 MHP. The results > obtained are equivalent > to those obtained using the method described in > Section 6.1 of > [RFC5286]. > Section 6.3 of [RFC5286] discusses complications Section 6.3 of [RFC5286] discusses complications > associated with associated with > computing LFAs for multi-homed prefixes in OSPF. computing LFAs for MHPs in OSPF. This document > This document provides detailed > provides detailed criteria for evaluating criteria for evaluating potential alternates for > potential alternates for external prefixes > external prefixes advertised by OSPF ASBRs, as advertised by OSPF ASBRs, as well as explicit > well as explicit inequalities. > inequalities. > This document also provides clarifications, This document also provides clarifications, > additional considerations additional considerations > to [RFC5286], to address a few coverage and to [RFC5286], to address a few coverage and > operational observations. operational observations. > These observations are in the area of handling These observations are in the area of handling > IS-IS attach (ATT) bit IS-IS attach (ATT) bit > in Level-1 (L1) area, links provisioned with in Level-1 (L1) area, links provisioned with > MAX_METRIC for traffic MAX_METRIC (see > engineering (TE) purposes and in the area of Section 5.1) for traffic engineering (TE) > Multi Topology (MT) IGP purposes and in the area of > deployments. These are elaborated in detail in Multi Topology (MT) IGP deployments. These are > Section 3.2 and elaborated in detail > Section 5. in Section 3.2 and Section 5. > This specification uses the same terminology This specification uses the same terminology > introduced in [RFC5714] introduced in [RFC5714] > to represent LFA and builds on the inequalities to represent LFA and builds on the inequalities > notation used in notation used in > [RFC5286] to compute LFAs for MHPs. [RFC5286] to compute LFAs for MHPs. > 1.1. Acronyms 1.1. Acronyms > AF - Address Family AF - Address Family > ATT - IS-IS Attach Bit ATT - IS-IS Attach Bit > skipping to change at page 3, line 47 P: skipping to change at page 4, line 4 P: > 1.1. Acronyms 1.1. Acronyms > AF - Address Family AF - Address Family > ATT - IS-IS Attach Bit ATT - IS-IS Attach Bit > ECMP - Equal Cost Multi Path ECMP - Equal Cost Multi Path > IGP - Interior Gateway Protocol IGP - Interior Gateway Protocol > IS-IS - Intermediate System to Intermediate IS-IS - Intermediate System to Intermediate > System System > LFA - Loop-Free Alternate LFA - Loop-Free Alternate > LSP - IS-IS Link State PDU LSP - IS-IS Link State PDU > OSPF - Open Shortest Path First OSPF - Open Shortest Path First > MHP - Multi-homed Prefix MHP - Multi-homed Prefix > MT - Multi Topology MT - Multi Topology > SPF - Shortest Path First PDU SPF - Shortest Path First > 2. LFA inequalities for MHPs 2. LFA inequalities for MHPs > This document proposes the following set of LFA This document proposes the following set of LFA > inequalities for inequalities for > selecting the most appropriate LFAs for selecting the most appropriate LFAs for MHPs. > multi-homed prefixes (MHPs). D_opt(X,Y) terminology > They can be derived from the inequalities in is defined in [RFC5714], which is nothing but > [RFC5286] combined with the metric sum of the > the observation that D_opt(N,P) = Min shortest path from X to Y and Cost(X,Y) > (D_opt(N,PO_i) + Cost(PO_i,P)) introduced in this document > over all PO_i is defined as the metric value of prefix Y from > the prefix > advertising node X. These LFAs can be derived > from the inequalities > in [RFC5286] combined with the observation that > D_opt(N,P) = Min > (D_opt(N,PO_i) + Cost(PO_i,P)) over all PO_i > Link-Protection: Link-Protection: > D_opt(N,PO_i)+ Cost(PO_i,P) < D_opt(N,S) + A neighbor N can provide a loop-free alternate > (LFA) if and only if > 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(N,S) + > D_opt(N,PO_i)+ Cost(PO_i,P) < D_opt(S,PO_best) + D_opt(S,PO_best) + Cost(PO_best,P) > Cost(PO_best,P) > Node-Protection: Link-Protection + Downstream-paths-only: > D_opt(N,PO_i)+ Cost(PO_i,P) < D_opt(N,E) + A subset of loop-free alternates are downstream > paths that must meet > D_opt(E,PO_best) + Cost(PO_best,P) a more restrictive condition that is applicable > to more complex > failure scenarios > Where, D_opt(N,PO_i)+ Cost(PO_i,P) < D_opt(S,PO_best) + > Cost(PO_best,P) > P - The multi-homed prefix being evaluated for > computing alternates Node-Protection: > S - The computing router For an alternate next-hop N to protect against > node failure of a > N - The alternate router being evaluated primary neighbor E for MHP P, N must be > loop-free with > E - The primary next-hop on shortest path from S respect to both E and mhp P. In other words, N's > to path to MHP P must not go > prefix P. through E (where N is the neighbor providing a > loop-free alternate) > PO_i - The specific prefix-originating router > being > evaluated. D_opt(N,PO_i)+ Cost(PO_i,P) < D_opt(N,E) + > PO_best - The prefix-originating router on the D_opt(E,PO_best) + Cost(PO_best,P) > shortest path > from the computing router S to prefix P. > Cost(X,P) - Cost of reaching the prefix P from Where, > prefix > originating node X. P - The multi-homed prefix being evaluated for > D_opt(X,Y) - Distance on the shortest path from computing alternates > node X to node > Y. 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. > Figure 1: LFA inequalities for MHPs Figure 1: LFA inequalities for MHPs > 3. LFA selection for the multi-homed prefixes 3. LFA selection for the multi-homed prefixes > To compute a valid LFA for a given multi-homed To compute a valid LFA for a given MHP P, a > prefix P, a computing computing router S MUST > router S MUST follow one of the appropriate follow one of the appropriate procedures below, > procedures below, for for each alternate > each alternate neighbor N. neighbor N and once for each remote node that > originated the prefix > P. > Link-Protection : Link-Protection : > ================= ================= > 1. If alternate neighbor N is also 1. if, in addition to being an alternate > prefix-originator of P, neighbor, N is also a prefix-originator of P, > 1.a. Select N as a LFA for prefix P 1.a. Select N as a LFA for prefix P > (irrespective of (irrespective of > the metric advertised by N for the prefix P). the metric advertised by N for the prefix P). > 2. Else, evaluate the link-protecting LFA 2. Else, evaluate the link-protecting LFA > inequality for P with inequality for P with > the N as the alternate neighbor. the N as the alternate neighbor. > 2.a. If LFA inequality condition is met, 2.a. If LFA inequality condition is met, > select N as a LFA for prefix P. select N as a LFA for prefix P. > 2.b. Else, N is not a LFA for prefix P. 2.b. Else, N is not a LFA for prefix P. > Link-Protection + Downstream-paths-only : Link-Protection + Downstream-paths-only : > ========================================= ========================================= > 1. Evaluate the link-protecting + 1. Evaluate the link-protecting + > downstream-only LFA inequality downstream-only LFA inequality > for P with the N as the alternate neighbor. for P with the N as the alternate neighbor. > 1.a. If LFA inequality condition is met, 1.a. If LFA inequality condition is met, > select N as a LFA for prefix P. select N as a LFA for prefix P. > 1.b. Else, N is not a LFA for prefix P. 1.b. Else, N is not a LFA for prefix P. > Node-Protection : Node-Protection : > ================= ================= > 1. If alternate neighbor N is also 1. if, in addition to being an alternate > prefix-originator of P, neighbor, N is also a prefix-originator of P, > 1.a. Select N as a LFA for prefix P 1.a. Select N as a LFA for prefix P > (irrespective of (irrespective of > the metric advertised by N for the prefix P). the metric advertised by N for the prefix P). > 2. Else, evaluate the appropriate 2. Else, evaluate the appropriate > node-protecting LFA inequality node-protecting LFA inequality > for P with the N as the alternate neighbor. for P with the N as the alternate neighbor. > 2.a. If LFA inequality condition is met, 2.a. If LFA inequality condition is met, > select N as a LFA for prefix P. select N as a LFA for prefix P. > 2.b. Else, N is not a LFA for prefix P. 2.b. Else, N is not a LFA for prefix P. > Figure 2: Rules for selecting LFA for MHPs Figure 2: Rules for selecting LFA for MHPs > In case an alternate neighbor N is also one of In case an alternate neighbor N is also one of > the prefix-originators the prefix-originators > of prefix P, N being a prefix-originator it is of prefix P, N being a prefix-originator it is > guaranteed that N will guaranteed that N will > not loop back packets destined for prefix P to not loop back packets destined for prefix P to > computing router S. computing router S. > So N MUST be chosen as a valid LFA for prefix P, So N MUST be chosen as a valid LFA for prefix P, > without evaluating without evaluating > any of the inequalities in Figure 1 as long as any of the inequalities in Figure 1 as long as > downstream-paths-only downstream-paths-only > LFA is not desired. To ensure such a neighbor N LFA is not desired. To ensure such a neighbor N > also provides a also provides a > downstream-paths-only LFA, router S MUST also downstream-paths-only LFA, router S MUST also > evaluate the evaluate the > downstream-only LFA inequality specified in downstream-only LFA inequality specified in > Figure 1 for neighbor N Figure 1 for neighbor N > and ensure router N satisfies the inequality. and ensure router N satisfies the inequality. > However, if N is not a prefix-originator of P, However, if N is not a prefix-originator of P, > the computing router the computing router > SHOULD evaluate one of the corresponding LFA MUST evaluate one of the corresponding LFA > inequalities, as inequalities, as mentioned > mentioned in Figure 1, once for each remote node in Figure 1, once for each remote node that > that originated the originated the prefix. > prefix. In case the inequality is satisfied by In case the inequality is satisfied by the > the neighbor N router neighbor N router S MUST > S MUST choose neighbor N, as one of the valid choose neighbor N, as one of the valid LFAs for > LFAs for the prefix P. the prefix P. > For more specific rules please refer to the For more specific rules please refer to the > later sections of this later sections of this > document. document. > 3.1. Improved coverage with simplified approach 3.1. Improved coverage with simplified approach > to MHPs to MHPs > LFA base specification [RFC5286] Section 6.1 LFA base specification [RFC5286] Section 6.1 > recommends that a router recommends that a router > computes the alternate next-hop for an IGP computes the alternate next-hop for an IGP MHP > multi-homed prefix by by considering > considering alternate paths via all routers that alternate paths via all routers that have > have announced that announced that prefix and > prefix and the same has been elaborated with the same has been elaborated with appropriate > appropriate inequalities inequalities in the > in the above section. However, [RFC5286] Section above section. However, [RFC5286] Section 6.1 > 6.1 also allows for also allows for the > the router to simplify the multi-homed prefix router to simplify the MHP calculation by > calculation by assuming 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 MHP > calculation by assuming > that the MHP is solely attached to the router that the MHP is solely attached to the router > that was its pre- that was its pre- > failure optimal point of attachment, at the failure optimal point of attachment, the > expense of potentially procedure described in this > lower coverage. If an implementation chooses to memo can potentially improve coverage for equal > simplify the multi- cost multi path > homed prefix calculation by assuming that the (ECMP) MHPs without incurring extra > MHP is solely attached computational cost. > 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. > This document improves the above approach to This document improves the above approach to > provide loop-free provide loop-free > alternatives without any additional cost for alternatives without any additional cost for > ECMP MHPs as described ECMP MHPs as described > through the below example network presented in through the below example network presented in > Figure 3. The Figure 3. The > approach specified here MAY also be applicable approach specified here may also be applicable > for handling default for handling default > routes as explained in Section 3.2. routes as explained in Section 3.2. > 5 +---+ 8 +---+ 5 +---+ 5 +---+ 8 +---+ 5 +---+ > +-----| S |------| A |-----| B | +-----| S |------| A |-----| B | > | +---+ +---+ +---+ | +---+ +---+ +---+ > | | | | | | > | 5 | 5 | | 5 | 5 | > | | | | | | > +---+ 5 +---+ 4 +---+ 1 +---+ +---+ 5 +---+ 4 +---+ 1 +---+ > | C |---| E |-----| M |-------| F | | C |---| E |-----| M |-------| F | > skipping to change at page 8, line 19 P: skipping to change at page 9, line 7 P: > advertising ATT (attach) bit in its LSP-0 advertising ATT (attach) bit in its LSP-0 > fragment. All L1 routers fragment. All L1 routers > in the area would do this during the decision in the area would do this during the decision > process with the next- process with the next- > hop of the default route set to the adjacent hop of the default route set to the adjacent > router through which the router through which the > closest L1/L2 router is reachable. The base LFA closest L1/L2 router is reachable. The base LFA > specification specification > [RFC5286] does not specify any procedure for [RFC5286] does not specify any procedure for > computing LFA for a computing LFA for a > default route in IS-IS L1 area. This document default route in IS-IS L1 area. This document > specifies, a node can specifies, a node can > consider a default route is being advertised consider a default route is being advertised > from the border L1/L2 from the border L1/L2 > router where ATT bit is set, and can do LFA router where ATT bit is set, and can do LFA > computation for that computation for that > default route. But, when multiple ECMP L1/L2 default route. But, when multiple ECMP L1/L2 > routers are reachable routers are reachable > in an L1 area corresponding best LFAs SHOULD be in an L1 area corresponding best LFAs SHOULD be > given for each given for each > primary next-hop associated with default route. primary next-hop associated with default route > Considerations as as this would be > specified in Section 3 and Section 3.1 are similar to ECMP MHP example as described in > applicable for default Section 3.1. > routes, if the default route is considered as Considerations as specified in Section 3 and > ECMP MHP. Note that, Section 3.1 are > this document doesn't alter any ECMP handling applicable for default routes, if the default > rules or computation of route is considered as > LFAs for ECMP in general as laid out in ECMP MHP. Note that, this document doesn't alter > [RFC5286]. any ECMP handling > rules or computation of LFAs for ECMP in general > as laid out in > [RFC5286]. > 4. LFA selection for the multi-homed external 4. LFA selection for the multi-homed external > prefixes prefixes > Redistribution of external routes into IGP is Redistribution of external routes into IGP is > required in case of two required in case of two > different networks getting merged into one or different networks getting merged into one or > during protocol during protocol > migrations. External routes could be distributed migrations. External routes could be distributed > into an IGP domain into an IGP domain > via multiple nodes to avoid a single point of via multiple nodes to avoid a single point of > failure. failure. > During LFA calculation, alternate LFA next-hops During LFA calculation, alternate LFA next-hops > to reach the best to reach the best > ASBR could be used as LFA for the routes ASBR could be used as LFA for the routes > redistributed via that ASBR. redistributed via that ASBR. > When there is no LFA available to the best ASBR, When there is no LFA available to the best ASBR, > it may be desirable it may be desirable > to consider the other ASBRs (referred to as to consider the other ASBRs (referred to as > alternate ASBR hereafter) alternate ASBR hereafter) > redistributing the external routes for LFA redistributing the external routes for LFA > selection as defined in selection as defined in > [RFC5286] and leverage the advantage of having [RFC5286] and leverage the advantage of having > multiple re- multiple re- > distributing nodes in the network. distributing nodes in the network. > 4.1. IS-IS 4.1. IS-IS > LFA evaluation for multi-homed external prefixes LFA evaluation for multi-homed external prefixes > in IS-IS is similar in IS-IS is same to > to the multi-homed internal prefixes. the multi-homed internal prefixes. Inequalities > Inequalities described in described in > Section 2 would also apply to multi-homed Section 2 would also apply to multi-homed > external prefixes. external prefixes. > 4.2. OSPF 4.2. OSPF > Loop Free Alternates [RFC5286] describes Loop Free Alternates [RFC5286] describes > mechanisms to apply mechanisms to apply > inequalities to find the loop free alternate inequalities to find the loop free alternate > neighbor. For the neighbor. For the > selection of alternate ASBR for LFA selection of alternate ASBR for LFA > consideration, additional rules consideration, additional rules > have to be applied in selecting the alternate have to be applied in selecting the alternate > ASBR due to the ASBR due to the > external route calculation rules imposed by external route calculation rules imposed by > [RFC2328]. [RFC2328]. > skipping to change at page 10, line 23 P: skipping to change at page 10, line 25 P: > consider next ASBR. consider next ASBR. > 2. Compare cost types (type 1/type 2) advertised 2. Compare cost types (type 1/type 2) advertised > by alternate ASBR and by alternate ASBR and > by the primary ASBR by the primary ASBR > 2a. If not the same type skip alternate ASBR and 2a. If not the same type skip alternate ASBR and > consider next ASBR. consider next ASBR. > 2b. If same proceed to step 3. 2b. If same proceed to step 3. > 3.If cost types are type 1, compare costs 3.If cost types are type 1, compare costs > advertised by alternate ASBR advertised by alternate ASBR > and by the primary ASBR and by the primary ASBR > 3a. If costs are the same then program ECMP FRR 3a. If costs are the same then program ECMP Fast > and return. ReRoute (FRR) and return. > 3b. else go to step 5.. 3b. else go to step 5.. > 4 If cost types are type 2, compare costs 4 If cost types are type 2, compare costs > advertised by alternate ASBR advertised by alternate ASBR > and by the primary ASBR and by the primary ASBR > 4a. If costs are different, skip alternate ASBR 4a. If costs are different, skip alternate ASBR > and and > consider next ASBR. consider next ASBR. > 4b. If cost are the same, proceed to step 4c to 4b. If cost are the same, proceed to step 4c to > compare compare > cost to reach ASBR/forwarding address. cost to reach ASBR/forwarding address. > 4c. If cost to reach ASBR/forwarding address are 4c. If cost to reach ASBR/forwarding address are > also same also same > program ECMP FRR and return. program ECMP FRR and return. > 4d. If cost to reach ASBR/forwarding address are 4d. If cost to reach ASBR/forwarding address are > different different > go to step 5. go to step 5. > 5. If route type (type 5/type 7) 5. If route type (type 5/type 7) > 5a. If route type is same, check route p-bit, 5a. If route type is same, check if the route > p-bit and the > forwarding address field for routes from both forwarding address field for routes from both > ASBRs match. If p-bit and forwarding address ASBRs match. If p-bit and forwarding address > matches matches > proceed to step 6. proceed to step 6. > If not, skip this alternate ASBR and consider If not, skip this alternate ASBR and consider > next ASBR. next ASBR. > 5b. If route type is not same, skip this 5b. If route type is not same, skip this > alternate ASBR alternate ASBR > and consider next alternate ASBR. and consider next alternate ASBR. > 6. Apply inequality on the alternate ASBR. 6. Apply inequality on the alternate ASBR. > skipping to change at page 11, line 20 P: skipping to change at page 11, line 20 P: > should be applied to ensure that the alternate should be applied to ensure that the alternate > neighbor does not neighbor does not > cause looping. cause looping. > When there are multiple ASBRs belonging to When there are multiple ASBRs belonging to > different area advertising different area advertising > the same prefix, pruning rules as defined in the same prefix, pruning rules as defined in > [RFC2328] section 16.4.1 [RFC2328] section 16.4.1 > are applied. The alternate ASBRs pruned using are applied. The alternate ASBRs pruned using > above rules are not above rules are not > considered for LFA evaluation. considered for LFA evaluation. > 4.2.1.2. Type 1 and Type 2 costs 4.2.1.2. Type 1 and Type 2 costs > If there are multiple ASBRs not pruned via rules If there are multiple ASBRs not pruned via rules > defined in described in > Section 4.2.1.1, the cost type advertised by the Section 4.2.1.1, the cost type advertised by the > ASBRs is compared. ASBRs is compared. > ASBRs advertising type 1 costs are preferred and ASBRs advertising type 1 costs are preferred and > the type 2 costs are the type 2 costs are > pruned. If two ASBRs advertise same type 2 cost, pruned. If two ASBRs advertise same type 2 cost, > the alternate ASBRs the alternate ASBRs > are considered along with their cost to reach are considered along with their cost to reach > ASBR/forwarding adress ASBR/forwarding adress > for evaluation. If the two ASBRs have same type for evaluation. If the two ASBRs have same type > 2 cost as well as 2 cost as well as > same cost to reach ASBR, ECMP FRR is programmed. same cost to reach ASBR, ECMP FRR is programmed. > When there are When there are > multiple ASBRs advertising same type 2 cost for multiple ASBRs advertising same type 2 cost for > the prefix, primary the prefix, primary > AS external route calculation as described in Autonomous System (AS) external route > [RFC2328] section calculation as described in > 16.4.1 selects the route with lowest type 2 [RFC2328] section 16.4.1 selects the route with > cost. ASBRs advertising lowest type 2 cost. > different type 2 cost (higher cost) are not ASBRs advertising different type 2 cost (higher > considered for LFA cost) are not > evaluation. Alternate ASBRs advertising type 2 considered for LFA evaluation. Alternate ASBRs > cost for the prefix advertising type 2 > but are not chosen as primary due to higher cost cost for the prefix but are not chosen as > to reach ASBR are primary due to higher cost > considered for LFA evaluation.The inequalities to reach ASBR are considered for LFA > for evaluating evaluation.The inequalities for > alternate ASBR for type 1 and type 2 costs are evaluating alternate ASBR for type 1 and type 2 > same, as the alternate costs are same, as > ASBRs with different type 2 costs are pruned and the alternate ASBRs with different type 2 costs > the evaluation is are pruned and the > based on equal type 2 cost ASBRS. evaluation is based on equal type 2 cost ASBRS. > 4.2.1.3. RFC1583compatibility is set to enabled 4.2.1.3. RFC1583compatibility is set to enabled > When RFC1583Compatibility is set to enabled, When RFC1583Compatibility is set to enabled, > multiple ASBRs belonging multiple ASBRs belonging > to different area advertising same prefix are to different area advertising same prefix are > chosen based on cost chosen based on cost > and hence are valid alternate ASBRs for the LFA and hence are valid alternate ASBRs for the LFA > evaluation. The evaluation. The > inequalities described in Section 4.2.2 are inequalities described in Section 4.2.2 are > applicable based on applicable based on > forwarding address and cost type advertised in forwarding address and cost type advertised in > External LSA. External Link State > Advertisement (LSA). > 4.2.1.4. Type 7 routes 4.2.1.4. Type 7 routes > Type 5 routes always get preference over Type 7 Type 5 routes always get preference over Type 7 > and the alternate and the alternate > ASBRs chosen for LFA calculation should belong ASBRs chosen for LFA calculation should belong > to same type. Among to same type. Among > Type 7 routes, routes with p-bit and forwarding Type 7 routes, routes with p-bit and forwarding > address set have address set have > higher preference than routes without these higher preference than routes without these > attributes. Alternate attributes. Alternate > ASBRs selected for LFA comparison should have ASBRs selected for LFA comparison should have > same p-bit and same p-bit and > forwarding address attributes. forwarding address attributes. > 4.2.2. Inequalities to be applied for alternate 4.2.2. Inequalities to be applied for alternate > ASBR selection ASBR selection > The alternate ASBRs selected using above The alternate ASBRs selected using above > mechanism described in mechanism described in > Section 4.2.1, are evaluated for Loop free Section 4.2.1, are evaluated for Loop free > criteria using below criteria using below > inequalities. inequalities. > 4.2.2.1. Forwarding address set to non-zero 4.2.2.1. Forwarding address set to non-zero > value value > Similar to inequalities as defined in Figure 1, > the following > inequalities are defined when forwarding address > is a non-zero value. > Link-Protection: Link-Protection: > F_opt(N,PO_i)+ Cost(PO_i,P) < D_opt(N,S) + F_opt(N,PO_i)+ Cost(PO_i,P) < D_opt(N,S) + > F_opt(S,PO_best) + Cost(PO_best,P) F_opt(S,PO_best) + Cost(PO_best,P) > Link-Protection + Downstream-paths-only: Link-Protection + Downstream-paths-only: > F_opt(N,PO_i)+ Cost(PO_i,P) < F_opt(S,PO_best) + F_opt(N,PO_i)+ Cost(PO_i,P) < F_opt(S,PO_best) + > Cost(PO_best,P) Cost(PO_best,P) > Node-Protection: Node-Protection: > F_opt(N,PO_i)+ Cost(PO_i,P) < D_opt(N,E) + F_opt(N,PO_i)+ Cost(PO_i,P) < D_opt(N,E) + > F_opt(E,PO_best) + Cost(PO_best,P) F_opt(E,PO_best) + Cost(PO_best,P) > skipping to change at page 13, line 4 P: skipping to change at page 13, line 6 P: > from the computing router S to prefix P. from the computing router S to prefix P. > Cost(X,Y) - External cost for Y as advertised by Cost(X,Y) - External cost for Y as advertised by > X X > F_opt(X,Y) - Distance on the shortest path from F_opt(X,Y) - Distance on the shortest path from > node X to Forwarding node X to Forwarding > address specified by ASBR Y. address specified by ASBR Y. > D_opt(X,Y) - Distance on the shortest path from D_opt(X,Y) - Distance on the shortest path from > node X to node Y. node X to node Y. > Figure 6: LFA inequality definition when Figure 6: LFA inequality definition when > forwarding address is non- forwarding address is non- > zero zero > 4.2.2.2. ASBRs advertising type1 and type2 cost 4.2.2.2. ASBRs advertising type1 and type2 cost > Similar to inequalities as defined in Figure 1, > the following > inequlities are defined for type1 and type2 > cost. > Link-Protection: Link-Protection: > D_opt(N,PO_i)+ Cost(PO_i,P) < D_opt(N,S) + D_opt(N,PO_i)+ Cost(PO_i,P) < D_opt(N,S) + > D_opt(S,PO_best) + Cost(PO_best,P) D_opt(S,PO_best) + Cost(PO_best,P) > Link-Protection + Downstream-paths-only: Link-Protection + Downstream-paths-only: > D_opt(N,PO_i)+ Cost(PO_i,P) < D_opt(S,PO_best) + D_opt(N,PO_i)+ Cost(PO_i,P) < D_opt(S,PO_best) + > Cost(PO_best,P) Cost(PO_best,P) > Node-Protection: Node-Protection: > D_opt(N,PO_i)+ Cost(PO_i,P) < D_opt(N,E) + D_opt(N,PO_i)+ Cost(PO_i,P) < D_opt(N,E) + > D_opt(E,PO_best) + Cost(PO_best,P) D_opt(E,PO_best) + Cost(PO_best,P) > skipping to change at page 13, line 29 P: skipping to change at page 13, line 35 P: > N - The alternate router being evaluated N - The alternate router being evaluated > E - The primary next-hop on shortest path from S E - The primary next-hop on shortest path from S > to to > prefix P. prefix P. > PO_i - The specific prefix-originating router PO_i - The specific prefix-originating router > being being > evaluated. evaluated. > PO_best - The prefix-originating router on the PO_best - The prefix-originating router on the > shortest path shortest path > from the computing router S to prefix P. from the computing router S to prefix P. > Cost(X,Y) - External cost for Y as advertised by Cost(X,Y) - External cost for Y as advertised by > X. X. > D_opt(X,Y) - Distance on the shortest path from D_opt(X,Y) - Distance on the shortest path from > node X to node Y. node X to node Y. > Figure 7: LFA inequality definition for type1 Figure 7: LFA inequality definition for type1 > and type 2 cost and type2 cost > 5. LFA Extended Procedures 5. LFA Extended Procedures > This section explains the additional This section explains the additional > considerations in various considerations in various > aspects as listed below to the base LFA aspects as listed below to the base LFA > specification [RFC5286]. specification [RFC5286]. > 5.1. Links with IGP MAX_METRIC 5.1. Links with IGP MAX_METRIC > Section 3.5 and 3.6 of [RFC5286] describe Section 3.5 and 3.6 of [RFC5286] describe > procedures for excluding procedures for excluding > nodes and links from use in alternate paths nodes and links from use in alternate paths > based on the maximum link based on the maximum link > metric (as defined for IS-IS in [RFC5305] or as metric. If these procedures are strictly > defined in [RFC6987] followed, there are > for OSPF). If these procedures are strictly > followed, there are > situations, as described below, where the only situations, as described below, where the only > potential alternate potential alternate > available which satisfies the basic loop-free available which satisfies the basic loop-free > condition will not be condition will not be > considered as alternative. considered as alternative. This document refers > the maximum link > metric in IGPs as the MAX_METRIC. MAX_METRIC is > defined for IS-IS in > [RFC5305], where it is called as "maximum link > metric" and defined > for OSPF in [RFC6987], where it is called as > "MaxLinkMetric". > +---+ 10 +---+ 10 +---+ +---+ 10 +---+ 10 +---+ > | S |------|N1 |-----|D1 | | S |------|N1 |-----|D1 | > +---+ +---+ +---+ +---+ +---+ +---+ > | | | | > 10 | 10 | 10 | 10 | > |MAX_MET(N2 to S) | |MAX_METRIC(N2 to S) | > | | | | > | +---+ | | +---+ | > +-------|N2 |--------+ +-------|N2 |--------+ > +---+ +---+ > 10 | 10 | > +---+ +---+ > |D2 | |D2 | > +---+ +---+ > Figure 8: Link with IGP MAX_METRIC Figure 8: Link with IGP MAX_METRIC > skipping to change at page 14, line 50 P: skipping to change at page 15, line 7 P: > the router to fix this particular issue. the router to fix this particular issue. > 5.2. Multi Topology Considerations 5.2. Multi Topology Considerations > Section 6.2 and 6.3.2 of [RFC5286] state that Section 6.2 and 6.3.2 of [RFC5286] state that > multi-topology OSPF and multi-topology OSPF and > IS-IS are out of scope for that specification. IS-IS are out of scope for that specification. > This memo clarifies This memo clarifies > and describes the applicability. and describes the applicability. > In Multi Topology (MT) IGP deployments, for each In Multi Topology (MT) IGP deployments, for each > MT ID, a separate MT ID, a separate > shortest path tree (SPT) is built with topology shortest path tree (SPT) is built with topology > specific adjacencies, specific adjacencies, > the LFA principles laid out in [RFC5286] are so the LFA principles laid out in [RFC5286] are > actually applicable for actually applicable > MT IS-IS [RFC5120] LFA SPF. The primary for MT IS-IS [RFC5120] LFA SPF. The primary > difference in this case is, difference in this case > identifying the eligible-set of neighbors for is, identifying the eligible-set of neighbors > each LFA computation for each LFA > which is done per MT ID. The eligible-set for computation which is done per MT ID. The > each MT ID is eligible-set for each MT ID > determined by the presence of IGP adjacency from is determined by the presence of IGP adjacency > Source to the from Source to the > neighboring node on that MT-ID apart from the neighboring node on that MT-ID apart from the > administrative administrative > restrictions and other checks laid out in restrictions and other checks laid out in > [RFC5286]. The same is [RFC5286]. The same is > also applicable for MT-OSPF [RFC4915] or also applicable for MT-OSPF [RFC4915] or > different AFs in multi different AFs in multi > instance OSPFv3 [RFC5838]. instance OSPFv3 [RFC5838]. > However for MT IS-IS, if a "standard topology" However for MT IS-IS, if a "standard topology" > is used with MT-ID #0 is used with MT-ID #0 > [RFC5286] and both IPv4 [RFC5305] and IPv6 [RFC5286] and both IPv4 [RFC5305] and IPv6 > routes/AFs [RFC5308] are routes/AFs [RFC5308] are > present, then the condition of network present, then the condition of network > congruency is applicable for congruency is applicable for > LFA computation as well. Network congruency here LFA computation as well. Network congruency here > refers to, having refers to, having > same address families provisioned on all the same address families provisioned on all the > links and all the nodes links and all the nodes > skipping to change at page 16, line 7 P: skipping to change at page 16, line 20 P: > Email: cbowers@juniper.net Email: cbowers@juniper.net > Bruno Decraene Bruno Decraene > Orange, Orange, > France France > Email: bruno.decraene@orange.com Email: bruno.decraene@orange.com > 9. Security Considerations 9. Security Considerations > Existing OSPF security considerations and The existing OSPF security considerations > stronger authentication and continue to apply, as do > manual key management mechanisms are specified the recommended manual key management mechanisms > in [RFC7474] SHOULD be specified in > considered for OSPF deployments. Security [RFC7474]. The existing security considerations > concerns for IS-IS are for IS-IS also > addressed in [RFC5304] and [RFC5310]. Further continue to apply, as specified in [RFC5304] and > security analysis for [RFC5310] and > IS-IS protocol is done in [RFC7645] SHOULD be extended by [RFC7645] for KARP. This document > considered for IS-IS does not change any of > deployments. This document does not change any the discussed protocol specifications [RFC1195] > of the discussed [RFC5120] [RFC2328] > protocol specifications [RFC1195] [RFC5120] [RFC5838], and the security considerations of > [RFC2328] [RFC5838], and the LFA base > the security considerations of the LFA base specification [RFC5286] therefore continue to > specification [RFC5286] apply. > therefore continue to apply. > 10. References 10. References > 10.1. Normative References 10.1. Normative References > [RFC2119] Bradner, S., "Key words for use in [RFC2119] Bradner, S., "Key words for use in > RFCs to Indicate RFCs to Indicate > Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119, > DOI 10.17487/RFC2119, March 1997, DOI 10.17487/RFC2119, March 1997, > <https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>. > End of changes. 42 change blocks. > 140 lines changed or deleted 172 lines changed or added > This html diff was produced by rfcdiff 1.47. The latest version is available from > http://tools.ietf.org/tools/rfcdiff/
- Benjamin Kaduk's No Objection on draft-ietf-rtgwg… Benjamin Kaduk
- RE: Benjamin Kaduk's No Objection on draft-ietf-r… Uma Chunduri
- Re: Benjamin Kaduk's No Objection on draft-ietf-r… Benjamin Kaduk
- RE: Benjamin Kaduk's No Objection on draft-ietf-r… Uma Chunduri