RFC 7752
North-Bound Distribution of Link-State and Traffic Engineering (TE) Information Using BGP
6. Manageability Considerations
This section is structured as recommended in [RFC5706].6.1. Operational Considerations
6.1.1. Operations
Existing BGP operational procedures apply. No new operation procedures are defined in this document. It is noted that the NLRI information present in this document carries purely application-level data that has no immediate corresponding forwarding state impact. As such, any churn in reachability information has a different impact than regular BGP updates, which need to change the forwarding state for an entire router. Furthermore, it is anticipated that distribution of this NLRI will be handled by dedicated route reflectors providing a level of isolation and fault containment between different NLRI types.6.1.2. Installation and Initial Setup
Configuration parameters defined in Section 6.2.3 SHOULD be initialized to the following default values: o The Link-State NLRI capability is turned off for all neighbors. o The maximum rate at which Link-State NLRIs will be advertised/ withdrawn from neighbors is set to 200 updates per second.6.1.3. Migration Path
The proposed extension is only activated between BGP peers after capability negotiation. Moreover, the extensions can be turned on/ off on an individual peer basis (see Section 6.2.3), so the extension can be gradually rolled out in the network.6.1.4. Requirements on Other Protocols and Functional Components
The protocol extension defined in this document does not put new requirements on other protocols or functional components.6.1.5. Impact on Network Operation
Frequency of Link-State NLRI updates could interfere with regular BGP prefix distribution. A network operator MAY use a dedicated Route- Reflector infrastructure to distribute Link-State NLRIs.
Distribution of Link-State NLRIs SHOULD be limited to a single admin domain, which can consist of multiple areas within an AS or multiple ASes.6.1.6. Verifying Correct Operation
Existing BGP procedures apply. In addition, an implementation SHOULD allow an operator to: o List neighbors with whom the speaker is exchanging Link-State NLRIs.6.2. Management Considerations
6.2.1. Management Information
The IDR working group has documented and continues to document parts of the Management Information Base and YANG models for managing and monitoring BGP speakers and the sessions between them. It is currently believed that the BGP session running BGP-LS is not substantially different from any other BGP session and can be managed using the same data models.6.2.2. Fault Management
If an implementation of BGP-LS detects a malformed attribute, then it MUST use the 'Attribute Discard' action as per [RFC7606], Section 2. An implementation of BGP-LS MUST perform the following syntactic checks for determining if a message is malformed. o Does the sum of all TLVs found in the BGP-LS attribute correspond to the BGP-LS path attribute length? o Does the sum of all TLVs found in the BGP MP_REACH_NLRI attribute correspond to the BGP MP_REACH_NLRI length? o Does the sum of all TLVs found in the BGP MP_UNREACH_NLRI attribute correspond to the BGP MP_UNREACH_NLRI length? o Does the sum of all TLVs found in a Node, Link or Prefix Descriptor NLRI attribute correspond to the Total NLRI Length field of the Node, Link, or Prefix Descriptors? o Does any fixed-length TLV correspond to the TLV Length field in this document?
6.2.3. Configuration Management
An implementation SHOULD allow the operator to specify neighbors to which Link-State NLRIs will be advertised and from which Link-State NLRIs will be accepted. An implementation SHOULD allow the operator to specify the maximum rate at which Link-State NLRIs will be advertised/withdrawn from neighbors. An implementation SHOULD allow the operator to specify the maximum number of Link-State NLRIs stored in a router's Routing Information Base (RIB). An implementation SHOULD allow the operator to create abstracted topologies that are advertised to neighbors and create different abstractions for different neighbors. An implementation SHOULD allow the operator to configure a 64-bit Instance-ID. An implementation SHOULD allow the operator to configure a pair of ASN and BGP-LS identifiers (Section 3.2.1.4) per flooding set in which the node participates.6.2.4. Accounting Management
Not Applicable.6.2.5. Performance Management
An implementation SHOULD provide the following statistics: o Total number of Link-State NLRI updates sent/received o Number of Link-State NLRI updates sent/received, per neighbor o Number of errored received Link-State NLRI updates, per neighbor o Total number of locally originated Link-State NLRIs These statistics should be recorded as absolute counts since system or session start time. An implementation MAY also enhance this information by recording peak per-second counts in each case.
6.2.6. Security Management
An operator SHOULD define an import policy to limit inbound updates as follows: o Drop all updates from consumer peers. An implementation MUST have the means to limit inbound updates.7. TLV/Sub-TLV Code Points Summary
This section contains the global table of all TLVs/sub-TLVs defined in this document. +-----------+---------------------+--------------+------------------+ | TLV Code | Description | IS-IS TLV/ | Reference | | Point | | Sub-TLV | (RFC/Section) | +-----------+---------------------+--------------+------------------+ | 256 | Local Node | --- | Section 3.2.1.2 | | | Descriptors | | | | 257 | Remote Node | --- | Section 3.2.1.3 | | | Descriptors | | | | 258 | Link Local/Remote | 22/4 | [RFC5307]/1.1 | | | Identifiers | | | | 259 | IPv4 interface | 22/6 | [RFC5305]/3.2 | | | address | | | | 260 | IPv4 neighbor | 22/8 | [RFC5305]/3.3 | | | address | | | | 261 | IPv6 interface | 22/12 | [RFC6119]/4.2 | | | address | | | | 262 | IPv6 neighbor | 22/13 | [RFC6119]/4.3 | | | address | | | | 263 | Multi-Topology ID | --- | Section 3.2.1.5 | | 264 | OSPF Route Type | --- | Section 3.2.3 | | 265 | IP Reachability | --- | Section 3.2.3 | | | Information | | | | 512 | Autonomous System | --- | Section 3.2.1.4 | | 513 | BGP-LS Identifier | --- | Section 3.2.1.4 | | 514 | OSPF Area-ID | --- | Section 3.2.1.4 | | 515 | IGP Router-ID | --- | Section 3.2.1.4 | | 1024 | Node Flag Bits | --- | Section 3.3.1.1 | | 1025 | Opaque Node | --- | Section 3.3.1.5 | | | Attribute | | | | 1026 | Node Name | variable | Section 3.3.1.3 | | 1027 | IS-IS Area | variable | Section 3.3.1.2 | | | Identifier | | | | 1028 | IPv4 Router-ID of | 134/--- | [RFC5305]/4.3 | | | Local Node | | |
| 1029 | IPv6 Router-ID of | 140/--- | [RFC6119]/4.1 | | | Local Node | | | | 1030 | IPv4 Router-ID of | 134/--- | [RFC5305]/4.3 | | | Remote Node | | | | 1031 | IPv6 Router-ID of | 140/--- | [RFC6119]/4.1 | | | Remote Node | | | | 1088 | Administrative | 22/3 | [RFC5305]/3.1 | | | group (color) | | | | 1089 | Maximum link | 22/9 | [RFC5305]/3.4 | | | bandwidth | | | | 1090 | Max. reservable | 22/10 | [RFC5305]/3.5 | | | link bandwidth | | | | 1091 | Unreserved | 22/11 | [RFC5305]/3.6 | | | bandwidth | | | | 1092 | TE Default Metric | 22/18 | Section 3.3.2.3 | | 1093 | Link Protection | 22/20 | [RFC5307]/1.2 | | | Type | | | | 1094 | MPLS Protocol Mask | --- | Section 3.3.2.2 | | 1095 | IGP Metric | --- | Section 3.3.2.4 | | 1096 | Shared Risk Link | --- | Section 3.3.2.5 | | | Group | | | | 1097 | Opaque Link | --- | Section 3.3.2.6 | | | Attribute | | | | 1098 | Link Name | --- | Section 3.3.2.7 | | 1152 | IGP Flags | --- | Section 3.3.3.1 | | 1153 | IGP Route Tag | --- | [RFC5130] | | 1154 | IGP Extended Route | --- | [RFC5130] | | | Tag | | | | 1155 | Prefix Metric | --- | [RFC5305] | | 1156 | OSPF Forwarding | --- | [RFC2328] | | | Address | | | | 1157 | Opaque Prefix | --- | Section 3.3.3.6 | | | Attribute | | | +-----------+---------------------+--------------+------------------+ Table 13: Summary Table of TLV/Sub-TLV Code Points8. Security Considerations
Procedures and protocol extensions defined in this document do not affect the BGP security model. See the Security Considerations section of [RFC4271] for a discussion of BGP security. Also refer to [RFC4272] and [RFC6952] for analysis of security issues for BGP. In the context of the BGP peerings associated with this document, a BGP speaker MUST NOT accept updates from a consumer peer. That is, a participating BGP speaker should be aware of the nature of its relationships for link-state relationships and should protect itself
from peers sending updates that either represent erroneous information feedback loops or are false input. Such protection can be achieved by manual configuration of consumer peers at the BGP speaker. An operator SHOULD employ a mechanism to protect a BGP speaker against DDoS attacks from consumers. The principal attack a consumer may apply is to attempt to start multiple sessions either sequentially or simultaneously. Protection can be applied by imposing rate limits. Additionally, it may be considered that the export of link-state and TE information as described in this document constitutes a risk to confidentiality of mission-critical or commercially sensitive information about the network. BGP peerings are not automatic and require configuration; thus, it is the responsibility of the network operator to ensure that only trusted consumers are configured to receive such information.9. References
9.1. Normative References
[ISO10589] International Organization for Standardization, "Intermediate System to Intermediate System intra-domain routeing information exchange protocol for use in conjunction with the protocol for providing the connectionless-mode network service (ISO 8473)", ISO/ IEC 10589, November 2002. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>. [RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, DOI 10.17487/RFC2328, April 1998, <http://www.rfc-editor.org/info/rfc2328>. [RFC2545] Marques, P. and F. Dupont, "Use of BGP-4 Multiprotocol Extensions for IPv6 Inter-Domain Routing", RFC 2545, DOI 10.17487/RFC2545, March 1999, <http://www.rfc-editor.org/info/rfc2545>. [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP Tunnels", RFC 3209, DOI 10.17487/RFC3209, December 2001, <http://www.rfc-editor.org/info/rfc3209>.
[RFC4202] Kompella, K., Ed. and Y. Rekhter, Ed., "Routing Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)", RFC 4202, DOI 10.17487/RFC4202, October 2005, <http://www.rfc-editor.org/info/rfc4202>. [RFC4203] Kompella, K., Ed. and Y. Rekhter, Ed., "OSPF Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)", RFC 4203, DOI 10.17487/RFC4203, October 2005, <http://www.rfc-editor.org/info/rfc4203>. [RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, DOI 10.17487/RFC4271, January 2006, <http://www.rfc-editor.org/info/rfc4271>. [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, "Multiprotocol Extensions for BGP-4", RFC 4760, DOI 10.17487/RFC4760, January 2007, <http://www.rfc-editor.org/info/rfc4760>. [RFC4915] Psenak, P., Mirtorabi, S., Roy, A., Nguyen, L., and P. Pillay-Esnault, "Multi-Topology (MT) Routing in OSPF", RFC 4915, DOI 10.17487/RFC4915, June 2007, <http://www.rfc-editor.org/info/rfc4915>. [RFC5036] Andersson, L., Ed., Minei, I., Ed., and B. Thomas, Ed., "LDP Specification", RFC 5036, DOI 10.17487/RFC5036, October 2007, <http://www.rfc-editor.org/info/rfc5036>. [RFC5120] Przygienda, T., Shen, N., and N. Sheth, "M-ISIS: Multi Topology (MT) Routing in Intermediate System to Intermediate Systems (IS-ISs)", RFC 5120, DOI 10.17487/RFC5120, February 2008, <http://www.rfc-editor.org/info/rfc5120>. [RFC5130] Previdi, S., Shand, M., Ed., and C. Martin, "A Policy Control Mechanism in IS-IS Using Administrative Tags", RFC 5130, DOI 10.17487/RFC5130, February 2008, <http://www.rfc-editor.org/info/rfc5130>. [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, DOI 10.17487/RFC5226, May 2008, <http://www.rfc-editor.org/info/rfc5226>. [RFC5301] McPherson, D. and N. Shen, "Dynamic Hostname Exchange Mechanism for IS-IS", RFC 5301, DOI 10.17487/RFC5301, October 2008, <http://www.rfc-editor.org/info/rfc5301>.
[RFC5305] Li, T. and H. Smit, "IS-IS Extensions for Traffic Engineering", RFC 5305, DOI 10.17487/RFC5305, October 2008, <http://www.rfc-editor.org/info/rfc5305>. [RFC5307] Kompella, K., Ed. and Y. Rekhter, Ed., "IS-IS Extensions in Support of Generalized Multi-Protocol Label Switching (GMPLS)", RFC 5307, DOI 10.17487/RFC5307, October 2008, <http://www.rfc-editor.org/info/rfc5307>. [RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF for IPv6", RFC 5340, DOI 10.17487/RFC5340, July 2008, <http://www.rfc-editor.org/info/rfc5340>. [RFC5890] Klensin, J., "Internationalized Domain Names for Applications (IDNA): Definitions and Document Framework", RFC 5890, DOI 10.17487/RFC5890, August 2010, <http://www.rfc-editor.org/info/rfc5890>. [RFC6119] Harrison, J., Berger, J., and M. Bartlett, "IPv6 Traffic Engineering in IS-IS", RFC 6119, DOI 10.17487/RFC6119, February 2011, <http://www.rfc-editor.org/info/rfc6119>. [RFC6549] Lindem, A., Roy, A., and S. Mirtorabi, "OSPFv2 Multi- Instance Extensions", RFC 6549, DOI 10.17487/RFC6549, March 2012, <http://www.rfc-editor.org/info/rfc6549>. [RFC6822] Previdi, S., Ed., Ginsberg, L., Shand, M., Roy, A., and D. Ward, "IS-IS Multi-Instance", RFC 6822, DOI 10.17487/RFC6822, December 2012, <http://www.rfc-editor.org/info/rfc6822>. [RFC7606] Chen, E., Ed., Scudder, J., Ed., Mohapatra, P., and K. Patel, "Revised Error Handling for BGP UPDATE Messages", RFC 7606, DOI 10.17487/RFC7606, August 2015, <http://www.rfc-editor.org/info/rfc7606>.9.2. Informative References
[RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G., and E. Lear, "Address Allocation for Private Internets", BCP 5, RFC 1918, DOI 10.17487/RFC1918, February 1996, <http://www.rfc-editor.org/info/rfc1918>. [RFC4272] Murphy, S., "BGP Security Vulnerabilities Analysis", RFC 4272, DOI 10.17487/RFC4272, January 2006, <http://www.rfc-editor.org/info/rfc4272>.
[RFC4364] Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February 2006, <http://www.rfc-editor.org/info/rfc4364>. [RFC4655] Farrel, A., Vasseur, JP., and J. Ash, "A Path Computation Element (PCE)-Based Architecture", RFC 4655, DOI 10.17487/RFC4655, August 2006, <http://www.rfc-editor.org/info/rfc4655>. [RFC5073] Vasseur, JP., Ed. and JL. Le Roux, Ed., "IGP Routing Protocol Extensions for Discovery of Traffic Engineering Node Capabilities", RFC 5073, DOI 10.17487/RFC5073, December 2007, <http://www.rfc-editor.org/info/rfc5073>. [RFC5152] Vasseur, JP., Ed., Ayyangar, A., Ed., and R. Zhang, "A Per-Domain Path Computation Method for Establishing Inter- Domain Traffic Engineering (TE) Label Switched Paths (LSPs)", RFC 5152, DOI 10.17487/RFC5152, February 2008, <http://www.rfc-editor.org/info/rfc5152>. [RFC5316] Chen, M., Zhang, R., and X. Duan, "ISIS Extensions in Support of Inter-Autonomous System (AS) MPLS and GMPLS Traffic Engineering", RFC 5316, DOI 10.17487/RFC5316, December 2008, <http://www.rfc-editor.org/info/rfc5316>. [RFC5392] Chen, M., Zhang, R., and X. Duan, "OSPF Extensions in Support of Inter-Autonomous System (AS) MPLS and GMPLS Traffic Engineering", RFC 5392, DOI 10.17487/RFC5392, January 2009, <http://www.rfc-editor.org/info/rfc5392>. [RFC5693] Seedorf, J. and E. Burger, "Application-Layer Traffic Optimization (ALTO) Problem Statement", RFC 5693, DOI 10.17487/RFC5693, October 2009, <http://www.rfc-editor.org/info/rfc5693>. [RFC5706] Harrington, D., "Guidelines for Considering Operations and Management of New Protocols and Protocol Extensions", RFC 5706, DOI 10.17487/RFC5706, November 2009, <http://www.rfc-editor.org/info/rfc5706>. [RFC6952] Jethanandani, M., Patel, K., and L. Zheng, "Analysis of BGP, LDP, PCEP, and MSDP Issues According to the Keying and Authentication for Routing Protocols (KARP) Design Guide", RFC 6952, DOI 10.17487/RFC6952, May 2013, <http://www.rfc-editor.org/info/rfc6952>.
[RFC7285] Alimi, R., Ed., Penno, R., Ed., Yang, Y., Ed., Kiesel, S., Previdi, S., Roome, W., Shalunov, S., and R. Woundy, "Application-Layer Traffic Optimization (ALTO) Protocol", RFC 7285, DOI 10.17487/RFC7285, September 2014, <http://www.rfc-editor.org/info/rfc7285>. [RFC7770] Lindem, A., Ed., Shen, N., Vasseur, JP., Aggarwal, R., and S. Shaffer, "Extensions to OSPF for Advertising Optional Router Capabilities", RFC 7770, DOI 10.17487/RFC7770, February 2016, <http://www.rfc-editor.org/info/rfc7770>.Acknowledgements
We would like to thank Nischal Sheth, Alia Atlas, David Ward, Derek Yeung, Murtuza Lightwala, John Scudder, Kaliraj Vairavakkalai, Les Ginsberg, Liem Nguyen, Manish Bhardwaj, Matt Miller, Mike Shand, Peter Psenak, Rex Fernando, Richard Woundy, Steven Luong, Tamas Mondal, Waqas Alam, Vipin Kumar, Naiming Shen, Carlos Pignataro, Balaji Rajagopalan, Yakov Rekhter, Alvaro Retana, Barry Leiba, and Ben Campbell for their comments.Contributors
We would like to thank Robert Varga for the significant contribution he gave to this document.
Authors' Addresses
Hannes Gredler (editor) Individual Contributor Email: hannes@gredler.at Jan Medved Cisco Systems, Inc. 170 West Tasman Drive San Jose, CA 95134 United States Email: jmedved@cisco.com Stefano Previdi Cisco Systems, Inc. Via Del Serafico, 200 Rome 00142 Italy Email: sprevidi@cisco.com Adrian Farrel Juniper Networks, Inc. Email: adrian@olddog.co.uk Saikat Ray Email: raysaikat@gmail.com