draft-ietf-lsvr-bgp-spf-02.txt   draft-ietf-lsvr-bgp-spf-03.txt 
Network Working Group K. Patel Network Working Group K. Patel
Internet-Draft Arrcus, Inc. Internet-Draft Arrcus, Inc.
Intended status: Standards Track A. Lindem Intended status: Standards Track A. Lindem
Expires: February 7, 2019 Cisco Systems Expires: March 31, 2019 Cisco Systems
S. Zandi S. Zandi
Linkedin Linkedin
W. Henderickx W. Henderickx
Nokia Nokia
August 6, 2018 September 27, 2018
Shortest Path Routing Extensions for BGP Protocol Shortest Path Routing Extensions for BGP Protocol
draft-ietf-lsvr-bgp-spf-02.txt draft-ietf-lsvr-bgp-spf-03.txt
Abstract Abstract
Many Massively Scaled Data Centers (MSDCs) have converged on Many Massively Scaled Data Centers (MSDCs) have converged on
simplified layer 3 routing. Furthermore, requirements for simplified layer 3 routing. Furthermore, requirements for
operational simplicity have lead many of these MSDCs to converge on operational simplicity have lead many of these MSDCs to converge on
BGP as their single routing protocol for both their fabric routing BGP as their single routing protocol for both their fabric routing
and their Data Center Interconnect (DCI) routing. This document and their Data Center Interconnect (DCI) routing. This document
describes a solution which leverages BGP Link-State distribution and describes a solution which leverages BGP Link-State distribution and
the Shortest Path First (SPF) algorithm similar to Internal Gateway the Shortest Path First (SPF) algorithm similar to Internal Gateway
skipping to change at page 1, line 42 skipping to change at page 1, line 42
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 February 7, 2019. This Internet-Draft will expire on March 31, 2019.
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 2, line 34 skipping to change at page 2, line 34
it for publication as an RFC or to translate it into languages other it for publication as an RFC or to translate it into languages other
than English. than English.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. BGP Shortest Path First (SPF) Motivation . . . . . . . . 4 1.1. BGP Shortest Path First (SPF) Motivation . . . . . . . . 4
1.2. Requirements Language . . . . . . . . . . . . . . . . . . 5 1.2. Requirements Language . . . . . . . . . . . . . . . . . . 5
2. BGP Peering Models . . . . . . . . . . . . . . . . . . . . . 5 2. BGP Peering Models . . . . . . . . . . . . . . . . . . . . . 5
2.1. BGP Single-Hop Peering on Network Node Connections . . . 5 2.1. BGP Single-Hop Peering on Network Node Connections . . . 5
2.2. BGP Peering Between Directly Connected Network Nodes . . 5 2.2. BGP Peering Between Directly Connected Network Nodes . . 6
2.3. BGP Peering in Route-Reflector or Controller Topology . . 6 2.3. BGP Peering in Route-Reflector or Controller Topology . . 6
3. BGP-LS Shortest Path Routing (SPF) SAFI . . . . . . . . . . . 6 3. BGP-LS Shortest Path Routing (SPF) SAFI . . . . . . . . . . . 6
4. Extensions to BGP-LS . . . . . . . . . . . . . . . . . . . . 6 4. Extensions to BGP-LS . . . . . . . . . . . . . . . . . . . . 7
4.1. Node NLRI Usage and Modifications . . . . . . . . . . . . 7 4.1. Node NLRI Usage and Modifications . . . . . . . . . . . . 7
4.2. Link NLRI Usage . . . . . . . . . . . . . . . . . . . . . 7 4.2. Link NLRI Usage . . . . . . . . . . . . . . . . . . . . . 8
4.2.1. BGP-LS Link NLRI Attribute Prefix-Length TLVs . . . . 8 4.2.1. BGP-LS Link NLRI Attribute Prefix-Length TLVs . . . . 9
4.3. Prefix NLRI Usage . . . . . . . . . . . . . . . . . . . . 8 4.3. Prefix NLRI Usage . . . . . . . . . . . . . . . . . . . . 9
4.4. BGP-LS Attribute Sequence-Number TLV . . . . . . . . . . 8 4.4. BGP-LS Attribute Sequence-Number TLV . . . . . . . . . . 9
5. Decision Process with SPF Algorithm . . . . . . . . . . . . . 9 5. Decision Process with SPF Algorithm . . . . . . . . . . . . . 10
5.1. Phase-1 BGP NLRI Selection . . . . . . . . . . . . . . . 10 5.1. Phase-1 BGP NLRI Selection . . . . . . . . . . . . . . . 11
5.2. Dual Stack Support . . . . . . . . . . . . . . . . . . . 11 5.2. Dual Stack Support . . . . . . . . . . . . . . . . . . . 12
5.3. SPF Calculation based on BGP-LS NLRI . . . . . . . . . . 11 5.3. SPF Calculation based on BGP-LS NLRI . . . . . . . . . . 12
5.4. NEXT_HOP Manipulation . . . . . . . . . . . . . . . . . . 13 5.4. NEXT_HOP Manipulation . . . . . . . . . . . . . . . . . . 15
5.5. IPv4/IPv6 Unicast Address Family Interaction . . . . . . 14 5.5. IPv4/IPv6 Unicast Address Family Interaction . . . . . . 15
5.6. NLRI Advertisement and Convergence . . . . . . . . . . . 14 5.6. NLRI Advertisement and Convergence . . . . . . . . . . . 15
5.7. Error Handling . . . . . . . . . . . . . . . . . . . . . 14 5.7. Error Handling . . . . . . . . . . . . . . . . . . . . . 16
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
7. Security Considerations . . . . . . . . . . . . . . . . . . . 15 7. Security Considerations . . . . . . . . . . . . . . . . . . . 16
7.1. Acknowledgements . . . . . . . . . . . . . . . . . . . . 15 8. Management Considerations . . . . . . . . . . . . . . . . . . 16
7.2. Contributors . . . . . . . . . . . . . . . . . . . . . . 15 8.1. Configuration . . . . . . . . . . . . . . . . . . . . . . 16
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 8.2. Operational Data . . . . . . . . . . . . . . . . . . . . 16
8.1. Normative References . . . . . . . . . . . . . . . . . . 16 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17
8.2. Information References . . . . . . . . . . . . . . . . . 16 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 17
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 17
11.1. Normative References . . . . . . . . . . . . . . . . . . 17
11.2. Information References . . . . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20
1. Introduction 1. Introduction
Many Massively Scaled Data Centers (MSDCs) have converged on Many Massively Scaled Data Centers (MSDCs) have converged on
simplified layer 3 routing. Furthermore, requirements for simplified layer 3 routing. Furthermore, requirements for
operational simplicity have lead many of these MSDCs to converge on operational simplicity have lead many of these MSDCs to converge on
BGP [RFC4271] as their single routing protocol for both their fabric BGP [RFC4271] as their single routing protocol for both their fabric
routing and their Data Center Interconnect (DCI) routing. routing and their Data Center Interconnect (DCI) routing.
Requirements and procedures for using BGP are described in [RFC7938]. Requirements and procedures for using BGP are described in [RFC7938].
This document describes an alternative solution which leverages BGP- This document describes an alternative solution which leverages BGP-
skipping to change at page 5, line 46 skipping to change at page 5, line 49
2.1. BGP Single-Hop Peering on Network Node Connections 2.1. BGP Single-Hop Peering on Network Node Connections
The simplest peering model is the one described in section 5.2.1 of The simplest peering model is the one described in section 5.2.1 of
[RFC7938]. In this model, EBGP single-hop sessions are established [RFC7938]. In this model, EBGP single-hop sessions are established
over direct point-to-point links interconnecting the SPF domain over direct point-to-point links interconnecting the SPF domain
nodes. For the purposes of BGP SPF, Link NLRI is only advertised if nodes. For the purposes of BGP SPF, Link NLRI is only advertised if
a single-hop BGP session has been established and the Link-State/SPF a single-hop BGP session has been established and the Link-State/SPF
address family capability has been exchanged [RFC4790] on the address family capability has been exchanged [RFC4790] on the
corresponding session. If the session goes down, the corresponding corresponding session. If the session goes down, the corresponding
Link NLRI will be withdrawn. Link NLRI will be withdrawn. Topologically, this would be equivalent
to the peering model in [RFC7938] where there is a BGP session on
every link in the data center switch fabric.
2.2. BGP Peering Between Directly Connected Network Nodes 2.2. BGP Peering Between Directly Connected Network Nodes
In this model, BGP speakers peer with all directly connected network In this model, BGP speakers peer with all directly connected network
nodes but the sessions may be multi-hop and the direct connection nodes but the sessions may be multi-hop and the direct connection
discovery and liveliness detection for those connections are discovery and liveliness detection for those connections are
independent of the BGP protocol. How this is accomplished is outside independent of the BGP protocol. How this is accomplished is outside
the scope of this document. Consequently, there will be a single the scope of this document. Consequently, there will be a single
session even if there are multiple direct connections between BGP session even if there are multiple direct connections between BGP
speakers. For the purposes of BGP SPF, Link NLRI is advertised as speakers. For the purposes of BGP SPF, Link NLRI is advertised as
long as a BGP session has been established, the Link-State/SPF long as a BGP session has been established, the Link-State/SPF
address family capability has been exchanged [RFC4790] and the address family capability has been exchanged [RFC4790] and the
corresponding link is considered is up and considered operational. corresponding link is considered is up and considered operational.
This is much like the previous peering model only peering is on a
single loopback address and the switch fabric links can be
unnumbered. However, there will be the same unnumber of sessions as
with the previous peering model unless there are parrallel links
between switches in the fabric.
2.3. BGP Peering in Route-Reflector or Controller Topology 2.3. BGP Peering in Route-Reflector or Controller Topology
In this model, BGP speakers peer solely with one or more Route In this model, BGP speakers peer solely with one or more Route
Reflectors [RFC4456] or controllers. As in the previous model, Reflectors [RFC4456] or controllers. As in the previous model,
direct connection discovery and liveliness detection for those direct connection discovery and liveliness detection for those
connections are done outside the BGP protocol. More specifically, connections are done outside the BGP protocol. More specifically,
the Liveliness detection is done using BFD protocol described in the Liveliness detection is done using BFD protocol described in
[RFC5880]. For the purposes of BGP SPF, Link NLRI is advertised as [RFC5880]. For the purposes of BGP SPF, Link NLRI is advertised as
long as the corresponding link is up and considered operational. long as the corresponding link is up and considered operational.
This peering model, known as sparse peering, allows for many fewer
BGP sessions and, consequently, instances of the same NLRI received
from multiple peers. It is discussed in greater detail in
[I-D.ietf-lsvr-applicability].
3. BGP-LS Shortest Path Routing (SPF) SAFI 3. BGP-LS Shortest Path Routing (SPF) SAFI
In order to replace the Phase 1 and 2 decision functions of the In order to replace the Phase 1 and 2 decision functions of the
existing Decision Process with an SPF-based Decision Process and existing Decision Process with an SPF-based Decision Process and
streamline the Phase 3 decision functions in a backward compatible streamline the Phase 3 decision functions in a backward compatible
manner, this draft introduces the BGP-LS-SFP SAFI for BGP-LS SPF manner, this draft introduces the BGP-LS-SFP SAFI for BGP-LS SPF
operation. The BGP-LS-SPF (AF 16388 / SAFI TBD1) [RFC4790] is operation. The BGP-LS-SPF (AF 16388 / SAFI TBD1) [RFC4790] is
allocated by IANA as specified in the Section 6. A BGP speaker using allocated by IANA as specified in the Section 6. A BGP speaker using
the BGP-LS SPF extensions described herein MUST exchange the AFI/SAFI the BGP-LS SPF extensions described herein MUST exchange the AFI/SAFI
using Multiprotocol Extensions Capability Code [RFC4760] with other using Multiprotocol Extensions Capability Code [RFC4760] with other
skipping to change at page 10, line 24 skipping to change at page 11, line 20
When BGP-LS-SPF NLRI is received, all that is required is to When BGP-LS-SPF NLRI is received, all that is required is to
determine whether it is the best-path by examining the Node-ID and determine whether it is the best-path by examining the Node-ID and
sequence number as described in Section 5.1. If the received best- sequence number as described in Section 5.1. If the received best-
path NLRI had changed, it will be advertised to other BGP-LS-SPF path NLRI had changed, it will be advertised to other BGP-LS-SPF
peers. If the attributes have changed (other than the sequence peers. If the attributes have changed (other than the sequence
number), a BGP SPF calculation will be scheduled. However, a changed number), a BGP SPF calculation will be scheduled. However, a changed
NLRI MAY be advertised to other peers almost immediately and NLRI MAY be advertised to other peers almost immediately and
propagation of changes can approach IGP convergence times. To propagation of changes can approach IGP convergence times. To
accomplish this, the MinRouteAdvertisementIntervalTimer and accomplish this, the MinRouteAdvertisementIntervalTimer and
MinRouteAdvertisementIntervalTimer [RFC4271] are not applicable to MinASOriginationIntervalTimer [RFC4271] are not applicable to the
the BGP-LS-SPF SAFI. BGP-LS-SPF SAFI. Rather, SPF calculations SHOULD be triggered and
dampened consistent with the SPF backoff algorithm specified in
[RFC8405].
The Phase 3 decision function of the Decision Process [RFC4271] is The Phase 3 decision function of the Decision Process [RFC4271] is
also simplified since under normal SPF operation, a BGP speaker would also simplified since under normal SPF operation, a BGP speaker would
advertise the NLRI selected for the SPF to all BGP peers with the advertise the NLRI selected for the SPF to all BGP peers with the
BGP-LS/BGP-LS-SPF AFI/SAFI. Application of policy would not be BGP-LS/BGP-LS-SPF AFI/SAFI. Application of policy would not be
prevented however its usage to best-path process would be limited as prevented however its usage to best-path process would be limited as
the SPF relies solely on link metrics. the SPF relies solely on link metrics.
5.1. Phase-1 BGP NLRI Selection 5.1. Phase-1 BGP NLRI Selection
skipping to change at page 11, line 5 skipping to change at page 12, line 5
2. If the Sequence-Number TLV is present in the BGP-LS Attribute, 2. If the Sequence-Number TLV is present in the BGP-LS Attribute,
then the NLRI with the most recent, i.e., highest sequence number then the NLRI with the most recent, i.e., highest sequence number
is selected. BGP-LS NLRI with a Sequence-Number TLV will be is selected. BGP-LS NLRI with a Sequence-Number TLV will be
considered more recent than NLRI without a BGP-LS Attribute or a considered more recent than NLRI without a BGP-LS Attribute or a
BGP-LS Attribute that doesn't include the Sequence-Number TLV. BGP-LS Attribute that doesn't include the Sequence-Number TLV.
3. The final tie-breaker is the NLRI from the BGP Speaker with the 3. The final tie-breaker is the NLRI from the BGP Speaker with the
numerically largest BGP Router ID. numerically largest BGP Router ID.
When a BGP speaker completely loses its sequence number state, i.e.,
due to a cold start, or in the unlikely possibility that that
sequence number wraps, the BGP routing domain will still converge.
This is due to the fact that BGP speakers adjacent to the router will
always accept self-originated NLRI from the associated speaker as
more recent (rule # 1). When BGP speaker reestablishes a connection
with its peers, any existing session will be taken down and stale
NLRI will be replaced by the new NLRI and stale NLRI will be
discarded independent of whether or not BGP graceful restart is
deployed, [RFC4724]. The adjacent BGP speaker will update their NLRI
advertisements in turn until the BGP routing domain has converged.
The modified SPF Decision Process performs an SPF calculation rooted The modified SPF Decision Process performs an SPF calculation rooted
at the BGP speaker using the metrics from Link and Prefix NLRI at the BGP speaker using the metrics from Link and Prefix NLRI
Attribute TLVs [RFC7752]. As a result, any attributes that would Attribute TLVs [RFC7752]. As a result, any attributes that would
influence the Decision process defined in [RFC4271] like ORIGIN, influence the Decision process defined in [RFC4271] like ORIGIN,
MULTI_EXIT_DISC, and LOCAL_PREF attributes are ignored by the SPF MULTI_EXIT_DISC, and LOCAL_PREF attributes are ignored by the SPF
algorithm. Furthermore, the NEXT_HOP attribute value is preserved algorithm. Furthermore, the NEXT_HOP attribute value is preserved
but otherwise ignored during the SPF or best-path. but otherwise ignored during the SPF or best-path.
5.2. Dual Stack Support 5.2. Dual Stack Support
skipping to change at page 15, line 20 skipping to change at page 16, line 33
This document also defines four attribute TLVs for BGP LS NLRI. We This document also defines four attribute TLVs for BGP LS NLRI. We
request IANA to assign TLVs for the SPF capability, Sequence Number, request IANA to assign TLVs for the SPF capability, Sequence Number,
IPv4 Link Prefix-Length, and IPv6 Link Prefix-Length from the "BGP-LS IPv4 Link Prefix-Length, and IPv6 Link Prefix-Length from the "BGP-LS
Node Descriptor, Link Descriptor, Prefix Descriptor, and Attribute Node Descriptor, Link Descriptor, Prefix Descriptor, and Attribute
TLVs" Registry. TLVs" Registry.
7. Security Considerations 7. Security Considerations
This extension to BGP does not change the underlying security issues This extension to BGP does not change the underlying security issues
inherent in the existing [RFC4724] and [RFC4271]. inherent in the existing [RFC4271], [RFC4724], and [RFC7752].
7.1. Acknowledgements 8. Management Considerations
This section includes unique management considerations for the BGP-LS
SPF address family.
8.1. Configuration
In addition to configuration of the BGP-LS SPF address family,
implementations SHOULD support the configuratio of the
INITIAL_SPF_DELAY, SHORT_SPF_DELAY, LONG_SPF_DELAY, TIME_TO_LEARN,
and HOLDDOWN_INTERVAL as documented in [RFC8405].
8.2. Operational Data
In order to troubleshoot SPF issues, implementations SHOULD support
an SPF log including entries for previous SPF computations, Each SPF
log entry would include the BGP-LS NLRI SPF triggering the SPF, SPF
scheduled time, SPF start time, SPF end time, and SPF type if
different types of SPF are supported. Since the size of the log will
be finite, implementations SHOULD also maintain counters for the
total number of SPF computations of each type and the total number of
SPF triggering events. Additionally, to troubleshoot SPF scheduling
and backoff [RFC8405], the current SPF backoff state, remaining time-
to-learn, remaining holddown, last trigger event time, last SPF time,
and next SPF time should be available.
9. Acknowledgements
The authors would like to thank Sue Hares, Jorge Rabadan, Boris The authors would like to thank Sue Hares, Jorge Rabadan, Boris
Hassanov, and Fred Baker for their review and comments. Hassanov, Dan Frost, and Fred Baker for their review and comments.
7.2. Contributors 10. Contributors
In addition to the authors listed on the front page, the following In addition to the authors listed on the front page, the following
co-authors have contributed to the document. co-authors have contributed to the document.
Derek Yeung Derek Yeung
Arrcus, Inc. Arrcus, Inc.
derek@arrcus.com derek@arrcus.com
Gunter Van De Velde Gunter Van De Velde
Nokia Nokia
gunter.van_de_velde@nokia.com gunter.van_de_velde@nokia.com
Abhay Roy Abhay Roy
Cisco Systems Cisco Systems
akr@cisco.com akr@cisco.com
Venu Venugopal Venu Venugopal
Cisco Systems Cisco Systems
venuv@cisco.com venuv@cisco.com
8. References 11. References
8.1. Normative References
11.1. Normative References
[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-14 (work in progress), December 2017. epe-15 (work in progress), March 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 47 skipping to change at page 18, line 35
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>. May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L., [RFC8402] Filsfils, C., Ed., Previdi, S., Ed., Ginsberg, L.,
Decraene, B., Litkowski, S., and R. Shakir, "Segment Decraene, B., Litkowski, S., and R. Shakir, "Segment
Routing Architecture", RFC 8402, DOI 10.17487/RFC8402, Routing Architecture", RFC 8402, DOI 10.17487/RFC8402,
July 2018, <https://www.rfc-editor.org/info/rfc8402>. July 2018, <https://www.rfc-editor.org/info/rfc8402>.
8.2. Information References [RFC8405] Decraene, B., Litkowski, S., Gredler, H., Lindem, A.,
Francois, P., and C. Bowers, "Shortest Path First (SPF)
Back-Off Delay Algorithm for Link-State IGPs", RFC 8405,
DOI 10.17487/RFC8405, June 2018, <https://www.rfc-
editor.org/info/rfc8405>.
11.2. Information References
[I-D.ietf-lsvr-applicability]
Patel, K., Lindem, A., Zandi, S., and G. Dawra, "Usage and
Applicability of Link State Vector Routing in Data
Centers", draft-ietf-lsvr-applicability-00 (work in
progress), July 2018.
[RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328,
DOI 10.17487/RFC2328, April 1998, <https://www.rfc- DOI 10.17487/RFC2328, April 1998, <https://www.rfc-
editor.org/info/rfc2328>. editor.org/info/rfc2328>.
[RFC4456] Bates, T., Chen, E., and R. Chandra, "BGP Route [RFC4456] Bates, T., Chen, E., and R. Chandra, "BGP Route
Reflection: An Alternative to Full Mesh Internal BGP Reflection: An Alternative to Full Mesh Internal BGP
(IBGP)", RFC 4456, DOI 10.17487/RFC4456, April 2006, (IBGP)", RFC 4456, DOI 10.17487/RFC4456, April 2006,
<https://www.rfc-editor.org/info/rfc4456>. <https://www.rfc-editor.org/info/rfc4456>.
 End of changes. 19 change blocks. 
37 lines changed or deleted 105 lines changed or added

This html diff was produced by rfcdiff 1.47. The latest version is available from http://tools.ietf.org/tools/rfcdiff/