<?xml version="1.0" encoding="iso-8859-1"?>
<!--<!DOCTYPE rfc SYSTEM "rfc4748.dtd"> -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY rfc2119 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY rfc8174 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.8174.xml">
<!ENTITY rfc7794 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7794.xml">
<!ENTITY rfc5302 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5302.xml">
<!ENTITY rfc7684 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7684.xml">
<!ENTITY rfc5340 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5340.xml">
<!ENTITY rfc8362 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.8362.xml">
<!ENTITY rfc8476 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.8476.xml">
<!ENTITY rfc8491 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.8491.xml">
<!ENTITY rfc7752 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.7752.xml">
<!ENTITY rfc8814 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.8814.xml">
<!ENTITY I-D.ietf-isis-mpls-elc PUBLIC "" "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-isis-mpls-elc.xml">
<!ENTITY I-D.ietf-ospf-mpls-elc PUBLIC "" "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-ospf-mpls-elc.xml">
<!ENTITY I-D.ietf-idr-bgp-ls-segment-routing-ext PUBLIC "" "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-idr-bgp-ls-segment-routing-ext.xml">
<!ENTITY I-D.ietf-mpls-inband-pm-encapsulation PUBLIC "" "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-mpls-inband-pm-encapsulation.xml">
]>
<rfc category="std" ipr="trust200902" docName="draft-xzc-lsr-mpls-flc-flrd-00">

<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>

<?rfc toc="yes"?>
<?rfc symrefs="yes" ?>
<?rfc sortrefs="yes" ?>
<?rfc compact="yes" ?>
<?rfc subcompact="no" ?>

<front>
        <title abbrev="Signaling FLC and FLRD using IGP and BGP-LS"> Signaling Flow-ID Label Capability and Flow-ID Readable Label Depth Using IGP and BGP-LS </title>

  <author fullname="Xiao Min" initials="X" surname="Min">
      <organization>ZTE Corp.</organization>
     <address>
       <postal>
         <street/>

         <!-- Reorder these if your country does things differently -->

         <city>Nanjing</city>

         <region/>

         <code/>

         <country>China</country>
       </postal>

       <phone/>

       <email>xiao.min2@zte.com.cn</email>

       <!-- uri and facsimile elements may also be added -->
     </address>
    </author>
	
  <author fullname="Zheng(Sandy) Zhang" initials="Z" surname="Zhang">
      <organization>ZTE Corp.</organization>
     <address>
       <postal>
         <street/>

         <!-- Reorder these if your country does things differently -->

         <city>Nanjing</city>

         <region/>

         <code/>

         <country>China</country>
       </postal>

       <phone/>

       <email>zhang.zheng@zte.com.cn</email>

       <!-- uri and facsimile elements may also be added -->
     </address>
    </author>

  <author fullname="Weiqiang Cheng" initials="W" surname="Cheng">
      <organization>China Mobile</organization>
     <address>
       <postal>
         <street></street>

         <!-- Reorder these if your country does things differently -->

         <city>Beijing</city>

         <region></region>

         <code></code>

         <country>China</country>
       </postal>

       <phone></phone>

       <email>chengweiqiang@chinamobile.com</email>

       <!-- uri and facsimile elements may also be added -->
     </address>
    </author>

	
    <date year="2021"/>
  
    <area>Routing</area>
    <workgroup>LSR Working Group</workgroup>

    <keyword>Request for Comments</keyword>
    <keyword>RFC</keyword>
    <keyword>Internet Draft</keyword>
    <keyword>I-D</keyword>

    <abstract>
  <t> Flow-ID Label (FL) is used for MPLS flow identification and flow-based performance measurement with alternate marking 
  method. The ability to process Flow-ID labels is called Flow-ID Label Capability (FLC), and the capability of reading 
  the maximum label stack depth and performing FL-based performance measurement is called Flow-ID Readable Label Depth (FRLD). 
  This document defines a mechanism to signal the FLC and the FRLD using IGP and BGP-LS. </t>
    </abstract>
    
</front>
  
