Early Review of draft-ietf-idr-route-oscillation-stop-00
review-ietf-idr-route-oscillation-stop-00-rtgdir-early-przygienda-2015-05-27-00

Request Review of draft-ietf-idr-route-oscillation-stop
Requested rev. no specific revision (document currently at 04)
Type Early Review
Team Routing Area Directorate (rtgdir)
Deadline 2015-05-27
Requested 2015-04-27
Authors Daniel Walton, Alvaro Retana, Enke Chen, John Scudder
Draft last updated 2015-05-27
Completed reviews Genart Last Call review of -02 by Paul Kyzivat (diff)
Genart Last Call review of -02 by Paul Kyzivat (diff)
Secdir Last Call review of -02 by Chris Lonvick (diff)
Opsdir Last Call review of -02 by Jon Mitchell (diff)
Rtgdir Early review of -00 by Tony Przygienda (diff)
Rtgdir Early review of -02 by He Jia (diff)
Assignment Reviewer Tony Przygienda
State Completed
Review review-ietf-idr-route-oscillation-stop-00-rtgdir-early-przygienda-2015-05-27
Reviewed rev. 00 (document currently at 04)
Review result Has Issues
Review completed: 2015-05-27

Review
review-ietf-idr-route-oscillation-stop-00-rtgdir-early-przygienda-2015-05-27






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, and sometimes
 on special request. 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-route-oscillation-stop-00


Reviewer: Tony Przygienda 


Review Date: 5/26/15


Intended Status: Standards




Summary:










I have some minor concerns about this document that I think should be resolved before publication. In short: very good BCP draft albeit terse unless very skilled in the art, too loose
 for a standards track (at least in the current form) IMO. Comments below. 




 







 




Network Working Group                                          D. Walton




Internet-Draft                                          Cumulus Networks




Intended status: Standards Track                               A. Retana




 




PRZ> I would like to question whether this is a standards Track document ?





PRZ> It looks to me more BCP than Standards track. It relies on peers





PRZ> supporting on optional capability and then it only SHOULDs the





PRZ> intended behavior. In fact there is not a single normative MUST in





PRZ> the whole document.





 




Expires: August 6, 2015                                          E. Chen




                                                     Cisco Systems, Inc.




                                                              J. Scudder




                                                        Juniper Networks




                                                        February 2, 2015




 




 




               BGP Persistent Route Oscillation Solutions




                draft-ietf-idr-route-oscillation-stop-00




 




Abstract




 




   In this document we present two sets of paths for an address prefix




   that can be advertised by a BGP route reflector or confederation ASBR




   to eliminate the MED-induced route oscillations in a network.  The




   first set involves all the available paths, and would achieve the




   same routing consistency as the full IBGP mesh.  The second set,




   which is a subset of the first one, involves the neighbor-AS based




   Group Best Paths, and would be sufficient to eliminate the MED-




   induced route oscillations (subject to certain commonly adopted




   topological constrains).




 




Status of This Memo




 




   This Internet-Draft is submitted in full conformance with the




   provisions of BCP 78 and BCP 79.




 




   Internet-Drafts are working documents of the Internet Engineering




   Task Force (IETF).  Note that other groups may also distribute




   working documents as Internet-Drafts.  The list of current Internet-




   Drafts is at


http://datatracker.ietf.org/drafts/current/

.




 




   Internet-Drafts are draft documents valid for a maximum of six months




   and may be updated, replaced, or obsoleted by other documents at any




   time.  It is inappropriate to use Internet-Drafts as reference




   material or to cite them other than as "work in progress."




 




   This Internet-Draft will expire on August 6, 2015.




 




Copyright Notice




 




   Copyright (c) 2015 IETF Trust and the persons identified as the




   document authors.  All rights reserved.




 




 




 




 




 




Walton, et al.           Expires August 6, 2015                 [Page 1]




