[Idr] FW: [RTG-DIR] Routing directorate review of draft-ietf-idr-add-paths-guidelines

["Susan Hares" <[e-mail]>]

Fyi - Routing directorate review of add-path-guidelines by Stewart Bryant. 

 

Thank you Stewart for your review!

 

Sue 

 

From: rtg-dir [mailto:[e-mail]] On Behalf Of Stewart Bryant
Sent: Wednesday, May 20, 2015 12:05 PM
To: Jonathan Hardwick
Cc: [e-mail]; [e-mail];
'Alvaro Retana (aretana)'; 'John G. Scudder'; Susan Hares; 'Jon Hudson'
Subject: Re: [RTG-DIR] Routing directorate review of
draft-ietf-idr-add-paths-guidelines

 

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?

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