Tech-invite3GPPspaceIETFspace
959493929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 7752

North-Bound Distribution of Link-State and Traffic Engineering (TE) Information Using BGP

Pages: 48
Obsoleted by:  9552
Updated by:  9029
Part 3 of 3 – Pages 38 to 48
First   Prev   None

Top   ToC   RFC7752 - Page 38   prevText

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.
Top   ToC   RFC7752 - Page 39
   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?
Top   ToC   RFC7752 - Page 40

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.
Top   ToC   RFC7752 - Page 41

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 | | |
Top   ToC   RFC7752 - Page 42
   |    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 Points

8. 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
Top   ToC   RFC7752 - Page 43
   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>.
Top   ToC   RFC7752 - Page 44
   [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>.
Top   ToC   RFC7752 - Page 45
   [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>.
Top   ToC   RFC7752 - Page 46
   [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>.
Top   ToC   RFC7752 - Page 47
   [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.
Top   ToC   RFC7752 - Page 48

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