Àpar Internet-Draft          BGP Oscillation Solutions          February 2015




 




 




   This document is subject to BCP 78 and the IETF Trust's Legal




   Provisions Relating to IETF Documents




   (

http://trustee.ietf.org/license-info

) in effect on the date of




   publication of this document.  Please review these documents




   carefully, as they describe your rights and restrictions with respect




   to this document.  Code Components extracted from this document must




   include Simplified BSD License text as described in Section 4.e of




   the Trust Legal Provisions and are provided without warranty as




   described in the Simplified BSD License.




 




Table of Contents




 




   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2




   2.  Requirements Language . . . . . . . . . . . . . . . . . . . .   3




   3.  Advertise the Available Paths . . . . . . . . . . . . . . . .   3




   4.  Advertise the Group Best Paths  . . . . . . . . . . . . . . .   3




   5.  Route Reflection and Confederation  . . . . . . . . . . . . .   4




     5.1.  Route Reflection  . . . . . . . . . . . . . . . . . . . .   5




     5.2.  Confederation . . . . . . . . . . . . . . . . . . . . . .   5




   6.  Deployment Considerations . . . . . . . . . . . . . . . . . .   5




   7.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   6




  8.  Security Considerations . . . . . . . . . . . . . . . . . . .   6




   9.  Acknowledgements  . . . . . . . . . . . . . . . . . . . . . .   7




   10. References  . . . . . . . . . . . . . . . . . . . . . . . . .   7




     10.1.  Normative References . . . . . . . . . . . . . . . . . .   7




     10.2.  Informative References . . . . . . . . . . . . . . . . .   7




   Appendix A.  Why the Group Best Paths Are Adequate? . . . . . . .   7




   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   8




 




1.  Introduction




 




   As documented in [RFC3345], the routing information reduction by BGP




   Route Reflection [RFC4456] or BGP Confederation [RFC5065] can result




   in persistent IBGP route oscillations with certain routing setup and




   network topologies.  Except for a couple artificially engineered




   network topologies, the MED attribute [RFC4271] has played a pivotal




   role in virtually all of the known persistent IBGP route




   oscillations.  For the sake of brevity, we use the term "MED-induced




   route oscillation" hereafter to refer to a persistent IBGP route




   oscillation in which the MED plays a role.




 




   In order to eliminate the MED-induced route oscillations and to




   achieve consistent routing in a network, clearly a route reflector or




   a confederation ASBR needs to advertise more than just the best path




   for an address prefix.  Our goal is to identify the "right" set of




   paths for an address prefix that needs to be advertised by a route




   reflector or a confederation ASBR.




 




 




 




 




Walton, et al.           Expires August 6, 2015                 [Page 2]




Àpar Internet-Draft          BGP Oscillation Solutions          February 2015




 




 




   In this document we present two sets of paths for an address prefix




   that can be advertised by a BGP route reflector or confederation ASBR




   to eliminate the MED-induced route oscillations in a network.  The




   first set involves all the available paths, and would achieve the




   same routing consistency as the full IBGP mesh.  The second set,




   which is a subset of the first one, involves the neighbor-AS based




   Group Best Paths, and would be sufficient to eliminate the MED-




   induced route oscillations (subject to certain commonly adopted




   topological constrains).




 




   These paths can be advertised using the mechanism described in ADD-




   PATH [I-D.ietf-idr-add-paths] for advertising multiple paths.




 




PRZ> I suggest to indicate in the document that all routers in AD MUST be





PRZ> configured to behave consistently when comparing MEDs





PRZ> (i.e. always-compare-med, missing-as-worst and so on need to be





PRZ> consistent).





PRZ> There seems to me a hidden assumption





PRZ> in the document




PRZ> albeit likely obvious for the skilled in the art that





PRZ> always-compare-med is used here (and in fact the overall behavior





PRZ> simulates deterministic-MED?) but IMO it must be mentioned what the





