Subject: RE: Benjamin Kaduk's No Objection on draft-ietf-rtgwg-multihomed-prefix-lfa-08: (with COMMENT)

From: Uma Chunduri <[email-masked]>
Date: Sat, 17 Nov 2018 00:38:58 +0000

Thanks Benjamin for your detailed review. Changes to address some of your comments are attached (diff file).

Also please see replies in-line [Uma]:

Hope this diff addresses your comments.
--
Uma C.

-----Original Message-----
From: Benjamin Kaduk [mailto:[email-masked]] 
Sent: Monday, October 22, 2018 11:25 AM
To: The IESG <[email-masked]>
Cc: [email-masked]; Stewart Bryant <[email-masked]>; [email-masked]; [email-masked]; [email-masked]
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.

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.

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.

                                                                  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. 

   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.

---

From: Benjamin Kaduk <[email-masked]>
Date: Fri, 16 Nov 2018 18:58:05 -0600

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

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

> [Uma]: This is addressed, please see section 2 changes.

Thanks, this helps a lot.

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

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

>  < 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.         
>                                                    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: [email-masked]                        Email: [email-masked]                       
>  Bruno Decraene                                    Bruno Decraene                                   
>  Orange,                                           Orange,                                          
>  France                                            France                                           
>  Email: [email-masked]                  Email: [email-masked]                 
>  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/

---

From: Uma Chunduri <[email-masked]>
Date: Sat, 17 Nov 2018 01:08:30 +0000

[Removed rest of the discussion as we are in agreement]

		>> [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 have no attachment to my specific proposal.)

I see what you are saying. Sure shall take care of this before upload. Thank you!

--
Uma C.