<middle>

  <section title="Introduction">

  <t> As specified in <xref target="I-D.ietf-mpls-inband-pm-encapsulation"/>, Flow-ID Label (FL) is used for MPLS 
  flow identification and flow-based performance measurement with alternate marking method. </t>
  
  <t> Flow-ID Label may appear multiple times in a label stack with variable depth, so both the Flow-ID Label 
  Capability (FLC) and the Flow-ID Readable Label Depth (FRLD) are defined in <xref target="I-D.ietf-mpls-inband-pm-encapsulation"/>. </t>
  
  <t> Analogous to <xref target="I-D.ietf-isis-mpls-elc"/> and <xref target="I-D.ietf-ospf-mpls-elc"/>, this document 
  defines a mechanism to signal the FLC and the FRLD using IGP and BGP-LS, specifically, IGP includes IS-IS, OSPFv2 and OSPFv3. </t>
  
  <section title="Terminology">

    <t> This memo makes use of the terms defined in <xref target="I-D.ietf-mpls-inband-pm-encapsulation"/> and <xref target="RFC8491"/>. </t>
  
	<t> The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",   "SHOULD", "SHOULD NOT", "RECOMMENDED", 
	"NOT RECOMMENDED", "MAY", and   "OPTIONAL" in this document are to be interpreted as described in BCP 14 
	<xref target="RFC2119"/> <xref target="RFC8174"/> when, and only when, they appear in all capitals, as shown here.</t>
	
  </section>
  </section>
  
  <section title="Advertising FLC Using IGP">

  <t> Even though FLC is a property of the node, in some cases it is advantageous to associate and advertise the FLC with a 
  prefix, so FLC is advertised with a prefix in this document.</t>
  
  <t> If a router has multiple interfaces, the router MUST NOT announce FLC unless all of its interfaces are capable of processing FLs.</t>
  
  <t> If the router supports FLs on all of its interfaces, it SHOULD advertise the FLC with every local host prefix it advertises in IGP.</t>

  <section title="Advertising FLC Using IS-IS">
  
  <t> Next to the ELC Flag (E-flag) defined in Section 3 of <xref target="I-D.ietf-isis-mpls-elc"/>, a new bit FLC Flag (F-flag) 
  is defined, which is Bit 4 in the Prefix Attribute Flags <xref target="RFC7794"/>, as shown in Figure 1. </t>
  
  <figure anchor="Figure_1" title="Prefix Attribute Flags">
  <artwork align="center">