PRZ> assumptions are. Especially for routers that want to the RRC but





PRZ> do NOT support add-path e.g.





PRZ> that they are sometimes employed to fix some of





PRZ> those issues and need to be considered.





 




2.  Requirements Language




 




   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",




   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this




   document are to be interpreted as described in [RFC2119].




 




3.  Advertise the Available Paths




 




   Observe that in a network that maintains a full IBGP mesh all the BGP




   speakers have consistent and equivalent routing information.  Such a




   network is thus free of the MED-induced route oscillations and other




   routing inconsistencies such as forwarding loops.




 




   Therefore one approach is to allow a route reflector or a




   confederation ASBR to advertise all the available paths for an




   address prefix.  Clearly this approach would yield the same amount of




   routing information and achieve the same routing consistency as the




   full IBGP mesh in a network.




 




   This approach can be implemented using the mechanism described in




   ADD-PATH [I-D.ietf-idr-add-paths] for advertising multiple paths for




   certain prefixes.




 




   For the sake of scalability the advertisement of multiple paths




   should be limited to those prefixes which are affected by MED-induced




   route oscillation in a network carrying a large number of alternate




   paths.




  





PRZ> Suggest to specify the precise criteria since those are fairly





PRZ> complicated as far I see or at least refer as example





PRZ> to e.g. 4456 section 11




PRZ> rather than the vague





PRZ> English relative clause encountered here during initial reading. 





PRZ> Or pull up the 4456 reference from section 4





PRZ> and refer from section 4 again in a short form.





PRZ> This will improve logical flow of the document.





PRZ> 





PRZ> Moreover, other mechanisms than avoiding well-known criteria can be





PRZ> imagined, e.g. something that has a hysterisis on # of flaps in





PRZ> a prefix and based on that qualifying a NLRI as a 'MED-induced





PRZ> oscillation affected prefix' to apply the techniques here. 





 




4.  Advertise the Group Best Paths




 




   The term neighbor-AS for a route refers to the neighboring AS from




   which the route was received.  The calculation of the neighbor-AS is




   specified in Sect. 9.1.2.2 of [RFC4271], and Section 7.2 of




   [RFC5065].  By definition the MED is comparable only among routes




   with the same neighbor-AS.





   




PRZ> We all know this can be violated by vendor specific configs and




PRZ> merits mentioning as reference to 4456 again since this is a very





PRZ> 'practical deployment'





PRZ> targeted draft. In fact this draft should reference how two best





PRZ> routes to same prefix via two different ASes (two group best paths





PRZ> to same prefix) should be resolved or ECMP’ed.  




   




   




    Thus the route selection procedures




 




 




 




Walton, et al.           Expires August 6, 2015                 [Page 3]




Àpar Internet-Draft          BGP Oscillation Solutions          February 2015




 




 




   specified in [RFC4271] would conceptually involve two steps: first




   organize the paths for an address prefix into groups according to




   their respective neighbor-AS's, and calculate the most preferred one




   (termed "Group Best Path") for each of the groups; Then calculate the




   overall best path among all the Group Best Paths.




 




PRZ> Per above, pls refer to the resolution and whether it must be





PRZ> uniform across all participating RRCs and iBGP peers involved.





 




   As a generally recommended ([RFC4456], [RFC5065]) and widely adopted




   practice, a route reflection cluster or a confederation sub-AS should




   be designed such that the IGP metrics for links within a cluster (or




   confederation sub-AS) are much smaller than the IGP metrics for the




   links between the clusters (or confederation sub-AS).  This practice




   helps achieve consistent routing within a route reflection cluster or




   a confederation sub-AS.




 




   When the aforementioned practice for devising a route reflection




   cluster or confederation sub-AS is followed in a network, we claim




   that the advertisement of all the Group Best Paths by a route




   reflector or a confederation ASBR is sufficient to eliminate the MED-




   induced route oscillations in the network.  This claim is validated




   in Appendix A.




 




   Note that a Group Best Path for an address prefix can be identified




   by the combination of the address prefix and the neighbor-AS.  Thus




   this approach can be implemented using the mechanism described in




   ADD-PATH [I-D.ietf-idr-add-paths] for advertising multiple paths, and




   in this case the neighbor-AS of a path may be used as the path




   identifier of the path.




 




   It should be noted that the approach of advertising the Group Best




   Paths requires certain topological constrains to be satisfied in




   order to eliminate the MED-induced route oscillation. 





   




