Hi Peter,
Thanks for thoroughly reviewing this document again and finding the nits. I incorporated all your comments other than adding "positive" as while it is more precise, it reads better without it and we don't want to imply that a TLV length could ever be negative. See attached diff.
Thanks,
Acee
On 6/13/18, 3:04 AM, "Peter Yee" <peter@xxxxxxxxxx> wrote:
Reviewer: Peter Yee
Review result: Ready with Nits
I am the assigned Gen-ART reviewer for this draft. The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair. Please treat these comments just
like any other last call comments.
For more information, please see the FAQ at
<https://trac.ietf.org/trac/gen/wiki/GenArtfaq>.
Document: draft-ietf-idr-bgp-prefix-sid-21
Reviewer: Peter Yee
Review Date: 2018-06-12
IETF LC End Date: 2018-06-12
IESG Telechat date: Not scheduled for a telechat
Summary: This document is ready for publication, although there are a few nits
that should be corrected prior to publication. I am not a routing expert, so I
cannot vouch for the correctness of this specification, but it otherwise
appears consistent and reflect s the many iterations it has undergone.
Major issues: None.
Minor issues: None
Nits/editorial comments:
General:
Expand uncommon acronyms on first use. (See:
https://www.rfc-editor.org/materials/abbrev.expansion.txt.). Acronyms need
expansion include: AS, ECMP, and EBGP.
Specific:
Page 3, 7th paragraph, last sentence: actually, this isn’t a complete sentence.
I’m not sure what you wanted to do with the fragment.
Page 5, 2nd full paragraph, last sentence: change “prefix-SID” to “BGP
Prefix-SID” to make usage in the remainder of the document.
Page 7, Section 3.2, 2nd bullet item: insert “positive” before “multiple”.
Page 9, last paragraph, 1st sentence: delete “to”.
Page 12, 1st paragraph after the (unlabeled) Value/Type/Reference table, last
sentence: insert “ Prefix” before “-SID”.
Page 12, 2nd paragraph after the (unlabeled) Value/Type/Reference table, last
sentence: insert “ Prefix” before “-SID”.
<
<https://tools.ietf.org/rfcdiff?url2=draft-ietf-idr-bgp-prefix-sid-21.txt> draft-ietf-idr-bgp-prefix-sid-21.txt
<https://tools.ietf.org/html/draft-ietf-idr-bgp-prefix-sid-21.txt>
draft-ietf-idr-bgp-prefix-sid-22.txt
<https://tools.ietf.org/html/draft-ietf-idr-bgp-prefix-sid-22.txt> >
<https://tools.ietf.org/rfcdiff?url1=draft-ietf-idr-bgp-prefix-sid-22.txt>
IDR S. Previdi, Ed. IDR S. Previdi, Ed.
Internet-Draft C. Filsfils Internet-Draft C. Filsfils
Intended status: Standards Track A. Lindem, Ed. Intended status: Standards Track A. Lindem, Ed.
Expires: November 30, 2018 Cisco Systems Expires: December 15, 2018 Cisco Systems
A. Sreekantiah A. Sreekantiah
H. Gredler H. Gredler
RtBrick Inc. RtBrick Inc.
May 29, 2018 June 13, 2018
Segment Routing Prefix SID extensions for BGP Segment Routing Prefix SID extensions for BGP
draft-ietf-idr-bgp-prefix-sid-21 draft-ietf-idr-bgp-prefix-sid-22
Abstract Abstract
The Segment Routing (SR) architecture allows a node to steer a packet The Segment Routing (SR) architecture allows a node to steer a packet
flow through any topological path and service chain by leveraging flow through any topological path and service chain by leveraging
source routing. The ingress node prepends an SR header to a packet source routing. The ingress node prepends an SR header to a packet
containing a set of segment identifiers (SID). Each SID represents a containing a set of segment identifiers (SID). Each SID represents a
topological or a service-based instruction. Per-flow state is topological or a service-based instruction. Per-flow state is
maintained only on the ingress node of the SR domain. An SR domain maintained only on the ingress node of the SR domain. An SR domain
is defined as a single administrative domain for global SID is defined as a single administrative domain for global SID
skipping to change at/page 2, line 10¶/ <#part-2> skipping to change
at/page 2, line 10¶/ <#part-2>
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on November 30, 2018. This Internet-Draft will expire on December 15, 2018.
Copyright Notice Copyright Notice
Copyright (c) 2018 IETF Trust and the persons identified as the Copyright (c) 2018 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at/page 3, line 15¶/ <#part-3> skipping to change
at/page 3, line 15¶/ <#part-3>
1. Introduction 1. Introduction
The Segment Routing (SR) architecture leverages the source routing The Segment Routing (SR) architecture leverages the source routing
paradigm. A group of inter-connected nodes that use SR forms an SR paradigm. A group of inter-connected nodes that use SR forms an SR
domain. A segment represents either a topological instruction such domain. A segment represents either a topological instruction such
as "go to prefix P following shortest path" or a service instruction. as "go to prefix P following shortest path" or a service instruction.
Other types of segments may be defined in the future. Other types of segments may be defined in the future.
A segment is identified through a Segment Identifier (SID). An SR A segment is identified through a Segment Identifier (SID). An SR
domain is defined as a single administrative domain for global SID domain is defined as a single administrative domain for global SID
assignment. It may be comprised of a single AS or multiple ASes assignment. It may be comprised of a single Autonomous System (AS)
under consolidated global SID administration. Typically, the ingress or multiple ASes under consolidated global SID administration.
node of the SR domain prepends an SR header containing segments Typically, the ingress node of the SR domain prepends an SR header
identifiers (SIDs) to an incoming packet. containing segments identifiers (SIDs) to an incoming packet.
As described in [I-D.ietf-spring-segment-routing], when SR is applied As described in [I-D.ietf-spring-segment-routing], when SR is applied
to the MPLS dataplane ([I-D.ietf-spring-segment-routing-mpls]), the to the MPLS dataplane ([I-D.ietf-spring-segment-routing-mpls]), the
SID consists of a label. SID consists of a label.
[I-D.ietf-spring-segment-routing] also describes how segment routing [I-D.ietf-spring-segment-routing] also describes how segment routing
can be applied to an IPv6 dataplane (SRv6) using an IPv6 routing can be applied to an IPv6 dataplane (SRv6) using an IPv6 routing
header containing a stack of SR SIDs encoded as IPv6 addresses header containing a stack of SR SIDs encoded as IPv6 addresses
[I-D.ietf-6man-segment-routing-header]. The applicability and [I-D.ietf-6man-segment-routing-header]. The applicability and
support for Segment Routing over IPv6 is beyond the scope of this support for Segment Routing over IPv6 is beyond the scope of this
document. document.
A BGP-Prefix Segment (and its BGP Prefix-SID) is a BGP segment A BGP-Prefix Segment (and its BGP Prefix-SID) is a BGP segment
attached to a BGP prefix. A BGP Prefix-SID is always a global SID attached to a BGP prefix. A BGP Prefix-SID is always a global SID
([I-D.ietf-spring-segment-routing]) within the SR/BGP domain (i.e., ([I-D.ietf-spring-segment-routing]) within the SR/BGP domain (i.e.,
the set of Autonomous Systems under a common administration and the set of Autonomous Systems under a common administration and
control and where SR is used) and identifies an instruction to control and where SR is used) and identifies an instruction to
forward the packet over the ECMP-aware best-path computed by BGP to forward the packet over the Equal-Cost Multi-Path (ECMP) best-path
the related prefix. The BGP Prefix-SID is the identifier of the BGP computed by BGP to the related prefix. The BGP Prefix-SID is the
prefix segment. In this document, we always refer to the BGP segment identifier of the BGP prefix segment. In this document, we always
by the BGP Prefix-SID. refer to the BGP segment by the BGP Prefix-SID.
This document describes the BGP extension to signal the BGP Prefix- This document describes the BGP extension to signal the BGP Prefix-
SID. Specifically, this document defines a BGP attribute known as SID. Specifically, this document defines a BGP attribute known as
the BGP Prefix-SID attribute and specifies the rules to originate, the BGP Prefix-SID attribute and specifies the rules to originate,
receive, and handle error conditions for the attribute. receive, and handle error conditions for the attribute.
The BGP Prefix-SID attribute defined in this document can be attached The BGP Prefix-SID attribute defined in this document can be attached
to prefixes from Multiprotocol BGP labeled IPv4/IPv6 Unicast to prefixes from Multiprotocol BGP labeled IPv4/IPv6 Unicast
([RFC4760], [RFC8277]). Address Family Identifier (AFI)/ Subsequent ([RFC4760], [RFC8277]). Usage of the BGP Prefix-SID attribute for
Address Family Identifier (SAFI) combinations. other Address Family Identifier (AFI)/ Subsequent Address Family
Identifier (SAFI) combinations is not defined herein but may be
Usage of the BGP Prefix-SID attribute for other AFI/SAFI combinations specified in future specifications.
is not defined herein but may be specified in future specifications.
[I-D.ietf-spring-segment-routing-msdc] describes example use cases [I-D.ietf-spring-segment-routing-msdc] describes example use cases
where the BGP Prefix-SID is used for the above AFI/SAFI combinations. where the BGP Prefix-SID is used for the above AFI/SAFI combinations.
It should be noted that: It should be noted that:
o A BGP Prefix-SID MAY be global between domains when the o A BGP Prefix-SID MAY be global between domains when the
interconnected domains agree on the SID allocation scheme. interconnected domains agree on the SID allocation scheme.
Alternatively, when interconnecting domains, the ASBRs of each Alternatively, when interconnecting domains, the ASBRs of each
domain will have to handle the advertisement of unique SIDs. The domain will have to handle the advertisement of unique SIDs. The
skipping to change at/page 5, line 19¶/ <#part-4> skipping to change
at/page 5, line 19¶/ <#part-4>
if traffic-engineering within the SR domain is required, each node if traffic-engineering within the SR domain is required, each node
may be required to advertise its local SRGB in addition to the may be required to advertise its local SRGB in addition to the
topological information. topological information.
This document assumes that BGP-LS is the preferred method for This document assumes that BGP-LS is the preferred method for
collecting both peer segments (Peer SIDs) and SRGB information collecting both peer segments (Peer SIDs) and SRGB information
through [RFC7752], [I-D.ietf-idr-bgpls-segment-routing-epe], and through [RFC7752], [I-D.ietf-idr-bgpls-segment-routing-epe], and
[I-D.ietf-idr-bgp-ls-segment-routing-ext]. However, as an [I-D.ietf-idr-bgp-ls-segment-routing-ext]. However, as an
optional alternative for the advertisement of the local SRGB optional alternative for the advertisement of the local SRGB
without the topology nor the peer SIDs, hence without without the topology nor the peer SIDs, hence without
applicability for TE, the Originator SRGB TLV of the prefix-SID applicability for TE, the Originator SRGB TLV of the BGP Prefix-
attribute is specified in Section 3.2 of this document. SID attribute is specified in Section 3.2 of this document.
As defined in [I-D.ietf-spring-segment-routing], the label index As defined in [I-D.ietf-spring-segment-routing], the label index
L_I is an offset into the SRGB. Each BGP speaker derives its L_I is an offset into the SRGB. Each BGP speaker derives its
local MPLS label, L, by adding L_I to the start value of its own local MPLS label, L, by adding L_I to the start value of its own
SRGB, and programs L in its MPLS dataplane as its incoming/local SRGB, and programs L in its MPLS dataplane as its incoming/local
label for the prefix. It should be noted that while SRGBs and label for the prefix. It should be noted that while SRGBs and
SIDs are advertised using 32-bit values, the derived label is SIDs are advertised using 32-bit values, the derived label is
advertised in the 20 right-most bits. See Section 4.1 for more advertised in the 20 right-most bits. See Section 4.1 for more
details. details.
skipping to change at/page 8, line 34¶/ <#part-5> skipping to change
at/page 8, line 34¶/ <#part-5>
The originator SRGB may only appear in a BGP Prefix-SID attribute The originator SRGB may only appear in a BGP Prefix-SID attribute
attached to Labeled IPv4/IPv6 unicast prefixes ([RFC8277]). It MUST attached to Labeled IPv4/IPv6 unicast prefixes ([RFC8277]). It MUST
be ignored when received for other BGP AFI/SAFI combinations. Since be ignored when received for other BGP AFI/SAFI combinations. Since
the Label-Index TLV is required for IPv4/IPv6 prefix applicability, the Label-Index TLV is required for IPv4/IPv6 prefix applicability,
the originator SRGB will be ignored if it is not specified consistent the originator SRGB will be ignored if it is not specified consistent
with Section 6. with Section 6.
4. Receiving BGP Prefix-SID Attribute 4. Receiving BGP Prefix-SID Attribute
A BGP speaker receiving a BGP Prefix-SID attribute from an EBGP A BGP speaker receiving a BGP Prefix-SID attribute from an External
neighbor residing outside the boundaries of the SR domain MUST BGP (EBGP) neighbor residing outside the boundaries of the SR domain
discard the attribute unless it is configured to accept the attribute MUST discard the attribute unless it is configured to accept the
from the EBGP neighbor. A BGP speaker SHOULD log an error for attribute from the EBGP neighbor. A BGP speaker SHOULD log an error
further analysis when discarding an attribute. for further analysis when discarding an attribute.
4.1. MPLS Dataplane: Labeled Unicast 4.1. MPLS Dataplane: Labeled Unicast
A BGP session supporting the Multiprotocol BGP labeled IPv4 or IPv6 A BGP session supporting the Multiprotocol BGP labeled IPv4 or IPv6
Unicast ([RFC8277]) AFI/SAFI is required. Unicast ([RFC8277]) AFI/SAFI is required.
The BGP Prefix-SID attribute MUST contain the Label-Index TLV and MAY The BGP Prefix-SID attribute MUST contain the Label-Index TLV and MAY
contain the Originator SRGB TLV. A BGP Prefix-SID attribute received contain the Originator SRGB TLV. A BGP Prefix-SID attribute received
without a Label-Index TLV MUST be considered as "invalid" by the without a Label-Index TLV MUST be considered as "invalid" by the
receiving speaker. receiving speaker.
skipping to change at/page 9, line 47¶/ <#part-6> skipping to change
at/page 9, line 47¶/ <#part-6>
When a BGP speaker receives a path from a neighbor with an "invalid" When a BGP speaker receives a path from a neighbor with an "invalid"
or "conflicting" BGP Prefix-SID attribute or when a BGP speaker or "conflicting" BGP Prefix-SID attribute or when a BGP speaker
receives a path from a neighbor with a BGP Prefix-SID attribute but receives a path from a neighbor with a BGP Prefix-SID attribute but
is unable to process it (e.g., local policy disables the is unable to process it (e.g., local policy disables the
functionality), it MUST ignore the BGP Prefix-SID attribute. For the functionality), it MUST ignore the BGP Prefix-SID attribute. For the
purposes of label allocation, a BGP speaker MUST assign a local (also purposes of label allocation, a BGP speaker MUST assign a local (also
called dynamic) label (non-SRGB) for such a prefix as per classic called dynamic) label (non-SRGB) for such a prefix as per classic
Multiprotocol BGP labeled IPv4/IPv6 Unicast ([RFC8277]) operation. Multiprotocol BGP labeled IPv4/IPv6 Unicast ([RFC8277]) operation.
In the case of an "invalid" BGP Prefix-SID attribute, a BGP speaker In the case of an "invalid" BGP Prefix-SID attribute, a BGP speaker
MUST follow to the error handling rules specified in Section 6. A MUST follow the error handling rules specified in Section 6. A BGP
BGP speaker SHOULD log an error for further analysis. In the case of speaker SHOULD log an error for further analysis. In the case of a
a "conflicting" BGP Prefix-SID attribute, a BGP speaker SHOULD NOT "conflicting" BGP Prefix-SID attribute, a BGP speaker SHOULD NOT
treat it as error and SHOULD propagate the attribute unchanged. A treat it as error and SHOULD propagate the attribute unchanged. A
BGP Speaker SHOULD log a warning for further analysis, i.e., in the BGP Speaker SHOULD log a warning for further analysis, i.e., in the
case the conflict is not due to a label index transition. case the conflict is not due to a label index transition.
When a BGP Prefix-SID attribute changes and transitions from When a BGP Prefix-SID attribute changes and transitions from
"conflicting" to "acceptable", the BGP Prefix-SID attributes for "conflicting" to "acceptable", the BGP Prefix-SID attributes for
other prefixes may also transition to "acceptable" as well. other prefixes may also transition to "acceptable" as well.
Implementations SHOULD assure all impacted prefixes revert to using Implementations SHOULD assure all impacted prefixes revert to using
the label indices corresponding to these newly "acceptable" BGP the label indices corresponding to these newly "acceptable" BGP
Prefix-SID attributes. Prefix-SID attributes.
skipping to change at/page 12, line 26¶/ <#part-7> skipping to change
at/page 12, line 26¶/ <#part-7>
1 Label-Index this document 1 Label-Index this document
2 Deprecated this document 2 Deprecated this document
3 Originator SRGB this document 3 Originator SRGB this document
4-254 Unassigned 4-254 Unassigned
255 Reserved this document 255 Reserved this document
This document also requests creation of the "BGP Prefix-SID Label- This document also requests creation of the "BGP Prefix-SID Label-
Index TLV Flags" registry under the "Border Gateway Protocol (BGP) Index TLV Flags" registry under the "Border Gateway Protocol (BGP)
Parameters" registry, Reference: draft-ietf-idr-bgp-prefix-sid. Parameters" registry, Reference: draft-ietf-idr-bgp-prefix-sid.
Initially, this 16 bit flags registry will be empty. Flag bits will Initially, this 16 bit flags registry will be empty. Flag bits will
be allocated First Come First Served (FCFS) consistent with the BGP- be allocated First Come First Served (FCFS) consistent with the BGP
SID TLV Types registry. Prefix-SID TLV Types registry.
Finally, this document requests creation of the "BGP Prefix-SID Finally, this document requests creation of the "BGP Prefix-SID
Originator SRGB TLV Flags" registry under the "Border Gateway Originator SRGB TLV Flags" registry under the "Border Gateway
Protocol (BGP) Parameters" registry, Reference: draft-ietf-idr-bgp- Protocol (BGP) Parameters" registry, Reference: draft-ietf-idr-bgp-
prefix-sid. Initially, this 16 bit flags registry will be empty. prefix-sid. Initially, this 16 bit flags registry will be empty.
Flag bits will be allocated First Come First Served (FCFS) consistent Flag bits will be allocated First Come First Served (FCFS) consistent
with the BGP-SID TLV Types registry. with the BGP Prefix-SID TLV Types registry.
8. Manageability Considerations 8. Manageability Considerations
This document defines a BGP attribute to address use cases such as This document defines a BGP attribute to address use cases such as
the one described in [I-D.ietf-spring-segment-routing-msdc]. It is the one described in [I-D.ietf-spring-segment-routing-msdc]. It is
assumed that advertisement of the BGP Prefix-SID attribute is assumed that advertisement of the BGP Prefix-SID attribute is
controlled by the operator in order to: controlled by the operator in order to:
o Prevent undesired origination/advertisement of the BGP Prefix-SID o Prevent undesired origination/advertisement of the BGP Prefix-SID
attribute. By default, a BGP Prefix-SID attribute SHOULD NOT be attribute. By default, a BGP Prefix-SID attribute SHOULD NOT be
skipping to change at/page 14, line 41¶/ <#part-8> skipping to change
at/page 14, line 41¶/ <#part-8>
[I-D.ietf-spring-segment-routing] [I-D.ietf-spring-segment-routing]
Filsfils, C., Previdi, S., Ginsberg, L., Decraene, B., Filsfils, C., Previdi, S., Ginsberg, L., Decraene, B.,
Litkowski, S., and R. Shakir, "Segment Routing Litkowski, S., and R. Shakir, "Segment Routing
Architecture", draft-ietf-spring-segment-routing-15 (work Architecture", draft-ietf-spring-segment-routing-15 (work
in progress), January 2018. in progress), January 2018.
[I-D.ietf-spring-segment-routing-mpls] [I-D.ietf-spring-segment-routing-mpls]
Bashandy, A., Filsfils, C., Previdi, S., Decraene, B., Bashandy, A., Filsfils, C., Previdi, S., Decraene, B.,
Litkowski, S., and R. Shakir, "Segment Routing with MPLS Litkowski, S., and R. Shakir, "Segment Routing with MPLS
data plane", draft-ietf-spring-segment-routing-mpls-13 data plane", draft-ietf-spring-segment-routing-mpls-14
(work in progress), April 2018. (work in progress), June 2018.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997, <https://www.rfc- DOI 10.17487/RFC2119, March 1997, <https://www.rfc-
editor.org/info/rfc2119>. editor.org/info/rfc2119>.
[RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A
Border Gateway Protocol 4 (BGP-4)", RFC 4271, Border Gateway Protocol 4 (BGP-4)", RFC 4271,
DOI 10.17487/RFC4271, January 2006, <https://www.rfc- DOI 10.17487/RFC4271, January 2006, <https://www.rfc-
editor.org/info/rfc4271>. editor.org/info/rfc4271>.
skipping to change at/page 16, line 12¶/ <#part-9> skipping to change
at/page 16, line 12¶/ <#part-9>
Routing", draft-ietf-idr-bgp-ls-segment-routing-ext-08 Routing", draft-ietf-idr-bgp-ls-segment-routing-ext-08
(work in progress), May 2018. (work in progress), May 2018.
[I-D.ietf-idr-bgpls-segment-routing-epe] [I-D.ietf-idr-bgpls-segment-routing-epe]
Previdi, S., Filsfils, C., Patel, K., Ray, S., and J. Previdi, S., Filsfils, C., Patel, K., Ray, S., and J.
Dong, "BGP-LS extensions for Segment Routing BGP Egress Dong, "BGP-LS extensions for Segment Routing BGP Egress
Peer Engineering", draft-ietf-idr-bgpls-segment-routing- Peer Engineering", draft-ietf-idr-bgpls-segment-routing-
epe-15 (work in progress), March 2018. epe-15 (work in progress), March 2018.
[I-D.ietf-spring-segment-routing-msdc] [I-D.ietf-spring-segment-routing-msdc]
Filsfils, C., Previdi, S., Mitchell, J., Aries, E., and P. Filsfils, C., Previdi, S., Dawra, G., Aries, E., and P.
Lapukhov, "BGP-Prefix Segment in large-scale data Lapukhov, "BGP-Prefix Segment in large-scale data
centers", draft-ietf-spring-segment-routing-msdc-08 (work centers", draft-ietf-spring-segment-routing-msdc-09 (work
in progress), December 2017. in progress), May 2018.
[RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., [RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y.,
Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack
Encoding", RFC 3032, DOI 10.17487/RFC3032, January 2001, Encoding", RFC 3032, DOI 10.17487/RFC3032, January 2001,
<https://www.rfc-editor.org/info/rfc3032>. <https://www.rfc-editor.org/info/rfc3032>.
[RFC5004] Chen, E. and S. Sangli, "Avoid BGP Best Path Transitions [RFC5004] Chen, E. and S. Sangli, "Avoid BGP Best Path Transitions
from One External to Another", RFC 5004, from One External to Another", RFC 5004,
DOI 10.17487/RFC5004, September 2007, <https://www.rfc- DOI 10.17487/RFC5004, September 2007, <https://www.rfc-
editor.org/info/rfc5004>. editor.org/info/rfc5004>.
End of changes. 15 change blocks.
/35 lines changed or deleted/ // /34 lines changed or added/
This html diff was produced by rfcdiff 1.46. The latest version is available from http://tools.ietf.org/tools/rfcdiff/ <http://www.tools.ietf.org/tools/rfcdiff/>
