<?xml version="1.0"encoding="US-ASCII"?> <!-- edited with XMLSPY v5 rel. 3 U (http://www.xmlspy.com) by Daniel M Kohn (private) -->encoding="UTF-8"?> <!DOCTYPE rfc SYSTEM"rfc2629.dtd" [ <!ENTITY rfc2119 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml"> ]>"rfc2629-xhtml.ent"> <rfccategory="std"xmlns:xi="http://www.w3.org/2001/XInclude" docName="draft-ietf-idr-eag-distribution-19"ipr="trust200902"> <?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?> <?rfc toc="yes" ?> <?rfc symrefs="yes" ?> <?rfc sortrefs="yes"?> <?rfc iprnotified="no" ?> <?rfc strict="yes" ?>number="9104" ipr="trust200902" obsoletes="" updates="" submissionType="IETF" category="std" consensus="true" xml:lang="en" tocInclude="true" symRefs="true" sortRefs="true" version="3"> <!-- xml2rfc v2v3 conversion 3.8.0 --> <front> <title abbrev="Extended AdministrativeGroup">DistributionGroups">Distribution of Traffic Engineering Extended Administrative Groupsusing BGP-LS</title>Using the Border Gateway Protocol - Link State (BGP-LS)</title> <seriesInfo name="RFC" value="9104"/> <author fullname="Jeff Tantsura"initials="J.T."initials="J." surname="Tantsura"><organization>Juniper Networks</organization><organization>Microsoft</organization> <address> <email>jefftant.ietf@gmail.com</email> </address> </author> <author fullname="Zitao Wang" initials="Z." surname="Wang"> <organization>Huawei</organization> <address> <postal> <extaddr>Yuhua District</extaddr> <street>101 SoftwareAvenue, Yuhua District</street>Avenue</street> <city>Nanjing</city> <region>Jiangsu</region> <code>210012</code> <country>China</country> </postal> <email>wangzitao@huawei.com</email> </address> </author> <author fullname="Qin Wu" initials="Q." surname="Wu"> <organization>Huawei</organization> <address> <postal> <extaddr>Yuhua District</extaddr> <street>101 SoftwareAvenue, Yuhua District</street>Avenue</street> <city>Nanjing</city> <region>Jiangsu</region> <code>210012</code> <country>China</country> </postal> <email>bill.wu@huawei.com</email> </address> </author> <author fullname="Ketan Talaulikar" initials="K." surname="Talaulikar"> <organization>Cisco Systems</organization> <address> <email>ketant@cisco.com</email> </address> </author> <dateyear=""/>year="2021" month="August"/> <area>Routing Area</area> <workgroup>IDR Working Group</workgroup><keyword>RFC</keyword> <keyword>Request for Comments</keyword> <keyword>I-D</keyword> <keyword>Internet-Draft</keyword><keyword>Inter-Domain Routing</keyword> <abstract> <t>Administrative groups are link attributes used for traffic engineering. This document defines an extension toBGP-LSthe Border Gateway Protocol - Link State (BGP-LS) for advertisement of extended administrative groups (EAGs).</t> </abstract> </front> <middle> <section anchor="intro"title="Introduction">numbered="true" toc="default"> <name>Introduction</name> <t>Administrative groups (commonly referred to as "colors" or "link colors") are link attributes that are advertised bylink statelink-state protocols like IS-IS <xreftarget="RFC1195"/>,target="RFC1195" format="default"/>, OSPFv2 <xreftarget="RFC2328"/>target="RFC2328" format="default"/>, and OSPFv3 <xreftarget="RFC5340"/>.target="RFC5340" format="default"/>. TheBGP-LSBorder Gateway Protocol - Link State (BGP-LS) advertisement of the originally defined (non-extended) administrative groups is encoded using the Administrative Group (color) TLV 1088 as defined in <xreftarget="RFC7752"/>.</t>target="RFC7752" format="default"/>.</t> <t>These administrative groups are defined as a fixed-length 32-bit bitmask. As networks grew and moreuse-casesuse cases were introduced, the 32-bit length was found to beconstrainingconstraining, and hence extended administrative groups(EAG)(EAGs) were introduced in <xreftarget="RFC7308"/>.</t>target="RFC7308" format="default"/>.</t> <t>The EAG TLV(Section 2)(<xref target="advert"/>) is not a replacement for the Administrative Group (color) TLV; as explained in <xreftarget="RFC7308"/>target="RFC7308" format="default"/>, both values can coexist. It is out of scope for this document to specify the behavior of the BGP-LS consumer <xreftarget="RFC7752"/>.target="RFC7752" format="default"/>. </t> <t>This document specifies an extension to BGP-LS for advertisement of the extended administrative groups.</t> <sectiontitle="Requirements Language">numbered="true" toc="default"> <name>Requirements Language</name> <t>The key words"MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY","<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>", "<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>", "<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>", "<bcp14>MAY</bcp14>", and"OPTIONAL""<bcp14>OPTIONAL</bcp14>" in this document are to be interpreted as described inBCP 14BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/> when, and only when, they appear in all capitals, as shown here.</t> </section> </section> <sectiontitle="Advertisinganchor="advert" numbered="true" toc="default"> <name>Advertising Extended AdministrativeGroupGroups inBGP-LS">BGP-LS</name> <t>This document defines an extension that enables BGP-LS speakers to signal the EAG of links in a network to a BGP-LS consumer of network topology such as a centralized controller. The centralized controller can leverage this information in traffic engineering computations and otheruse-cases.use cases. When a BGP-LS speaker is originating the topologylearntlearned via link-state routing protocols like OSPF or IS-IS, the EAG information of the links is sourced from the underlying extensions as defined in <xreftarget="RFC7308"/>.</t>target="RFC7308" format="default"/>.</t> <t>The EAG of a link is encoded in a new Link Attribute TLV <xreftarget="RFC7752"/>target="RFC7752" format="default"/> using the following format:</t> <figureanchor="link-attribute_tlv" title="Extendedanchor="link-attribute_tlv"> <name>Extended Administrative Group TLVFormat"> <artwork><![CDATA[Format</name> <artwork name="" type="ascii-art" align="left" alt=""><![CDATA[ 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Extended Administrative Group (variable) // +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ]]></artwork> </figure><t>Where:<list style="symbols"> <t>Type: 1173</t> <t>Length: variable<t>Where:</t> <dl spacing="normal"> <dt>Type:</dt><dd>1173</dd> <dt>Length:</dt><dd>variable lengthwhichthat represents the total length of the value field in octets. The length valueMUST<bcp14>MUST</bcp14> be a multiple of 4. If the length is not a multiple of 4, the TLVMUST<bcp14>MUST</bcp14> be consideredmalformed.</t> <t>Value: onemalformed.</dd> <dt>Value:</dt><dd>one or more sets of 32-bit bitmasks that indicate the administrative groups (colors) that are enabled on the link when those specific bits areset.</t> </list> </t>set.</dd> </dl> </section> <section anchor="iana-consider"title="IANA Considerations"> <t>This document requests assigningnumbered="true" toc="default"> <name>IANA Considerations</name> <t>IANA has assigned acode-pointcode point from theregistry"BGP-LS Node Descriptor, Link Descriptor, Prefix Descriptor, and Attribute TLVs"based on table below. Early allocation for these code-points have been done by IANA.</t> <figure> <artwork align="center"><![CDATA[ +------------+-------------------------------+-------------------+ | Code Point | Description | IS-IS TLV/Sub-TLV | +------------+-------------------------------+-------------------+ | 1173 | Extendedregistry as described in the following table.</t> <table anchor="tab-1"> <name></name> <thead> <tr> <th>Code Point</th> <th>Description</th> <th>IS-IS TLV/Sub-TLV</th> </tr> </thead> <tbody> <tr> <td>1173</td> <td>Extended AdministrativeGroup | 22/14 | +------------+-------------------------------+-------------------+ ]]></artwork> </figure>Group</td> <td>22/14</td> </tr> </tbody> </table> </section> <section anchor="Manageability"title="Manageability Considerations">numbered="true" toc="default"> <name>Manageability Considerations</name> <t>The new protocol extensions introduced in this document augment the existing IGP topology information that is distributed via <xreftarget="RFC7752"/>.target="RFC7752" format="default"/>. Procedures and protocol extensions defined in this document do not affect the BGP protocol operations and management other than as discussed inthe Manageability Considerations sectionSection <xref target="RFC7752" section="6" sectionFormat="bare">"Manageability Considerations"</xref> of <xref target="RFC7752"/>. Specifically, themalformed attributetests for malformed attributes, to perform syntactic checks as described inthe Fault Management sectionSection <xref target="RFC7752" section="6.2.2" sectionFormat="bare">"Fault Management"</xref> of <xreftarget="RFC7752"/>target="RFC7752"/>, now encompass the new BGP-LS Attribute TLV defined in this document. The semantic or content checking for the TLV specified in this document and its association with the BGP-LSNLRINetwork Layer Reachability Information (NLRI) types or its BGP-LS Attributeisare left to the consumer of the BGP-LS information(e.g.(e.g., an application or a controller) and nottheto BGPprotocol.</t>itself.</t> <t>A consumer of the BGP-LS information retrieves this information over a BGP-LS session (referSection 1to Sections <xref target="RFC7752" section="1" sectionFormat="bare"/> and2<xref target="RFC7752" section="2" sectionFormat="bare"/> of <xref target="RFC7752"/>).</t> </section> <sectiontitle="Security Considerations">numbered="true" toc="default"> <name>Security Considerations</name> <t>The procedures and protocol extensions defined in this document do not affect the BGP security model. See the "Security Considerations" section of <xreftarget="RFC4271"/>target="RFC4271" format="default"/> for a discussion of BGP security. This document only introduces a new AttributeTLVTLV, and any syntactic error in it would result in the BGP-LS Attribute being discarded <xreftarget="RFC7752"/>.target="RFC7752" format="default"/>. Also, refer to <xreftarget="RFC4272"/>target="RFC4272" format="default"/> and <xreftarget="RFC6952"/>target="RFC6952" format="default"/> for analyses of security issues for BGP. Security considerations for acquiring and distributing BGP-LS information are discussed in <xreftarget="RFC7752"/>.target="RFC7752" format="default"/>. The TLV introduced in this document is used to propagate the EAG extensions defined in <xreftarget="RFC7308"/>.target="RFC7308" format="default"/>. It is assumed that the IGP instances originating this TLV will support any required security mechanisms for OSPF and IS-IS, in order to prevent any security issues when propagating the Sub-TLVs into BGP-LS.</t> <t>Security concerns for OSPF are addressed in <xreftarget="RFC7474"/>,target="RFC7474" format="default"/>, <xreftarget="RFC4552"/>target="RFC4552" format="default"/>, and <xreftarget="RFC7166"/>.target="RFC7166" format="default"/>. Further security analysis for the OSPF protocol is done in <xreftarget="RFC6863"/>.</t>target="RFC6863" format="default"/>.</t> <t>Security considerations for IS-IS are specified by <xreftarget="RFC5304"/>.</t>target="RFC5304" format="default"/>.</t> <t>The advertisement of the link attribute information defined in this document presents no significant additional risk beyond that associated with the existing link attribute information already supported in <xreftarget="RFC7752"/>.</t>target="RFC7752" format="default"/>.</t> </section> </middle> <back> <references> <name>References</name> <references> <name>Normative References</name> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2119.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7308.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7752.xml"/> </references> <references> <name>Informative References</name> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.1195.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.2328.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5340.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4271.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4272.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6952.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.4552.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7166.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.6863.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7474.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.5304.xml"/> </references> </references> <sectiontitle="Acknowledgments">numbered="false" toc="default"> <name>Acknowledgments</name> <t>The authors would like to thankEric Osborne, Les Ginsberg, Tim Chown, Ben Niven-Jenkins<contact fullname="Eric Osborne"/>, <contact fullname="Les Ginsberg"/>, <contact fullname="Tim Chown"/>, <contact fullname="Ben Niven-Jenkins"/>, andAlvaro Retana<contact fullname="Alvaro Retana"/> for their reviews and valuable comments.</t> </section></middle> <back> <references title="Normative References"> <?rfc include="reference.RFC.2119"?> <?rfc include="reference.RFC.8174"?> <?rfc include="reference.RFC.7308"?> <?rfc include="reference.RFC.7752"?> </references> <references title="Informative References"> <?rfc include="reference.RFC.1195"?> <?rfc include="reference.RFC.2328"?> <?rfc include="reference.RFC.5340"?> <?rfc include="reference.RFC.4271"?> <?rfc include="reference.RFC.4272"?> <?rfc include="reference.RFC.6952"?> <?rfc include="reference.RFC.4552"?> <?rfc include="reference.RFC.7166"?> <?rfc include="reference.RFC.6863"?> <?rfc include="reference.RFC.7474"?> <?rfc include="reference.RFC.5304"?> </references></back> </rfc>