PRZ> Please give at least ONE example of what those 'certain topological




PRZ> constraints' are if there are more than the 'short IGP distance inside'




  





   In addition,




   the BGP speakers still depend on the route selection by the route




   reflector or the confederation ASBR.  As the route selection involves




   the comparison of the nexthop's IGP metrics which are specific to a




   particular BGP speaker, the routing information advertised by a route




   reflector or a confederation ASBR may still be inadequate to avoid




   other routing inconsistencies such as forwarding loops in certain




   networks.




  





PRZ> This is simply too vague, especially for a standards track. Please





PRZ> give at least one example of such looping.





 




5.  Route Reflection and Confederation




 




   To allow a route reflector or a confederation ASBR to advertise




   either the Available Paths or Group Best Paths using the mechanism




   described in ADD-PATH [I-D.ietf-idr-add-paths], the following




   revisions are proposed for BGP route reflection and BGP




   Confederation.




 




 




 




 




 




Walton, et al.           Expires August 6, 2015                 [Page 4]




Àpar Internet-Draft          BGP Oscillation Solutions          February 2015




 




 




5.1.  Route Reflection




 




   Depending on the configuration, for a particular <AFI, SAFI> a route




   reflector SHOULD include the <AFI, SAFI> with the "Send/Receive"




   field set to 2 or 3 in the ADD-PATH Capability




   [I-D.ietf-idr-add-paths] advertised to an IBGP peer.  When the ADD-




   PATH Capability is also received from the IBGP peer with the "Send/




   Receive" field set to 1 or 3 for the same <AFI, SAFI>, then the




   following procedures shall be followed:




 




   If the peer is a route reflection client, the route reflector SHOULD




   advertise to the peer the Group Best Paths (or the Available Paths)




   received from its non-client IBGP peers.  Depending on the




   configuration, the route reflector MAY also advertise to the peer the




   Group Best Paths (or the Available Paths) received from its clients.




 




   If the peer is a non-client, the route reflector SHOULD advertise to




   the peer the Group Best Paths (or the Available Paths) received from




   its clients.




 




5.2.  Confederation




 




  Depending on the configuration, for a particular <AFI, SAFI> a




   confederation ASBR SHOULD include the <AFI, SAFI> with the "Send/




   Receive" field set to 2 or 3 in the ADD-PATH Capability




   [I-D.ietf-idr-add-paths] advertised to an IBGP peer, and to a




   confederation external peer.  When the ADD-PATH Capability is also




   received from the IBGP peer or the confederation external peer with




   the "Send/Receive" field set to 1 or 3 for the same <AFI, SAFI>, then




   the following procedures shall be followed:




 




   If the peer is internal, the confederation ASBR SHOULD advertise to




   the peer the Group Best Paths (or the Available Paths) received from




   its confederation external peers.




 




   If the peer is confederation external, the confederation ASBR SHOULD




   advertise to the peer the Group Best Paths (or the Available Paths)




   received from its IBGP peers.




 




PRZ> This needs specification WHAT is advertised to the peers not supporting





PRZ> add-path? if we follow today's behavior, it would be any





PRZ> of the best-group paths broken on IGP metric.





PRZ> I think it is worth mentioning that if ANY of the involved RRs does




PRZ> not support add-path, the solution COULD loop again using IGP as tie-breaker




PRZ> for routes from different ASes.





