Early Review of draft-ietf-idr-add-paths-guidelines-07
review-ietf-idr-add-paths-guidelines-07-rtgdir-early-bryant-2015-05-20-00

Hello,







I have been selected as the Routing Directorate reviewer
      for this draft. 




The Routing Directorate seeks to review all routing or
      routing-related 




drafts as they pass through IETF last call and IESG review.
      The purpose 




of the review is to provide assistance to the Routing ADs.
      For more 




information about the Routing Directorate, please see 




http://trac.tools.ietf.org/area/rtg/trac/wiki/RtgDir







Although these comments are primarily for the use of the
      Routing ADs, 




it would be helpful if you could consider them along with
      any other 




IETF Last Call comments that you receive, and strive to
      resolve




 them through discussion or by updating the draft.







Document: draft-ietf-idr-add-paths-guidelines-07.txt




Reviewer: Stewart Bryant




Review Date: 20 May 2015




IETF LC End Date: Not yet in IETF LC




Intended Status: Standards Track







Summary:







I have significant concerns about this document and recommend
      that the 


      Routing ADs discuss these issues further with the authors.
    





      (Actually I see that this document has not yet been passed to the
      ADs, 


      so I suggest that the chairs address these issues with the
      authors) 








      I provide comments inline - Please look for SB>







IDR Working
      Group                                             J. Uttaro




Internet-Draft                                                    
      AT&T




Intended status: Standards Track




Expires: Jun 3, 2015                                       
      P. Francois




                                                        
      IMDEA Networks







                                                              
      K. Patel




                                                         
      Cisco Systems







                                                          
      P. Mohapatra




                                                      
      Cumulus Networks







                                                               
      J. Haas




                                                      
      Juniper Networks







                                                            
      A. Simpson




                                                           
      R. Fragassi




                                                        
      Alcatel-Lucent










SB> This document has seven authors against a guideline
      of five.




SB> I assume that the chairs and ADs are happy with
      this.







                                                           
      Dec 3, 2014







        Best Practices for Advertisement of Multiple Paths
      in IBGP




                draft-ietf-idr-add-paths-guidelines-07.txt







SB> I wonder if this document is correct as ST rather
      than BCP? Certainly the 




SB> the title and abstract imply a better match with
      BCP.







SB> There are 9 nits warnings, of which the following
      should be




SB> addressed:







================







  Checking nits according to
      

http://www.ietf.org/id-info/checklist

 :




 
----------------------------------------------------------------------------







  == There are 5 instances of lines with
      non-RFC5735-compliant IPv4 addresses




     in the document.  If these are example addresses, they
      should be changed.










  Miscellaneous warnings:




 
----------------------------------------------------------------------------










  == Line 611 has weird spacing: '...ltipath  selec...'










  Checking references for intended status: Proposed
      Standard




 
----------------------------------------------------------------------------







     (See RFCs 3967 and 4897 for information about using
      normative references




     to lower-maturity documents in RFCs)







  == Missing Reference: 'RFC 4271' is mentioned on line
      153, but not defined







  == Missing Reference: 'RFC-2119' is mentioned on line
      175, but not defined







  == Missing Reference: 'RFC4364' is mentioned on line 808,
      but not defined







  == Unused Reference: 'RFC2119' is defined on line 912,
      but no explicit




     reference was found in the text







  == Unused Reference: 'RFC4271' is defined on line 939,
      but no explicit




     reference was found in the text







  == Outdated reference: A later version (-10) exists of




     draft-ietf-idr-add-paths-07







===============













              ========        =====================




              =  +---+        +---+           +---+




              =  |RTR|________|RTR|           |RTR|




              =  | E |        | A |           | C |




              =  +---+Path A->+---+    AS1    +---+




              =      =        =    \         /    =




              =      =        =     \       /     =




              =      =        =      \     /      =




              =      =        =       \   /       =




              = AS3  =        =       +---+       =




              =      =        =       |RR |       =




              =      =        =       | 1 |       =




              =      =        =       +---+       =




              =      =        =       /   \       =




              =      =        =      /     \      =




              =      =        =     /       \     =




              =      =        =    /         \    =




              =  +---+Path B->+---+           +---+




              =  |RTR|  ______|RTR|           |RTR|




              =  | F |        | B |           | D |




              =  +---+        +---+           +---+




              ========        =====================







                        Figure 1: Example Topology







SB> Surely the advertisments go L to R, but the paths




SB> actually go R to L?










   Under these circumstances consider the steps required to
      restore




   traffic from router D to destination XYZ when the link
      between Router




SB> For clarification " destination XYZ reachable via
      AS3"




   A and Router E fails. (Assume that router A set next-hop
      to self when




   advertising path A and that router B is not configured
      for best-




   external).




SB> is "best-external" the formal name for this
      configuration. If not




SB> I recommend that you use the formal name.







   1. Router A sends a BGP UPDATE message Withdrawing its
      advertisement




      of path (A).




SB> Presumable "Router A sends a BGP UPDATE message to
      RR1 withdrawing..."







============







   5. Router D reruns its decisions process, determines
      path (B) to be




      the best path, and updates its forwarding table.
      After this step




      traffic from router D to destination XYZ is restored
      (the traffic




      path has changed from A to B).







SB> Surely " path has changed from path A to path B"







==========







   1. Router A sends a BGP UPDATE message withdrawing its
      advertisement




      of path (A).