<![CDATA[
   0 1 2 3 4 5 6 7...
  +-+-+-+-+-+-+-+-+...
  |X|R|N|E|F|      ...
  +-+-+-+-+-+-+-+-+...
]]>
  </artwork>
  </figure>
  
     <t> F-Flag:  FLC Flag (Bit 4)
		   <list>
		   <t> Set for local host prefix of the originating node if it supports FLC on all interfaces.</t>
		   </list>
	 </t>
  
  <t> The FLC signaling MUST be preserved when a router propagates a prefix between ISIS levels <xref target="RFC5302"/>. </t>  
  
  </section>
  
  <section title="Advertising FLC Using OSPFv2">
	
  <t> Next to the ELC Flag (E-flag) defined in Section 3.1 of <xref target="I-D.ietf-ospf-mpls-elc"/>, a new bit FLC Flag (F-flag) 
  is defined, which is Bit 3 in Flags field of OSPFv2 Extended Prefix TLV <xref target="RFC7684"/>:
     <list>
	 <t> 0x10 - F-Flag (FLC Flag): Set for local host prefix of the originating node if it supports FLC on all interfaces.</t>
	 </list>
  </t>
  
  <t> The FLC signaling MUST be preserved when an OSPFv2 Area Border Router (ABR) distributes information between areas. To do so, an 
  ABR MUST originate an OSPFv2 Extended Prefix Opaque LSA <xref target="RFC7684"/> including the received FLC setting.</t>
  
  </section>
  
  <section title="Advertising FLC Using OSPFv3">
	
  <t> Next to the ELC Flag (E-flag) defined in Section 3.2 of <xref target="I-D.ietf-ospf-mpls-elc"/>, a new bit FLC Flag (F-flag) 
  is defined, which is Bit 0 in OSPFv3 PrefixOptions field <xref target="RFC5340"/>:
     <list>
	 <t> 0x80 - F-Flag (FLC Flag): Set for local host prefix of the originating node if it supports FLC on all interfaces.</t>
	 </list>
  </t>
  
  <t> The FLC signaling MUST be preserved when an OSPFv3 Area Border Router (ABR) distributes information between areas. The setting 
  of the FLC Flag in the Inter-Area-Prefix-LSA <xref target="RFC5340"/> or in the Inter-Area-Prefix TLV <xref target="RFC8362"/>, 
  generated by an ABR, MUST be the same as the value the FLC Flag associated with the prefix in the source area.</t>
  
  </section>
  
  </section>
  
  <section title="Advertising FRLD Using IGP">

  <t> As requested by <xref target="RFC8491"/>, IANA has created an IANA-managed registry titled "IGP MSD-Types" to 
  identify MSD-Types. A new MSD-Type, called FRLD-MSD, is defined to advertise the FRLD of a given router. The MSD-Type 
  code 3 is requested to be assigned by IANA for FRLD-MSD. The MSD-Value field is set to the FRLD in the range between 
  0 to 255. </t>
  
  <t> If a router has multiple interfaces with different capabilities of reading the maximum label stack depth, 
  the router MUST advertise the smallest value found across all of its interfaces.</t>
  
  <t> For IS-IS, the FRLD is advertised in a Node MSD Sub-TLV <xref target="RFC8491"/> using the FRLD-MSD type. </t>
  
  <t> For OSPF including both OSPFv2 and OSPFv3, the FRLD is advertised in a Node MSD TLV <xref target="RFC8476"/> using the FRLD-MSD type. </t>
  
  <t> The absence of FRLD-MSD advertisements indicates only that the advertising node does not support advertisement 
  of this capability. </t>

  </section>
    
  <section title="Signaling FLC and FRLD in BGP-LS">
	
  <t> The IGP extensions defined in this document can be advertised via BGP-LS (Distribution of Link-State and TE Information 
  Using BGP) <xref target="RFC7752"/> using existing BGP-LS TLVs. </t>
  
  <t> The FLC is advertised using the Prefix Attribute Flags TLV as defined in <xref target="I-D.ietf-idr-bgp-ls-segment-routing-ext"/>. </t>
  
  <t> The FRLD-MSD is advertised using the Node MSD TLV as defined in <xref target="RFC8814"/>. </t>
  
  </section>
  
  <section title="Security Considerations">
  <t> This document does not raise any additional security issues beyond those of the specifications referred to in 
  the list of normative references.</t>
  </section>
  
  <section title="IANA Considerations"> 
  <t> This document requests the following allocations from IANA:
     <list>	 
	 <t> - Bit 4 in the Bit Values for Prefix Attribute Flags Sub-TLV registry is requested to be assigned to the FLC Flag (F-Flag).</t>
	 <t> - Flag 0x10 in the OSPFv2 Extended Prefix TLV Flags registry is requested to be assigned to the FLC Flag (F-Flag).</t>
	 <t> - Bit 0x80 in the "OSPFv3 Prefix Options (8 bits)" registry is requested to be assigned to the FLC Flag (F-Flag).</t>
	 <t> - Type 3 in the IGP MSD-Types registry is requested to be assigned to the FRLD-MSD.</t>	 
	 </list>
  </t>
  </section>

  <section title="Acknowledgements">
  <t> TBA. </t>
  </section>  
  
</middle>
  
<back>

    <references title="Normative References">
	 &rfc2119;
     &rfc8174;
     &rfc7794;
     &rfc5302; 
     &rfc7684;
     &rfc5340;
     &rfc8362;
     &rfc8476;
     &rfc8491;
     &rfc7752;
     &rfc8814;
	 &I-D.ietf-isis-mpls-elc;
	 &I-D.ietf-ospf-mpls-elc;
	 &I-D.ietf-idr-bgp-ls-segment-routing-ext;
	 &I-D.ietf-mpls-inband-pm-encapsulation;
    </references>
	
</back>
</rfc>