PRZ>




PRZ> Or is one of the restrictions this draft suggests





PRZ> that all RRs MUST be





PRZ> add-path capable ?





 




6.  Deployment Considerations




 




   Some route oscillations, once detected, can be eliminated by simple




   configuration workarounds.  As carrying additional paths impacts the




   memory usage and routing convergence in a network, it is recommended




   that the impact be evaluated and the approach of using a




   configuration workaround be considered in deciding whether to deploy




   the proposed mechanism in a network.  In addition, the advertisement




 




 




 




 




Walton, et al.           Expires August 6, 2015                 [Page 5]




Àpar Internet-Draft          BGP Oscillation Solutions          February 2015




 




 




   of multiple paths should be limited to those prefixes which are




   affected by MED-induced route oscillation.




 




   While the route reflectors or confederation ASBRs in a network need




   to advertise the Group Best Paths or Available Paths, the vast




   majority of the BGP speakers in the network only need to receive the




   Group Best Paths or Available Paths, which would involve only minor




   software changes.




 




   It should be emphasized that in order to eliminate the MED-induced




   route oscillations in a network using the approach of advertising the




   Group Best Paths, the recommended practice for devising a route




   reflection cluster or confederation sub-AS with respect to the IGP




   metrics ([RFC4456], [RFC5065]) should be followed.




 




   It is expected that the approach of advertising the Group Best Paths




   would be adequate to achieve consistent routing for the vast majority




   of the networks.  For a network that has large number of alternate




   paths, the approach should be a good choice as the number of paths




   advertised by a reflector or a confederation ASBR is bounded by the




   number of the neighbor-AS's for a particular address prefix.  The




   additional states for an address prefix would also be per neighbor-AS




   based rather than per path based.  The number of the neighbor-AS's




   for a particular address prefix is typically small because of the




   limited number of upstream providers for a customer and the nature of




   advertising only customer routes at the inter-exchange points.




 




   The approach of advertising the Group Best Paths, however, may still




   be inadequate for certain networks to avoid other routing




   inconsistencies such as forwarding loops.  The required topological




   constrains could also be operationally challenging.  In these cases




   the approach of advertising the Available Paths may be used, but




   should be limited to those prefixes which are affected by MED-induced




   route oscillation in a network carrying a large number of alternate




   paths.  Note that the number of paths that need to be maintained and




   advertised can be greatly reduced by accepting the IGP metric based




   MEDs from other peering networks.




  





PRZ> does 'IGP metric based MED' mean 'copy IGP into MED & advertise?'.





PRZ> If so, please define the term clearly.





 




7.  IANA Considerations




 




   This memo includes no request to IANA.




 




8.  Security Considerations




 




   This extension to BGP does not change the underlying security issues




   inherent in the existing BGP [RFC4271].




 




 




 




 




 




Walton, et al.           Expires August 6, 2015                 [Page 6]




Àpar Internet-Draft          BGP Oscillation Solutions          February 2015




 




 




9.  Acknowledgements




 




   We would like to thank David Cook and Naiming Shen for their




   contributions to the design and development of the solutions.




 




10.  References




 




10.1.  Normative References




 




   [I-D.ietf-idr-add-paths]




              Walton, D., Retana, A., Chen, E., and J. Scudder,




              "Advertisement of Multiple Paths in BGP", draft-ietf-idr-




              add-paths-10 (work in progress), October 2014.




 




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




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




 




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




              Protocol 4 (BGP-4)", RFC 4271, January 2006.




 




   [RFC4456]  Bates, T., Chen, E., and R. Chandra, "BGP Route




              Reflection: An Alternative to Full Mesh Internal BGP




              (IBGP)", RFC 4456, April 2006.




 




   [RFC5065]  Traina, P., McPherson, D., and J. Scudder, "Autonomous




              System Confederations for BGP", RFC 5065, August 2007.




 




