--- 1/draft-psarkar-idr-bgp-ls-node-admin-tag-extension-04.txt 2016-11-14 05:13:15.001502500 -0800 +++ 2/draft-psarkar-idr-bgp-ls-node-admin-tag-extension-05.txt 2016-11-14 05:13:15.029503188 -0800 @@ -1,20 +1,21 @@ Inter-Domain Routing P. Sarkar, Ed. -Internet-Draft H. Gredler -Intended status: Standards Track Individual Contributor -Expires: November 14, 2016 S. Litkowski +Internet-Draft Individual Contributor +Intended status: Standards Track H. Gredler +Expires: May 18, 2017 RtBrick, Inc. + S. Litkowski Orange - May 13, 2016 + November 14, 2016 Advertising Node Admin Tags in BGP Link-State Advertisements - draft-psarkar-idr-bgp-ls-node-admin-tag-extension-04 + draft-psarkar-idr-bgp-ls-node-admin-tag-extension-05 Abstract This document describes the protocol extensions to collect node administrative tags adevertised in IGP Link State advertisements and disseminate the same in BGP Link-State advertisement protocol, to facilitate inter-AS TE applications that may need the same node administrative tags to associate a subset of network devices spanning across more than one AS with a specific functionality. @@ -32,90 +33,89 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - This Internet-Draft will expire on November 14, 2016. + This Internet-Draft will expire on May 18, 2017. Copyright Notice Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Per-Node Administrative Tag . . . . . . . . . . . . . . . . . 4 - 3. BGP-LS Extensions for Per-Node Administrative Tags . . . . . 4 + 3. BGP-LS Extensions for Per-Node Administrative Tags . . . . . 5 3.1. Node Admin Tag TLV . . . . . . . . . . . . . . . . . . . 5 4. Elements of Procedure . . . . . . . . . . . . . . . . . . . . 7 5. Applications . . . . . . . . . . . . . . . . . . . . . . . . 8 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 8 7. Manageability Considerations . . . . . . . . . . . . . . . . 9 7.1. Operational Considerations . . . . . . . . . . . . . . . 9 7.1.1. Operations . . . . . . . . . . . . . . . . . . . . . 9 8. TLV/Sub-TLV Code Points Summary . . . . . . . . . . . . . . . 9 9. Security Considerations . . . . . . . . . . . . . . . . . . . 9 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 9 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 9 11.1. Normative References . . . . . . . . . . . . . . . . . . 9 11.2. Informative References . . . . . . . . . . . . . . . . . 10 11.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 10 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 11 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10 1. Introduction Advertising Node Administrative Tags in Link State protocols like IS- - IS [I-D.ietf-isis-node-admin-tag] and OSPF - [I-D.ietf-ospf-node-admin-tag] allows adding an optional operational + IS [RFC7917] and OSPF [RFC7777] allows adding an optional operational capability, that allows tagging and grouping of the nodes in a IGP domain. This, among other applications, allows simple management and easy control over route and path selection, based on local configured policies. However node administrative tags advertised in IGP advertisements let network operators associate nodes within a single AS (if not a single area). This limits the use of such node administrative tags and applications that need to associate a subset of network devices spanning across multiple AS with a specific functionality cannot use them. To address the need for applications that require visibility into LSDB across IGP areas, or even across ASes, the BGP-LS address- family/sub-address-family have been defined that allows BGP to carry LSDB information. The BGP Network Layer Reachability Information (NLRI) encoding format for BGP-LS and a new BGP Path Attribute called - BGP-LS attribute are defined in [I-D.ietf-idr-ls-distribution]. The - identifying key of each LSDB object, namely a node, a link or a - prefix, is encoded in the NLRI and the properties of the object are - encoded in the BGP-LS attribute. Figure 1 describes a typical - deployment scenario. In each IGP area, one or more nodes are - configured with BGP-LS. These BGP speakers form an IBGP mesh by - connecting to one or more route-reflectors. This way, all BGP - speakers - specifically the route-reflectors - obtain LSDB - information from all IGP areas (and from other ASes from EBGP peers). - An external component connects to the route-reflector to obtain this - information (perhaps moderated by a policy regarding what information - is sent to the external component, and what information isn't). + BGP-LS attribute are defined in [RFC7752]. The identifying key of + each LSDB object, namely a node, a link or a prefix, is encoded in + the NLRI and the properties of the object are encoded in the BGP-LS + attribute. Figure 1 describes a typical deployment scenario. In + each IGP area, one or more nodes are configured with BGP-LS. These + BGP speakers form an IBGP mesh by connecting to one or more route- + reflectors. This way, all BGP speakers - specifically the route- + reflectors - obtain LSDB information from all IGP areas (and from + other ASes from EBGP peers). An external component connects to the + route-reflector to obtain this information (perhaps moderated by a + policy regarding what information is sent to the external component, + and what information isn't). +------------+ | Consumer | +------------+ ^ | v +-------------------+ | BGP Speaker | +-----------+ | (Route-Reflector) | | Consumer | @@ -131,22 +131,21 @@ +-----------+ +-----------+ +-----------+ ^ ^ ^ | | | IGP IGP IGP Figure 1: Link State info collection For the purpose of advertising node administrative tags within BGP Link-State advertisements, a new Node Attribute TLV to be carried in the corresponding BGP-LS Node NLRI is proposed. For more details on - the Node Attribute TLVs please refer to section 3.3.1 in - [I-D.ietf-idr-ls-distribution] + the Node Attribute TLVs please refer to section 3.3.1 in [RFC7752] 2. Per-Node Administrative Tag An administrative Tag is a 32-bit integer value that can be used to identify a group of nodes in the entire routing domain. The new sub- TLV specifies one or more administrative tag values. A BGP Link- State speaker that also participates in the IGP link state advertisements exchange may learn one or more node administrative tags advertised by another router in the same IGP domain. Such BGP- LS speaker shall encode the same set of node administrative tags in @@ -173,44 +172,42 @@ To be able to distinguish between the significance of a per-area(or level) administrative tag learnt in one area, from that advertised in another area, or another AS, any applications receiving such a BGP-LS advertisements MUST consider the scope associated with each node administrative tag with 'per-area (or per-level) along with the area(or level in IS-IS) associated with corresponding IGP link state advertisement and the AS number associated with the originating node. The area(or level) associated with corresponding IGP link state advertisement and the AS number associated with the originating node can be derived from appropriate node attributes (already defined in - BGP-LS [I-D.ietf-idr-ls-distribution]) attached with the - corresponding Node NLRI. + BGP-LS [RFC7752]) attached with the corresponding Node NLRI. 3. BGP-LS Extensions for Per-Node Administrative Tags The BGP-LS NLRI can be a node NLRI, a link NLRI or a prefix NLRI. The corresponding BGP-LS attribute is a node attribute, a link - attribute or a prefix attribute. BGP-LS - [I-D.ietf-idr-ls-distribution] defines the TLVs that map link-state - information to BGP-LS NLRI and BGP-LS attribute. This document adds - an new Node Attribute TLV called 'Node Admin Tag TLV' to encode node - administrative tags information. + attribute or a prefix attribute. BGP-LS [RFC7752] defines the TLVs + that map link-state information to BGP-LS NLRI and BGP-LS attribute. + This document adds an new Node Attribute TLV called 'Node Admin Tag + TLV' to encode node administrative tags information. - [I-D.ietf-isis-node-admin-tag] defines the 'Node Admin Tag' sub-TLV - in the Router Capability TLV (type 242) in IS-IS Link State PDUs to - encode node administrative tags. Similarly - [I-D.ietf-isis-node-admin-tag] defines the 'Node Administrative Tag' - TLV in OSPF Router Information LSAs to encode node administrative - tags in OSPF Link State update packets. The node administrative tags - TLVs learnt from the IGP link state advertisements of a specific node - will all be inserted in a new Node Admin Tag TLV and added to the - corresponding Node are mapped to the corresponding BGP-LS Node NLRI. - Node administrative tags from IGP advertisements are mapped to the - corresponding Node Admin Tag TLV in the following way. + [RFC7917] defines the 'Node Admin Tag' sub-TLV in the Router + Capability TLV (type 242) in IS-IS Link State PDUs to encode node + administrative tags. Similarly [RFC7917] defines the 'Node + Administrative Tag' TLV in OSPF Router Information LSAs to encode + node administrative tags in OSPF Link State update packets. The node + administrative tags TLVs learnt from the IGP link state + advertisements of a specific node will all be inserted in a new Node + Admin Tag TLV and added to the corresponding Node are mapped to the + corresponding BGP-LS Node NLRI. Node administrative tags from IGP + advertisements are mapped to the corresponding Node Admin Tag TLV in + the following way. +----------+---------------+----------+---------------+-------------+ | TLV Code | Description | Length | IS-IS TLV | OSPF | | Point | | | /sub-TLV | LSA/TLV | +----------+---------------+----------+---------------+-------------+ | TBD | Node Admin | Variable | 242/TBD [1] | RI-LSA/TBD | | | Tag TLV | | | [2] | +----------+---------------+----------+---------------+-------------+ Table 1: Node Admin Tag TLV Mapping from IGP @@ -317,28 +314,28 @@ carried by the Node Admin Tag TLV SHOULD be used to indicate a independent characteristics of the node in IGP domain that originated it. The TLV SHOULD be considered as an unordered list. Whilst policies may be implemented based on the presence of multiple tags (e.g., if tag A AND tag B are present), they MUST NOT be reliant upon the order of the tags (i.e., all policies should be considered commutative operations, such that tag A preceding or following tag B does not change their outcome). For more details on guidance on usage of node administrative tags - please refer to section 4 [3] in [I-D.ietf-isis-node-admin-tag]. + please refer to section 4 [3] in [RFC7917]. 5. Applications - [I-D.ietf-isis-node-admin-tag] and [I-D.ietf-ospf-node-admin-tag] - present some applications of node administrative tags. + [RFC7917] and [RFC7777] present some applications of node + administrative tags. - The policy-based Explicit routing use case can be extended to inter- + The Policy-based Explicit routing use case can be extended to inter- area or inter-AS scenarios where an end to end path needs to avoid or include nodes that have particular properties. Following are some examples. 1. Geopolitical routing : preventing traffic from country A to country B to cross country C. In this case, we may use node administrative tags to encode geographical information (country). Path computation will be required to take into account node administrative tag to permit avoidance of nodes belonging to country C. @@ -348,22 +345,21 @@ in the network. For example, legacy nodes may not be carrier class (no high availability), and service provider wants to ensure that critical traffic only uses nodes that are providing high availability. In case of inter-AS Traffic-Engineering applications, different ASes SHOULD share their administrative tag policies. They MAY also need to agree upon some common tagging policy for specific applications. For more details on some possible applications with node - administrative tags please refer to section 5 [4] in - [I-D.ietf-isis-node-admin-tag]. + administrative tags please refer to section 3 [4] in [RFC7777]. 6. IANA Considerations This document requests assigning code-points from the registry for BGP-LS attribute TLVs based on table Table 2. 7. Manageability Considerations This section is structured as recommended in [RFC5706]. @@ -389,92 +385,84 @@ 9. 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. 10. Acknowledgements - TBD. + TBA. 11. References 11.1. Normative References - [I-D.ietf-idr-ls-distribution] - Gredler, H., Medved, J., Previdi, S., Farrel, A., and S. - Ray, "North-Bound Distribution of Link-State and TE - Information using BGP", draft-ietf-idr-ls-distribution-13 - (work in progress), October 2015. - [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [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, . -11.2. Informative References - - [I-D.ietf-isis-node-admin-tag] - Sarkar, P., Gredler, H., Hegde, S., Litkowski, S., - Decraene, B., Li, Z., Aries, E., Rodriguez, R., and H. - Raghuveer, "Advertising Per-node Admin Tags in IS-IS", - draft-ietf-isis-node-admin-tag-00 (work in progress), - December 2014. + [RFC7752] Gredler, H., Ed., Medved, J., Previdi, S., Farrel, A., and + S. Ray, "North-Bound Distribution of Link-State and + Traffic Engineering (TE) Information Using BGP", RFC 7752, + DOI 10.17487/RFC7752, March 2016, + . - [I-D.ietf-ospf-node-admin-tag] - Hegde, S., Raghuveer, H., Gredler, H., Shakir, R., - Smirnov, A., Li, Z., and B. Decraene, "Advertising per- - node administrative tags in OSPF", draft-ietf-ospf-node- - admin-tag-00 (work in progress), October 2014. +11.2. Informative References [RFC4272] Murphy, S., "BGP Security Vulnerabilities Analysis", RFC 4272, DOI 10.17487/RFC4272, January 2006, . [RFC5706] Harrington, D., "Guidelines for Considering Operations and Management of New Protocols and Protocol Extensions", RFC 5706, DOI 10.17487/RFC5706, November 2009, . [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, . + [RFC7777] Hegde, S., Shakir, R., Smirnov, A., Li, Z., and B. + Decraene, "Advertising Node Administrative Tags in OSPF", + RFC 7777, DOI 10.17487/RFC7777, March 2016, + . + + [RFC7917] Sarkar, P., Ed., Gredler, H., Hegde, S., Litkowski, S., + and B. Decraene, "Advertising Node Administrative Tags in + IS-IS", RFC 7917, DOI 10.17487/RFC7917, July 2016, + . + 11.3. URIs - [1] http://tools.ietf.org/html/draft-ietf-isis-node-admin-tag- - 00#section-3.1 + [1] http://tools.ietf.org/html/rfc7917#section-3.1 - [2] http://tools.ietf.org/html/draft-ietf-ospf-node-admin-tag- - 00#section-4.1 + [2] http://tools.ietf.org/html/rfc7777#section-2.1 - [3] http://tools.ietf.org/html/draft-ietf-isis-node-admin-tag- - 00#section-4 + [3] http://tools.ietf.org/html/rfc7917#section-4 - [4] http://tools.ietf.org/html/draft-ietf-isis-node-admin-tag- - 00#section-5 + [4] http://tools.ietf.org/html/rfc7777#section-3 Authors' Addresses - Pushpasis Sarkar (editor) Individual Contributor Email: pushpasis.ietf@gmail.com Hannes Gredler - Individual Contributor + RtBrick, Inc. - Email: hannes@gredler.at + Email: hannes@rtbrick.com Stephane Litkowski Orange Email: stephane.litkowski@orange.com