<?xmlversion="1.0" encoding="US-ASCII"?>version='1.0' encoding='utf-8'?> <!DOCTYPE rfc SYSTEM"rfc2629.dtd" [ <!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml"> <!ENTITY RFC8174 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.8174.xml"> <!ENTITY IANA_STAT_ADJRIBOUT_PRE "14"> <!ENTITY IANA_STAT_ADJRIBOUT_POST "15"> <!ENTITY IANA_STAT_ADJRIBOUT_PER_SAFI_PRE "16"> <!ENTITY IANA_STAT_ADJRIBOUT_PER_SAFI_POST "17"> <!ENTITY IANA_PEER_INFO_TLV_ADMIN_LABEL "4"> ]> <?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>"rfc2629-xhtml.ent"> <rfc number="8671" xmlns:xi="http://www.w3.org/2001/XInclude" category="std" docName="draft-ietf-grow-bmp-adj-rib-out-07" ipr="trust200902" consensus="true" submissionType="IETF"updates="7854"> <?rfc strict="yes" ?> <?rfc toc="yes"?> <?rfc tocdepth="4"?> <?rfc symrefs="yes"?> <?rfc sortrefs="yes" ?> <?rfc compact="yes" ?> <?rfc subcompact="no" ?>updates="7854" obsoletes="" xml:lang="en" tocInclude="true" symRefs="true" sortRefs="true" version="3"> <!-- xml2rfc v2v3 conversion 2.27.1 --> <front> <title abbrev="BMP Adj-RIB-Out"> Support for Adj-RIB-Out in the BGP Monitoring Protocol (BMP)</title> <!-- [rfced] *ADs, please review the new Section 7.2 and let us know if you approve this added text. This change was sent to us after the document was approved for publication. You can view the added text in this diff file: rfc8671-diff.html. --> <seriesInfo name="RFC" value="8671" /> <author fullname="Tim Evens" initials="T" surname="Evens"> <organization>Cisco Systems</organization> <address> <postal> <street>2901 Third Avenue, Suite 600</street> <city>Seattle</city> <region>WA</region> <code>98121</code><country>USA</country><country>United States of America</country> </postal> <email>tievens@cisco.com</email> </address> </author> <author fullname="Serpil Bayraktar" initials="S" surname="Bayraktar"> <organization>Cisco Systems</organization> <address> <postal> <street>3700 Cisco Way</street> <city>San Jose</city> <region>CA</region> <code>95134</code><country>USA</country><country>United States of America</country> </postal> <email>serpil@cisco.com</email> </address> </author> <author fullname="Paolo Lucente" initials="P" surname="Lucente"> <organization>NTT Communications</organization> <address> <postal> <street>Siriusdreef 70-72</street> <city>Hoofddorp</city> <code>2132</code> <region>WT</region> <country>NL</country> </postal> <email>paolo@ntt.net</email> </address> </author> <author fullname="Penghui Mi" initials="P" surname="Mi"> <organization>Tencent</organization> <address> <postal> <street>TengyunBuilding,Tower A ,No.Building, Tower A, No. 397 Tianlin Road</street> <city>Shanghai</city> <code>200233</code><region></region><region/> <country>China</country> </postal><email>kevinmi@tencent.com</email><email>Penghui.Mi@gmail.com</email> </address> </author> <author fullname="Shunwan Zhuang" initials="S" surname="Zhuang"> <organization>Huawei</organization> <address> <postal> <street>HuaweiBld.,Building, No.156 Beiqing Rd.</street> <city>Beijing</city> <code>100095</code><region></region><region/> <country>China</country> </postal> <email>zhuangshunwan@huawei.com</email> </address> </author> <date month="October" year="2019"/> <area>General</area> <workgroup>Global Routing Operations</workgroup> <keyword>BGP</keyword> <keyword>BMP</keyword> <keyword>adj-rib-out</keyword> <abstract> <t> The BGP Monitoring Protocol (BMP) only defines access toonlytheAdj-RIB- InAdj-RIB-In Routing Information Bases (RIBs). This document updatesthe BGP Monitoring Protocol (BMP) RFC 7854BMP (RFC 7854) by adding access to theAdj-RIB- OutAdj-RIB-Out RIBs. It also adds a new flag to the peer header to distinguishAdj- RIB-Inbetween Adj-RIB-In and Adj-RIB-Out. </t> </abstract> </front> <middle> <sectiontitle="Introduction" anchor="Introduction">anchor="Introduction" numbered="true" toc="default"> <name>Introduction</name> <t> The BGP Monitoring Protocol (BMP) defines monitoring of the received (e.g., Adj-RIB-In) Routing Information Bases (RIBs) per peer. TheAdj-RIB-Inpre-policy Adj-RIB-In conveys to a BMP receiver all RIB data before any policy has been applied. TheAdj-RIB-Inpost-policy Adj-RIB-In conveys to a BMP receiver all RIB data after policy filters and/or modifications have been applied. An example of pre-policy versus post-policy is when an inbound policy applies attribute modification or filters. Pre-policy would contain information prior to the inbound policy changes or filters of data.Post policyPost-policy would convey the changed data or would not contain the filtered data.<vspace blankLines="1"/></t> <t> Monitoring the received updates that the router received before any policy has been applied is the primary level of monitoring for mostuse-cases.use cases. Inbound policy validation and auditingisare the primaryuse-caseuse cases for enabling post-policy monitoring.<vspace blankLines="1"/></t> <t> In order for a BMP receiver to receive any BGP data, the BMP sender (e.g., router) needs to have an established BGP peering session and actively be receiving updates for an Adj-RIB-In.<vspace blankLines="1"/></t> <t> Being able to only monitor the Adj-RIB-In puts a restriction on what data is available to BMP receivers via BMP senders (e.g., routers). This is an issue when the receiving end of the BGP peer is not enabled for BMP or when it is not accessible for administrative reasons. For example, a service provider advertises prefixes to a customer, but the service provider cannot see what it advertises via BMP. Asking the customer to enable BMP and monitoring of the Adj-RIB-Inisare not feasible.<vspace blankLines="1"/> BGP Monitoring Protocol (BMP)</t> <t> BMP <xreftarget="RFC7854">RFC 7854</xref>target="RFC7854" format="default"/> only defines Adj-RIB-In being sent to BMP receivers. This document updates the per-peer header defined in <xreftarget="RFC7854">section 4.2 of</xref>target="RFC7854" sectionFormat="of" section="4.2" /> by adding a new flag to distinguish between Adj-RIB-Inversusand Adj-RIB-Out. BMP senders use the new flag to send either Adj-RIB-In or Adj-RIB-Out.<vspace blankLines="1"/></t> <t> Adding Adj-RIB-Out provides the ability for a BMP sender to send to BMP receivers what it advertises to BGP peers, which can be used for outbound policy validation and to monitor routes that were advertised. </t> </section> <sectiontitle="Terminology">numbered="true" toc="default"> <name>Terminology</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 <xreftarget="RFC2119">RFC 2119</xref>target="RFC2119"/> <xreftarget="RFC8174">RFC 8174</xref>target="RFC8174"/> when, and only when, they appear in all capitals, as shown here. </t> </section> <sectiontitle="Definitions"> <t> <list style="symbols"> <t> Adj-RIB-Out: Asnumbered="true" toc="default"> <name>Definitions</name> <dl newline="true" spacing="normal"> <dt>Adj-RIB-Out</dt> <dd>As defined in <xreftarget="RFC4271"/>,target="RFC4271" format="default"/>, "The Adj-RIBs-Out contains the routes for advertisement to specific peers by means of the local speaker's UPDATEmessages." </t> <t> Pre-Policy Adj-RIB-Out: Themessages."</dd> <dt>Pre-policy Adj-RIB-Out</dt> <dd>The result before applying the outbound policy to an Adj-RIB-Out. This normally would match what is in the localRIB. </t> <t> Post-Policy Adj-RIB-Out: TheRIB.</dd> <dt>Post-policy Adj-RIB-Out</dt> <dd>The result of applying outbound policy to an Adj-RIB-Out. ThisMUST<bcp14>MUST</bcp14> convey to the BMP receiver what is actually transmitted to thepeer. </t> </list> </t>peer.</dd> </dl> </section> <sectiontitle="Per-Peer Header" anchor="PeerFlags">anchor="PeerFlags" numbered="true" toc="default"> <name>Per-Peer Header</name> <t> The per-peer header has the same structure and flags as defined in <xreftarget="RFC7854">section 4.2 of</xref>target="RFC7854" sectionFormat="of" section="4.2"/> with thefollowingaddition of the O flagaddition:as shown here: </t><figure align="center"><artworkalign="center"><![CDATA[align="left" name="" type="" alt=""><![CDATA[ 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ |V|L|A|O| Resv | +-+-+-+-+-+-+-+-+ ]]></artwork></figure> <t> <list style="symbols"> <t><ul spacing="normal"> <li> The O flag indicates Adj-RIB-In if set to 0 and Adj-RIB-Out if set to 1.</t> </list> <vspace blankLines="1"/></li> </ul> <t> The existing flags are defined in <xreftarget="RFC7854">section 4.2 of</xref>target="RFC7854" sectionFormat="of" section="4.2"/>, and the remaining bits are reserved for future use. TheyMUST<bcp14>MUST</bcp14> be transmitted as00, and their valuesMUST<bcp14>MUST</bcp14> be ignored on receipt.<vspace blankLines="1"/></t> <t> When the O flag is set to 1, the following fields in thePer-Peer Headerper-peer header are redefined:<list style="symbols"> <t></t> <ul spacing="normal"> <li> Peer Address: The remote IP address associated with the TCP session over which the encapsulatedPDUProtocol Data Unit (PDU) is sent.</t> <t></li> <li> Peer AS: The Autonomous System number of the peer to which the encapsulated PDU is sent.</t> <t></li> <li> Peer BGP ID: The BGP Identifier of the peer to which the encapsulated PDU is sent.</t> <t></li> <li> Timestamp: The time when the encapsulated routes were advertised (one may also think of this as the time when they were installed in the Adj-RIB-Out), expressed in seconds and microseconds since midnight (zero hour), January 1, 1970 (UTC). If zero, the time is unavailable. Precision of the timestamp is implementation-dependent.</t> </list> </t></li> </ul> </section> <sectiontitle="Adj-RIB-Out"> <section title="Post-Policy">numbered="true" toc="default"> <name>Adj-RIB-Out</name> <section numbered="true" toc="default"> <name>Post-policy</name> <t> The primaryuse-caseuse case in monitoring Adj-RIB-Out is to monitor the updates transmitted to a BGP peer after outbound policy has been applied. These updates reflect the result after modifications and filters have been applied (e.g.,Adj-RIB-Out Post-Policy).post-policy Adj-RIB-Out). Some attributes are set when the BGP message is transmitted, such asnext-hop.next hop. Post-policy Adj-RIB-OutPost-Policy MUST<bcp14>MUST</bcp14> convey to the BMP receiver what is actually transmitted to the peer.<vspace blankLines="1"/></t> <t> The L flagMUST<bcp14>MUST</bcp14> be set to 1 to indicate post-policy. </t> </section> <sectiontitle="Pre-Policy">numbered="true" toc="default"> <name>Pre-policy</name> <t>SimilarlySimilar to Adj-RIB-In policy validation, pre-policy Adj-RIB-Out can be used to validate and audit outbound policies. For example, a comparison between pre-policy and post-policy can be used to validate the outbound policy.<vspace blankLines="1"/></t> <t> Depending on the BGP peering session type(IBGP,-- Internal BGP (IBGP), IBGP route reflector client,EBGP,External BGP (EBGP), BGP confederations,Route Server Client)route server client -- the candidate routes that make up thePre-Policypre-policy Adj-RIB-Out do not contain alllocal-riblocal RIB routes.Pre-PolicyPre-policy Adj-RIB-Out conveys only routes that are available based on the peering type.Post-PolicyPost-policy represents the filtered/changed routes from the available routes.<vspace blankLines="1"/></t> <t> Some attributes are set only during transmission of the BGP message, i.e.,Post-Policy.post-policy. It is common thatnext-hopthe next hop may be null, loopback, or similar during the pre-policy phase. All mandatory attributes, such asnext-hop, MUSTnext hop, <bcp14>MUST</bcp14> be eitherZEROzero or have an empty length if they are unknown at thePre-Policypre-policy phase completion. The BMP receiver will treat zero or empty mandatory attributes as self-originated.<vspace blankLines="1"/></t> <t> The L flagMUST<bcp14>MUST</bcp14> be set to 0 to indicate pre-policy. </t> </section> </section> <sectiontitle="BMP Messages">numbered="true" toc="default"> <name>BMP Messages</name> <t> Many BMP messages have a per-peerheaderheader, but some are not applicable to Adj-RIB-In or Adj-RIB-Out monitoring, such aspeer upPeer Up anddown notifications.Down Notifications. Unless otherwise defined, the O flag should be set to 0 in the per-peer header in BMP messages. </t> <sectiontitle="Routenumbered="true" toc="default"> <name>Route Monitoring and RouteMirroring">Mirroring</name> <t> The O flagMUST<bcp14>MUST</bcp14> be set accordingly to indicate if the route monitor or route mirroring message conveys Adj-RIB-In or Adj-RIB-Out. </t> </section> <sectiontitle="Statistics Report" anchor="StatisticsReport">anchor="StatisticsReport" numbered="true" toc="default"> <name>Statistics Report</name> <t> The StatisticsreportReport message has a Stat Type field to indicate the statistic carried in the Stat Data field. Statistics report messages are not specific to Adj-RIB-In or Adj-RIB-Out andMUST<bcp14>MUST</bcp14> have the O flag set to zero. The O flagSHOULD<bcp14>SHOULD</bcp14> be ignored by the BMP receiver.<vspace blankLines="1"/> The</t> <t> This document defines the following newstatistic types are added: <list style="symbols"> <t>statistics types: </t> <ul spacing="normal"> <li> Stat Type =&IANA_STAT_ADJRIBOUT_PRE;: (64-bit Gauge)14: Number of routes inAdj-RIBs-Out Pre-Policy. </t> <t>pre-policy Adj-RIB-Out. This statistics type is 64-bit Gauge. </li> <li> Stat Type =&IANA_STAT_ADJRIBOUT_POST;: (64-bit Gauge)15: Number of routes inAdj-RIBs-Out Post-Policy. </t> <t>post-policy Adj-RIB-Out. This statistics type is 64-bit Gauge. </li> <li> Stat Type =&IANA_STAT_ADJRIBOUT_PER_SAFI_PRE;:16: Number of routes in per-AFI/SAFIAdj-RIB-Out Pre- Policy.pre-policy Adj-RIB-Out. The value is structured as: 2-byte Address Family Identifier (AFI), 1-byte Subsequent Address Family Identifier (SAFI), followed by a 64-bit Gauge.</t> <t></li> <li> Stat Type =&IANA_STAT_ADJRIBOUT_PER_SAFI_POST;:17: Number of routes in per-AFI/SAFIAdj-RIB-Out Post-Policy.post-policy Adj-RIB-Out. The value is structured as: 2-byte Address Family Identifier (AFI), 1-byte Subsequent Address Family Identifier (SAFI), followed by a 64-bit Gauge.</t> </list> </t></li> </ul> </section> <sectiontitle="Peer Down andnumbered="true" toc="default"> <name>Peer UpNotifications">and Down Notifications</name> <t> Peer Up and DownnotificationsNotifications convey BGP peering session state to BMP receivers. The state is independent of whether or not route monitoring or route mirroring messages will be sent for Adj-RIB-In, Adj-RIB-Out, or both. BMP receiver implementationsSHOULD<bcp14>SHOULD</bcp14> ignore the O flag in Peer Up and Downnotifications.Notifications. </t> <sectiontitle="Peeranchor="PeerUpInfoTlv" numbered="true" toc="default"> <name>Peer UpInformation" anchor="PeerUpInfoTlv">Information</name> <t>TheThis document defines the following Peer UpmessageInformation TLVtype is added: <list style="symbols">type: </t> <ul spacing="normal"> <li> <t> Type =&IANA_PEER_INFO_TLV_ADMIN_LABEL;:4: Admin Label. The Information field contains a free-form UTF-8 string whose byte length is given by the Information Length field. The value is administratively assigned. There is no requirement to terminate the string with null or any other character.<vspace blankLines="1"/></t> <t> Multipleadmin labelsAdmin Labels can be included in the Peer Upnotification.Notification. When multipleadmin labelsAdmin Labels areincludedincluded, the BMP receiverMUST<bcp14>MUST</bcp14> preserve their order.<vspace blankLines="1"/></t> <t> TheTLVAdmin Label is optional. </t></list> </t></li> </ul> </section> </section> </section> <sectiontitle="Other Considerations"> <section title="Peernumbered="true" toc="default"> <name>Other Considerations</name> <section numbered="true" toc="default"> <name>Peer and UpdateGroups">Groups</name> <t> Peer and update groups are used to group updates shared by many peers. This is a level of efficiency in implementations, not a true representation of what is conveyed to a peer in eitherPre-Policypre-policy orPost-Policy. <vspace blankLines="1"/>post-policy. </t> <t> One of theuse-casesuse cases to monitor post-policy Adj-RIB-OutPost-Policyis to validate and continually ensure the egress updates match what is expected. For example, wholesale peers should never have routes with community X:Y sent to them. In thisuse-case,use case, there may be hundreds of wholesalepeerspeers, but a single peer could have represented the group.<vspace blankLines="1"/></t> <t> From a BMP perspective,thisit should be simple to include a group name in the Peer Up, but it is more complex than that. BGP implementations have evolved to provide comprehensive and structured policy grouping, such as session, AFI/SAFI, and template-basedbasedgroup policy inheritances.<vspace blankLines="1"/></t> <t> This level of structure and inheritance of polices does not provide a simple peer group name or ID, such as wholesale peer.<vspace blankLines="1"/> Instead</t> <t> This document defines a new Admin Label type for Peer Up Information TLVs (<xref target="PeerUpInfoTlv" format="default"/>) that can be used instead of requiring a groupname to be used, a new administrative label informational TLV (<xref target="PeerUpInfoTlv"/>) is added to the Peer Up message. These labels havename. These labels have administrative scope relevance. For example, labels "type=wholesale" and "region=west" could be used to monitor expected policies.<vspace blankLines="1"/></t> <t> Configuration and assignment of labels to peersisare BGPimplementation specific.implementation-specific. </t> </section> <section numbered="true" toc="default"> <name>Changes to Existing BMP Session</name> <t> In case of any change that results in the alteration of behavior of an existing BMP session (i.e., changes to filtering and table names), the session <bcp14>MUST</bcp14> be bounced with a Peer Down/Peer Up sequence. </t> </section> </section> <sectiontitle="Security Considerations">numbered="true" toc="default"> <name>Security Considerations</name> <t> Thesameconsiderationsasin <xreftarget="RFC7854">section 11 of</xref>target="RFC7854" sectionFormat="of" section="11"/> apply to this document. Implementations of this protocolSHOULD<bcp14>SHOULD</bcp14> requireto establishestablishing sessions with authorized and trusted monitoring devices. It is also believed that this document does not add any additional security considerations. </t> </section> <sectiontitle="IANA Considerations"> <t> This document requests that IANA assignnumbered="true" toc="default"> <name>IANA Considerations</name> <t>IANA has assigned the following new parameters to the <ereftarget="https://www.iana.org/assignments/bmp-parameters/bmp-parameters.xhtml"> BMP parameters name space</eref>.target="https://www.iana.org/assignments/bmp-parameters/"> "BGP Monitoring Protocol (BMP) Parameters" registry</eref>. </t> <sectiontitle="BMPnumbered="true" toc="default"> <name>Addition to BMP PeerFlags"> <t> This document definesFlags Registry</name> <t>IANA has made the following assignment for the per-peer headerflags (<xref target="PeerFlags"/>): <list style="symbols"> <t> Flag 3 as O flag: The Oflagindicates Adj-RIB-In if set to 0 and Adj-RIB-Out if set to 1. </t> </list>defined in <xref target="PeerFlags" format="default"/> of this document: </t> <table anchor="iana1" align="left"> <name>Addition to the "BMP Peer Flags" Registry</name> <thead> <tr> <th>Flag</th> <th>Description</th> <th>Reference</th> </tr> </thead> <tbody> <tr> <td>3</td> <td>O flag</td> <td>RFC 8671</td> </tr> </tbody> </table> </section> <sectiontitle="BMPnumbered="true" toc="default"> <name>Additions to BMP StatisticsTypes"> <t> This document defines four statistic typesTypes Registry</name> <t>IANA has made the following assignment for the four statisticsreporting (<xref target="StatisticsReport"/>): <list style="symbols"> <t> Stat Type = &IANA_STAT_ADJRIBOUT_PRE;: (64-bit Gauge) Numbertypes defined in <xref target="StatisticsReport" format="default"/> of this document: </t> <table anchor="iana2" align="left"> <name>Additions to the "BMP Statistics Types" Registry</name> <thead> <tr> <th>Stat Type</th> <th>Description</th> <th>Reference</th> </tr> </thead> <tbody> <tr> <td>14</td> <td>Number of routes inAdj-RIBs-Out Pre-Policy. </t> <t> Stat Type = &IANA_STAT_ADJRIBOUT_POST;: (64-bit Gauge) Numberpre-policy Adj-RIB-Out</td> <td>RFC 8671</td> </tr> <tr> <td>15</td> <td>Number of routes inAdj-RIBs-Out Post-Policy. </t> <t> Stat Type = &IANA_STAT_ADJRIBOUT_PER_SAFI_PRE;: Numberpost-policy Adj-RIB-Out</td> <td>RFC 8671</td> </tr> <tr> <td>16</td> <td>Number of routes in per-AFI/SAFIAdj-RIB-Out Pre- Policy. The value is structured as: 2-byte Address Family Identifier (AFI), 1-byte Subsequent Address Family Identifier (SAFI), followed by a 64-bit Gauge. </t> <t> Stat Type = &IANA_STAT_ADJRIBOUT_PER_SAFI_POST;: Numberpre-policy Adj-RIB-Out</td> <td>RFC 8671</td> </tr> <tr> <td>17</td> <td>Number of routes in per-AFI/SAFIAdj-RIB-Out Post-Policy. The value is structured as: 2-byte Address Family Identifier (AFI), 1-byte Subsequent Address Family Identifier (SAFI), followed by a 64-bit Gauge. </t> </list> </t>post-policy Adj-RIB-Out</td> <td>RFC 8671</td> </tr> </tbody> </table> </section> <sectiontitle="Peer Up Information TLV"> <t> This document defines the following BMP Peer Up Information TLV types (<xref target="PeerUpInfoTlv"/>): <list style="symbols"> <t> Type = &IANA_PEER_INFO_TLV_ADMIN_LABEL;: Admin Label. The Information field contains a free-form UTF-8 string whose byte length is given by the Information Length field. The value is administratively assigned. There is no requirementnumbered="true" toc="default"> <name>Addition toterminate the string with null or any other character. <vspace blankLines="1"/> Multiple admin labels can be included in the Peer Up notification. When multiple admin labels are included theBMPreceiver MUST preserve their order. <vspace blankLines="1"/> The TLV is optional. </t> </list>Initiation Message TLVs Registry</name> <t>IANA has made the following assignment per <xref target="PeerUpInfoTlv" format="default"/> of this document: </t> <table anchor="iana3" align="left"> <name>Addition to the "BMP Initiation Message TLVs" Registry</name> <thead> <tr> <th>Type</th> <th>Description</th> <th>Reference</th> </tr> </thead> <tbody> <tr> <td>4</td> <td>Admin Label</td> <td>RFC 8671</td> </tr> </tbody> </table> </section> </section> </middle> <back><references title="Normative References"> &RFC2119; &RFC8174; <?rfc include="reference.RFC.4271.xml"?> <?rfc include="reference.RFC.7854.xml"?><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.4271.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.7854.xml"/> <xi:include href="https://xml2rfc.ietf.org/public/rfc/bibxml/reference.RFC.8174.xml"/> </references> <section anchor="Acknowledgements"title="Acknowledgements" numbered="no">numbered="false" toc="default"> <name>Acknowledgements</name> <t> The authors would like to thank John Scudder and Mukul Srivastava for their valuable input. </t> </section> <section anchor="Contributors"title="Contributors" numbered="no"> <t> Manish Bhardwaj<vspace/> Cisco Systems<vspace/> 3700 Cisco Way<vspace/> San Jose, CA 95134<vspace/> USA<vspace/> <vspace blankLines="1"/> Email: manbhard@cisco.com<vspace blankLines="1"/> </t> <t> Xianyuzheng<vspace/> Tencent<vspace/> Tencent Building, Kejizhongyi Avenue,<vspace/> Hi-techPark, Nanshan District,Shenzhen 518057, P.R.China<vspace/> <vspace blankLines="1"/> </t> <t> Weiguo<vspace/> Tencent<vspace/> Tencent Building, Kejizhongyi Avenue,<vspace/> Hi-techPark, Nanshan District,Shenzhen 518057, P.R.China<vspace/> <vspace blankLines="1"/> </t> <t> Shugang cheng<vspace/> H3C<vspace/> <vspace blankLines="1"/>numbered="false" toc="default"> <name>Contributors</name> <t>The following individuals contributed to this document: </t> <ul spacing="normal"> <li>Manish Bhardwaj, Cisco Systems</li> <li>Xianyu Zheng, Tencent</li> <li>Wei Guo, Tencent</li> <li>Shugang Cheng, H3C</li> </ul> </section> </back> </rfc>