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? ==============