draft-ietf-lsvr-applicability-03.txt   draft-ietf-lsvr-applicability-04.txt 
skipping to change at page 1, line 13 skipping to change at page 1, line 13
LSVR K. Patel LSVR K. Patel
Internet-Draft Arrcus, Inc. Internet-Draft Arrcus, Inc.
Intended status: Informational A. Lindem Intended status: Informational A. Lindem
Expires: May 5, 2020 Cisco Systems Expires: May 5, 2020 Cisco Systems
S. Zandi S. Zandi
G. Dawra G. Dawra
Linkedin Linkedin
November 2, 2019 November 2, 2019
Usage and Applicability of Link State Vector Routing in Data Centers Usage and Applicability of Link State Vector Routing in Data Centers
draft-ietf-lsvr-applicability-03 draft-ietf-lsvr-applicability-04
Abstract Abstract
This document discusses the usage and applicability of Link State This document discusses the usage and applicability of Link State
Vector Routing (LSVR) extensions in data center networks utilizing Vector Routing (LSVR) extensions in data center networks utilizing
CLOS or Fat-Tree topologies. The document is intended to provide a CLOS or Fat-Tree topologies. The document is intended to provide a
simplified guide for the deployment of LSVR extensions. simplified guide for the deployment of LSVR extensions.
Status of This Memo Status of This Memo
skipping to change at page 2, line 26 skipping to change at page 2, line 26
6.1. Usage of BGP-LS SPF SAFI . . . . . . . . . . . . . . . . 5 6.1. Usage of BGP-LS SPF SAFI . . . . . . . . . . . . . . . . 5
6.1.1. Relationship to Other BGP AFI/SAFI Tuples . . . . . . 6 6.1.1. Relationship to Other BGP AFI/SAFI Tuples . . . . . . 6
6.2. Peering Models . . . . . . . . . . . . . . . . . . . . . 6 6.2. Peering Models . . . . . . . . . . . . . . . . . . . . . 6
6.2.1. Sparse Peering Model . . . . . . . . . . . . . . . . 6 6.2.1. Sparse Peering Model . . . . . . . . . . . . . . . . 6
6.2.2. Bi-Connected Graph Heuristic . . . . . . . . . . . . 7 6.2.2. Bi-Connected Graph Heuristic . . . . . . . . . . . . 7
6.3. BGP Spine/Leaf Topology Policy . . . . . . . . . . . . . 7 6.3. BGP Spine/Leaf Topology Policy . . . . . . . . . . . . . 7
6.4. BGP Peer Discovery Requirements . . . . . . . . . . . . . 8 6.4. BGP Peer Discovery Requirements . . . . . . . . . . . . . 8
6.5. BGP Peer Discovery . . . . . . . . . . . . . . . . . . . 9 6.5. BGP Peer Discovery . . . . . . . . . . . . . . . . . . . 9
6.5.1. BGP Peer Discovery Alternatives . . . . . . . . . . . 9 6.5.1. BGP Peer Discovery Alternatives . . . . . . . . . . . 9
6.5.2. Data Center Interconnect (DCI) Applicability . . . . 9 6.5.2. Data Center Interconnect (DCI) Applicability . . . . 9
6.6. Non-Transit Node Capability . . . . . . . . . . . . . . . 10 7. Non-CLOS/FAT Tree Topology Applicability . . . . . . . . . . 10
6.7. Non-CLOS/FAT Tree Topology Applicability . . . . . . . . 10 8. Non-Transit Node Capability . . . . . . . . . . . . . . . . . 10
7. BGP Policy Applicability . . . . . . . . . . . . . . . . . . 10 9. BGP Policy Applicability . . . . . . . . . . . . . . . . . . 10
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
9. Security Considerations . . . . . . . . . . . . . . . . . . . 11 11. Security Considerations . . . . . . . . . . . . . . . . . . . 11
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11 12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 11
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 11 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 11
11.1. Normative References . . . . . . . . . . . . . . . . . . 11 13.1. Normative References . . . . . . . . . . . . . . . . . . 11
11.2. Informative References . . . . . . . . . . . . . . . . . 11 13.2. Informative References . . . . . . . . . . . . . . . . . 11
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 13
1. Introduction 1. Introduction
This document complements [I-D.ietf-lsvr-bgp-spf] by discussing the This document complements [I-D.ietf-lsvr-bgp-spf] by discussing the
applicability of the technology in a simple and fairly common applicability of the technology in a simple and fairly common
deployment scenario, which is described in Section 4. deployment scenario, which is described in Section 4.
After describing the deployment scenario, Section 5 will describe the After describing the deployment scenario, Section 5 will describe the
reasons for BGP modifications for such deployments. reasons for BGP modifications for such deployments.
skipping to change at page 10, line 5 skipping to change at page 10, line 5
The BGP discovery mechanisms under consideration are The BGP discovery mechanisms under consideration are
[I-D.acee-idr-lldp-peer-discovery], [I-D.acee-idr-lldp-peer-discovery],
[I-D.xu-idr-neighbor-autodiscovery], and [I-D.ietf-lsvr-l3dl]. [I-D.xu-idr-neighbor-autodiscovery], and [I-D.ietf-lsvr-l3dl].
6.5.2. Data Center Interconnect (DCI) Applicability 6.5.2. Data Center Interconnect (DCI) Applicability
Since BGP SPF is to be used for the routing underlay and DCI gateway Since BGP SPF is to be used for the routing underlay and DCI gateway
boxes typically have direct or very simple connectivity, BGP external boxes typically have direct or very simple connectivity, BGP external
sessions would typically not include the BGP SPF SAFI. sessions would typically not include the BGP SPF SAFI.
6.6. Non-Transit Node Capability 7. Non-CLOS/FAT Tree Topology Applicability
The BGP SPF extensions [I-D.ietf-lsvr-bgp-spf] can be used in other
topologies and avail the inherent convergence improvements.
Additionally, sparse peering techniques may be utilized Section 6.2.
However, determining whether or to establish a BGP session is more
complex and the heuristic described in Section 6.2.2 cannot be used.
In such topologies, other techniques such as those described in
[I-D.ietf-lsr-dynamic-flooding] may be employed. One potential
deployment would be the underlay for a Service Provider (SP) backbone
where usage of a single protocol, i.e., BGP, is desired.
8. Non-Transit Node Capability
In certain scenarios, a BGP node wishes to participate in the BGP SPF In certain scenarios, a BGP node wishes to participate in the BGP SPF
topology but never be used for transit traffic. These in include topology but never be used for transit traffic. These in include
situations where a server wants to make application services situations where a server wants to make application services
available to clients homed at subnets throughout the BGP SPF domain available to clients homed at subnets throughout the BGP SPF domain
but doesn't ever want to be used as a router (i.e., carry transit but doesn't ever want to be used as a router (i.e., carry transit
traffic). Another specific instance is where a controller is traffic). Another specific instance is where a controller is
resident on a server and direct connectivity to the controller is resident on a server and direct connectivity to the controller is
required throughout the entire domain. This can readily be required throughout the entire domain. This can readily be
accomplished using the BGP-LS Node NLRI Attribute SPF Status TLV as accomplished using the BGP-LS Node NLRI Attribute SPF Status TLV as
described in [I-D.ietf-lsvr-bgp-spf]. described in [I-D.ietf-lsvr-bgp-spf].
6.7. Non-CLOS/FAT Tree Topology Applicability 9. BGP Policy Applicability
The BGP SPF extensions [I-D.ietf-lsvr-bgp-spf] can be used in other
topologies and avail the inherent convergence improvements.
Additionally, sparse peering techniques may be utilized Section 6.2.
However, determining whether or to establish a BGP session is more
complex and the heuristic described in Section 6.2.2 cannot be used.
In such topologies, other techniques such as those described in
[I-D.ietf-lsr-dynamic-flooding] may be employed. One potential
deployment would be the underlay for a Service Provider (SP) backbone
where usage of a single protocol, i.e., BGP, is desired.
7. BGP Policy Applicability
Existing BGP policy including aggregation and prefix filtering may be Existing BGP policy including aggregation and prefix filtering may be
used in conjunction with the BGP-LS SPF SAFI. When aggregation used in conjunction with the BGP-LS SPF SAFI. When aggregation
policy is used, BGP-LS SPF prefix NLRI will be originated for the policy is used, BGP-LS SPF prefix NLRI will be originated for the
aggregate prefix and BGP-LS SPF prefix NLRI for components will be aggregate prefix and BGP-LS SPF prefix NLRI for components will be
filtered. Additionally, link and node NLRI may be filtered and the filtered. Additionally, link and node NLRI may be filtered and the
abstracted by the prefix NLRI. abstracted by the prefix NLRI.
When BGP policy is used with the BGP-LS SPF SAFI, BGP speakers in the When BGP policy is used with the BGP-LS SPF SAFI, BGP speakers in the
BGP-LS SPF routing domain will not all have the same set of NLRI and BGP-LS SPF routing domain will not all have the same set of NLRI and
will compute a different BGP local routing table. Consequently, care will compute a different BGP local routing table. Consequently, care
must be taken to assure routing is consistent and blackholes or must be taken to assure routing is consistent and blackholes or
routing loops do not ensue. However, this is no different than if routing loops do not ensue. However, this is no different than if
tradition BGP routing using the IPv4 and IPv6 address families were tradition BGP routing using the IPv4 and IPv6 address families were
used. used.
8. IANA Considerations 10. IANA Considerations
No IANA updates are requested by this document. No IANA updates are requested by this document.
9. Security Considerations 11. Security Considerations
This document introduces no new security considerations above and This document introduces no new security considerations above and
beyond those already specified in the [RFC4271] and beyond those already specified in the [RFC4271] and
[I-D.ietf-lsvr-bgp-spf]. [I-D.ietf-lsvr-bgp-spf].
10. Acknowledgements 12. Acknowledgements
The authors would like to thank Alvaro Retana and Yan Filyurin for The authors would like to thank Alvaro Retana and Yan Filyurin for
the review and comments. the review and comments.
11. References 13. References
11.1. Normative References 13.1. Normative References
[I-D.ietf-lsvr-bgp-spf] [I-D.ietf-lsvr-bgp-spf]
Patel, K., Lindem, A., Zandi, S., and W. Henderickx, Patel, K., Lindem, A., Zandi, S., and W. Henderickx,
"Shortest Path Routing Extensions for BGP Protocol", "Shortest Path Routing Extensions for BGP Protocol",
draft-ietf-lsvr-bgp-spf-06 (work in progress), September draft-ietf-lsvr-bgp-spf-06 (work in progress), September
2019. 2019.
[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, DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>. <https://www.rfc-editor.org/info/rfc2119>.
[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>.
11.2. Informative References 13.2. Informative References
[CLOS] "A Study of Non-Blocking Switching Networks", The Bell [CLOS] "A Study of Non-Blocking Switching Networks", The Bell
System Technical Journal, Vol. 32(2), DOI System Technical Journal, Vol. 32(2), DOI
10.1002/j.1538-7305.1953.tb01433.x, March 1953. 10.1002/j.1538-7305.1953.tb01433.x, March 1953.
[I-D.acee-idr-lldp-peer-discovery] [I-D.acee-idr-lldp-peer-discovery]
Lindem, A., Patel, K., Zandi, S., Haas, J., and X. Xu, Lindem, A., Patel, K., Zandi, S., Haas, J., and X. Xu,
"BGP Logical Link Discovery Protocol (LLDP) Peer "BGP Logical Link Discovery Protocol (LLDP) Peer
Discovery", draft-acee-idr-lldp-peer-discovery-05 (work in Discovery", draft-acee-idr-lldp-peer-discovery-05 (work in
progress), July 2019. progress), July 2019.
 End of changes. 10 change blocks. 
30 lines changed or deleted 30 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/