Jeffrey Haas et seq jhaasjunipernet addpath current status The base BGP addpath feature is well deployed and interoperable at this point AlcatelLucent Cisco Juniper and probably others ID: 141337
Download Presentation The PPT/PDF document "Advancing add-path" is the property of its rightful owner. Permission is granted to download and print the materials on this web site for personal, non-commercial use only, and to display it on your personal computer provided you do not modify the materials and that you retain all copyright notices contained in the materials. By downloading content from our website, you accept the terms of this agreement.
Slide1
Advancing add-path
Jeffrey Haas, et seq.
jhaas@juniper.netSlide2
add-path current status
The base BGP add-path feature is well deployed and interoperable at this point:
Alcatel-Lucent
Cisco
Juniper
(and probably others…)Slide3
add-path concerns
During the development of the add-path feature, there were a number of concerns about how the feature would behave from a route-selection standpoint.
Those issues are much better understood these days. Many are documented in draft-
ietf
-
idr
-add-paths-guidelines.Slide4
eBGP and add-path
draft-
pmohapat
-
idr
-fast-conn-restore is currently a NORMATIVE reference in the base add-path document.
The
Edge_Discriminator
Path Attribute documented in that I-D is required for BGP to perform consistent path selection for
eBGP
routes distributed in Add-Path.
There are no implementations of this feature?Slide5
Advancing add-path
Operators are clearly seeing benefit from the add-path feature, even without the
Edge_Discriminator
feature.
Introducing that feature has the usual incremental BGP deployment pain points.
Should the feature be removed as a normative reference so the add-path feature can advance and get published as an RFC?Slide6
Discussion