SB> Presumable "Router A sends a BGP UPDATE message to
      RR1 withdrawing..."










   2. RR1 receives the withdrawal, and propagates it to its
      other client




      peers, routers B, C and D.







   3. Router D receives the withdrawal, reruns the decision
      process and




      updates the forwarding entry for destination XYZ.







SB> Wait a minuite here. What about the other other
      routers in the 




SB> network? Maybe you are considering a BGP-free core,
      which is fine




SB> but that has to be noted up front as a constraint,
      but so far




SB> as I can see you do not talk about that. In a BGP
      free core 




SB> what you say holds, but in a regular IP core you may
      get loops




SB> until the on path routers have been converged. This
      really needs some




SB> text.




SB>




SB> You talk about this later in the text, but you
      really need to




SB> at least summarise your important assumptions
      earlier in the text.










   3.2. Load Balancing







   Increased path diversity allows routers to install
      several paths in




   their forwarding tables in order to load balance traffic
      across those




   paths.







SB> Again the matter of BGP free core needs some
      discussion.




SB> In the case of non-BGP-free core it's not quite that
      simple.







   3.3. Churn Reduction







   When Add-Paths is used in an AS, the availability of
      additional




   backup paths means failures can be recovered locally
      with much less




   path exploration in iBGP and therefore less updates
      disseminate in




   eBGP.  When the preferred backup path is the
      post-convergence path,




   churn is minimized.







SB> The text containing "therefore less updates
      disseminate" does 




SB> not scan correctly.




SB> BTW When the preferred backup path is the
      post-convergence path




SB> you don't get loops.







==============







SB> You might consider some RFC2119 language in the
      following para:




   A BGP UPDATE message from an Add-Paths peer may
      advertise and




   withdraw more than one NLRI belonging to one or more
      address




   families. In this case Add-Paths may be supported for
      some of the




   address families and not others. In this situation the
      receiving BGP




   router should not expect that all of the path
      identifiers in the




   UPDATE message will be the same.







===============







   Control Plane Stress: Coping with multiple iBGP paths
      has two




   implications on the computation that a router has to
      handle. First,




   it has to compute the paths to send to its peers, i.e.
      more than the




   best path.  Second, it also has to handle the potential
      churn related




   to the exchange of those multiple paths.







SB> Is there any SIDR and BGPsec related compute stress
      that needs 




SB> to be called out?







===============










   5.2. Scalability Considerations







   In terms of scalability, we note that advertising
      multiple paths per




   prefix requires more memory and state than the current
      behavior of




   advertising the best path only. A BGP speaker that does
      not implement




   Add-Paths maintains send state information in its prefix
      data




   structure per neighbor as a way to determine that the
      prefix has been




   advertised to the neighbor. With Add-Paths, this
      information has to




   be replicated on a per path basis that needs to be
      advertised.




   Mathematically, if "send state" size per prefix is 's'
      bytes, number




   of neighbors is 'n', and number of paths being
      advertised is 'p',




   then the current memory requirement for BGP "send state"
      = n * s




   bytes; with Add-Paths, it becomes n * s * p bytes.







SB> The following are personal preferences which can be
      ingrored if




SB> you wish.




SB> 




SB> If these are the IDR standard terms (n, s, p) then
      fine. However I




SB> was initially confused by the change of meaning and
      case of n.




SB> Elsewhere we use k for number of neighbours. An
      equation




SB> K * s * N might be less confusing. A bit of a nit
      it's




SB> handy if the order of definitions and order of terms
      in




SB> the equation is the same.







==============







   5.4. Consistency between Advertised Paths and Forwarding
      Paths







   When using Add-Paths, routers may advertise paths that
      they have not




   selected as best, and that they are thus not using for
      traffic




   forwarding.  This is generally not an issue if
      encapsulation is used




   in the AS as described in [RFC4364] and all forwarding
      decisions,




   including by the tunnel egress router, are based on
      label information




   - i.e. if only the ingress router performs an IP FIB
      lookup.  In this




   situation the dataplane path followed by the packets is
      the one




   intended by the ingress router, and corresponds to the
      control plane




   path it selected.







SB> I was looking for discussion on this earlier in the
      text




SB> as I was confused about forwarding consistency
      there.







===============










=====================







6. Security Considerations







   TBD







SB> This is a showstopper! It is not possible to advance
      a document




SB> without a security section.







=====================







9. IANA Considerations







   TBD







SB> This is also a showstopper! If there are no IANA
      considerations




SB> this needs to be noted.







10. References







   10.1. Normative References







   [RFC2119]        Bradner, S., "Key words for use in RFCs
      to Indicate




                    Requirement Levels", BCP 14, RFC 2119,
      March 1997.







   10.2. Informative References







   [Add-Paths]      Walton, D., Retana, A., Chen E.,
      Scudder J.,




                    "Advertisement of Multiple Paths in
      BGP", draft-




                    ietf-idr-add-paths-07, June 17, 2012.







SB> I cannot see how this can possibly be informative
      since it is




SB> fundamental to the advice.




SB> I have not checked all of refs for
      Normative/Informative status




SB> but they do need to be checked.







=============







   [RFC4271]        Rekhter, Y., Li, T., Hares, S., "A
      Border Gateway




                    Protocol 4 (BGP-4), January 2006.







SB> Nit -  Trailing quote (") missing.







============










A.3. Advertise Paths at decisive step -1







SB> This really needs a reference. What is decisive step
      minus 1?







==============