10.2.  Informative References




 




   [RFC3345]  McPherson, D., Gill, V., Walton, D., and A. Retana,




              "Border Gateway Protocol (BGP) Persistent Route




              Oscillation Condition", RFC 3345, August 2002.




 




Appendix A.  Why the Group Best Paths Are Adequate?




 




PRZ> It seems to me there is another, more easily understood




PRZ> ‘proof’ by basically saying that





PRZ> IGP metric is comparable now only within each AS’s paths (MED), i.e.





PRZ> an ‘best-path’





PRZ> cannot change MEDs based on comparing IGP metrics of two different





PRZ> ASs (= there is now a ‘best-path’ per AS). This is normally the source of





PRZ> ‘MED loops’ I saw, i.e. a RR





PRZ> changes opinion and advertises different MEDs on the route because





PRZ> the IGP metric comparison between routes with 2 different MEDs





PRZ> triggers the ‘change of heart’.





 




   It is assumed that the following common practice is followed.  A




   route reflection cluster or a confederation sub-AS should be designed




   such that the IGP metrics for links within a cluster (or




   confederation sub-AS) are much smaller than the IGP metrics for the




   links between the clusters (or confederation sub-AS).  This practice




   helps achieve consistent routing within a route reflection cluster or




   a confederation sub-AS.




 




   Observe that in a network that maintains full IBGP mesh only the




   paths that survive the (Local_Pref, AS-PATH Length, Origin, MED)




   comparisons [RFC4271] would contribute to the route selection in the




   network.




 




 




 




 




Walton, et al.           Expires August 6, 2015                 [Page 7]




Àpar Internet-Draft          BGP Oscillation Solutions          February 2015




 




 




   Consider a route reflection cluster that sources one or more paths




   that would survive the (Local_Pref, AS-PATH Length, Origin, MED)




   comparisons among all the paths in the network.  One of these




   surviving paths would be selected as the Group Best Path by the route




   reflector in the cluster.  Due to the constrain on the IGP metrics as




   described previously, this path would remain as the Group Best Path




   and would be advertised to all other clusters even after a path is




   received from another cluster.




 




   On the other hand, when no path in a route reflection cluster would




   survive the (Local_Pref, AS-PATH Length, Origin, MED) comparisons




   among all the paths in the network, the Group Best Path (when exists)




   for a route reflector would be from another cluster.  Clearly the




   advertise of the Group Best Path by the route reflector to the




   clients only depends on the paths received from other clusters.




 




   Therefore there is no MED-induced route oscillation in the network as




   the advertisement of a Group Best Path to a peer does not depend on




   the paths received from that peer.




 




   The claim for the confederation can be validated similarly.




 




Authors' Addresses




 




   Daniel Walton




   Cumulus Networks




   140C S. Whisman Rd.




   Mountain View, CA  94041




   USA




 




   Email:


dwalton at cumulusnetworks.com




 




 




   Alvaro Retana




   Cisco Systems, Inc.




   7025 Kit Creek Rd.




   Research Triangle Park, NC  27709




   USA




 




   Email:


aretana at cisco.com




 




 




 




 




 




 




 




 




 




 




 




Walton, et al.           Expires August 6, 2015                 [Page 8]




Àpar Internet-Draft          BGP Oscillation Solutions          February 2015




 




 




   Enke Chen




   Cisco Systems, Inc.




   170 W. Tasman Dr.




   San Jose, CA  95134




   USA




 




   Email:


enkechen at cisco.com




 




 




   John Scudder




   Juniper Networks




   1194 N. Mathilda Ave




   Sunnyvale, CA  94089




   USA




 




   Email:


jgs at juniper.net




 




 




 




 




 




 




 




 




 




 




 




 




 




 




 




 




 




 




 




 




 




 




 




 




 




 




 




 




 




 




 




 




 




 




 




Walton, et al.           Expires August 6, 2015                 [Page 9]