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?

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