Skip to main content

Early Review of draft-ietf-idr-add-paths-guidelines-07

Request Review of draft-ietf-idr-add-paths-guidelines
Requested revision No specific revision (document currently at 08)
Type Early Review
Team Routing Area Directorate (rtgdir)
Deadline 2015-05-20
Requested 2015-05-06
Authors Jim Uttaro , Pierre Francois , Keyur Patel , Jeffrey Haas , Adam Simpson , Roberto Fragassi
I-D last updated 2015-05-20
Completed reviews Rtgdir Early review of -07 by Stewart Bryant (diff)
Assignment Reviewer Stewart Bryant
State Completed
Request Early review on draft-ietf-idr-add-paths-guidelines by Routing Area Directorate Assigned
Reviewed revision 07 (document currently at 08)
Result Not ready
Completed 2015-05-20


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

The Routing Directorate seeks to review all routing or

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

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

 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


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

      so I suggest that the chairs address these issues with the

      I provide comments inline - Please look for SB>

IDR Working
      Group                                             J. Uttaro


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


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

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

      Dec 3, 2014

        Best Practices for Advertisement of Multiple Paths
      in IBGP


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

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

SB> addressed:


  Checking nits according to



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


     (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



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

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

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

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

SB> For clarification " destination XYZ reachable via

   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-


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

      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

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


SB> Again the matter of BGP free core needs some

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

   3.3. Churn Reduction

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

   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

   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

   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

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

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

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

SB> the equation is the same.


   5.4. Consistency between Advertised Paths and Forwarding

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

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

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

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

   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

SB> as I was confused about forwarding consistency



6. Security Considerations


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

SB> without a security section.


9. IANA Considerations


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

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?