Border Gateway Protocol - Link State (BGP-LS) Extensions for Flexible Algorithm Advertisement

Border Gateway Protocol - Link State (BGP-LS) Extensions for Flexible Algorithm Advertisement Cisco Systems


          India


        ketant.ietf@gmail.com


    
      Cisco Systems
      
        
          
          
          
          
          Slovakia
        
        ppsenak@cisco.com
      

    
    
      LinkedIn
      
        
          
          
          
          United States of America
        
        szandi@linkedin.com
      

    
    
      LinkedIn
      
        
          
          
          
          United States of America
        
        gdawra.ietf@gmail.com
      

    
    
    rtg
    idr
    BGP-LS
    Segment Routing
    IS-IS
    OSPF
    OSPFv3
    
      Flexible Algorithm is a solution that allows some routing protocols
      (e.g., OSPF and IS-IS) to compute paths over a network based on
      user-defined (and hence, flexible) constraints and metrics. The
      computation is performed by routers participating in the specific
      network in a distributed manner using a Flexible Algorithm Definition (FAD).
      This definition is provisioned on one or more routers and propagated
      through the network by OSPF and IS-IS flooding.
      Border Gateway Protocol - Link State (BGP-LS) enables the collection of various
      topology information from the network. This document defines extensions to the
      BGP-LS address family to advertise the FAD as
      a part of the topology information from the network.
    
    
      
        Status of This Memo
        
            This is an Internet Standards Track document.
        
        
            This document is a product of the Internet Engineering Task Force
            (IETF).  It represents the consensus of the IETF community.  It has
            received public review and has been approved for publication by
            the Internet Engineering Steering Group (IESG).  Further
            information on Internet Standards is available in Section 2 of 
            RFC 7841.
        
        
            Information about the current status of this document, any
            errata, and how to provide feedback on it may be obtained at
            .
        
      
      
        Copyright Notice
        
            Copyright (c) 2023 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
            () 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 Revised BSD License text as described in
            Section 4.e of the Trust Legal Provisions and are provided without
            warranty as described in the Revised BSD License.
        
      
    
    
      
        Table of Contents
        
          
            .  Introduction
            
              
                .  Requirements Language
              
            
          
          
            .  Overview of BGP-LS Extensions for Flexible Algorithm
          
          
            .  Flexible Algorithm Definition TLV
            
              
                .  Flexible Algorithm Exclude-Any Affinity Sub-TLV
              
              
                .  Flexible Algorithm Include-Any Affinity Sub-TLV
              
              
                .  Flexible Algorithm Include-All Affinity Sub-TLV
              
              
                .  Flexible Algorithm Definition Flags Sub-TLV
              
              
                .  Flexible Algorithm Exclude SRLG Sub-TLV
              
              
                .  Flexible Algorithm Unsupported Sub-TLV
              
            
          
          
            .  Flexible Algorithm Prefix Metric TLV
          
          
            .  IANA Considerations
          
          
            .  Manageability Considerations
          
          
            .  Security Considerations
          
          
            .  References
            
              
                .  Normative References
              
              
                .  Informative References
              
            
          
          
            Acknowledgements
          
          
            Authors' Addresses


  
    
      Introduction
      The classical IGP (e.g., OSPF and IS-IS) computation of best paths
      over the network is based on the IGP metric assigned to the links in the
      network. Many network deployments use solutions based on RSVP-TE  or Segment Routing (SR) Policy  to enforce traffic over a path that is
      computed using different metrics or constraints than the shortest IGP
      path.  defines the Flexible
      Algorithm solution that allows IGPs themselves to compute constraint-based paths over the
      network.
      Flexible Algorithm is called so because it allows a user the
      flexibility to define:
      
        the type of calculation to be used (e.g., shortest path),
        the metric type to be used (e.g., IGP metric or TE metric), and
        the set of constraints to be used (e.g., inclusion or exclusion
          of certain links using affinities).
      
      The operations of the IGP Flexible Algorithm solution are described
      in detail in .
      The BGP-LS extensions for SR are defined in 
      and  for SR-MPLS and Segment
      Routing over IPv6 (SRv6), respectively. They include the extensions for
      advertisement of SR information including various types of Segment
      Identifiers (SIDs) as below: 
      
        SR Algorithm TLV to indicate the participation of a node in a
          Flexible Algorithm computation
        Prefix-SID TLV to indicate the association of the Prefix-SIDs to
          a specific Flexible Algorithm for SR-MPLS forwarding
        SRv6 Locator TLV to indicate the Locator for a specific Flexible
        Algorithm for SRv6 forwarding
      
      This document defines extensions to BGP-LS for the advertisement of
      the Flexible Algorithm Definition (FAD) information to enable learning
      of the mapping of the Flexible Algorithm number to its definition in
      each area/domain of the underlying IGP. This definition indicates the
      type of computation used and the constraints for a given Flexible
      Algorithm. This information can then be used for setting up SR Policy
      paths end to end across domains by using the appropriate Flexible-Algorithm-specific
      SIDs in its segment list .
      For example, picking the Flexible Algorithm Prefix-SID (in case of
      SR-MPLS) or End SID (in case of SRv6) of Area Border Routers (ABRs) or
      Autonomous System Border Routers (ASBRs) corresponding to a definition
      that optimizes on the delay metric enables the building of an end-to-end
      low-latency path across IGP domains with minimal SIDs in the SID
      list.
      
        Requirements Language
        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   when, and only
        when, they appear in all capitals, as shown here.
      
    
    
      Overview of BGP-LS Extensions for Flexible Algorithm
      BGP-LS  specifies the Node Network Layer
      Reachability Information (NLRI) for the advertisement of nodes, along
      with their attributes using the BGP-LS Attribute; the Link NLRI for the
      advertisement of links, along with their attributes using the BGP-LS
      Attribute; and the Prefix NLRI for the advertisement of prefixes, along
      with their attributes using the BGP-LS Attribute.
      The FADs advertised by a node are considered as a node-level
      attribute and advertised as specified in .
      Various link attributes, like affinities and Shared Risk Link Group
      (SRLG), that are used during the Flexible Algorithm route calculations in
      IS-IS and OSPF are advertised in those protocols using the Application-Specific Link
      Attribute (ASLA) advertisements, as described in , , and . The BGP-LS extensions for ASLA
      advertisements are specified in .
      The Flexible Algorithm Prefix Metric (FAPM) is considered as a prefix
      attribute and advertised as specified in .
    
    
      Flexible Algorithm Definition TLV
      This document defines a new optional BGP-LS Attribute TLV associated
      with the Node NLRI called the "Flexible Algorithm Definition TLV" ("FAD TLV" for short),
      and its format is as follows:
      
        Flexible Algorithm Definition TLV 
        
 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            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   Flex Algo   |   Metric-Type |   Calc-Type   |    Priority   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                sub-TLVs       ...                            //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+      

      
      
        where:
        
          
            Type:
             1039
            Length:
             The total length of the value field (including any
            sub-TLVs) in octets. The length value MUST be 4 or larger.
            Flexible Algorithm (Flex Algo):
             Single octet value carrying the
            Flexible Algorithm number between 128 and 255 inclusive, as defined
            in .
            Metric-Type:
             Single octet value carrying the metric type, as
            defined in .
            Calc-Type:
             Single octet value carrying the calculation type, as
            defined in .
            Priority:
             Single octet value carrying the priority of the FAD
            advertisement, as defined in .
            sub-TLVs:
             Zero or more sub-TLVs may be included, as described
            further in this section.
          
        
      
      The FAD TLV that is advertised in the BGP-LS Attribute along with the
      Node NLRI of a node is derived from the following IGP protocol-specific
      advertisements:
      
        in the case of IS-IS, from the IS-IS Flexible Algorithm
          Definition sub-TLV in 
        in the case of OSPFv2/OSPFv3, from the OSPF Flexible Algorithm
          Definition TLV in 
      
      The BGP-LS Attribute associated with a Node NLRI may include one or
      more FAD TLVs corresponding to the FAD for each algorithm that the
      particular node is advertising.
      The following subsections define sub-TLVs of the FAD TLV.
      
        Flexible Algorithm Exclude-Any Affinity Sub-TLV
        The Flexible Algorithm Exclude-Any Affinity sub-TLV is an optional
        sub-TLV that is used to carry the affinity constraints associated with
        the FAD and enable the exclusion of links carrying any of the
        specified affinities from the computation of the specific algorithm, as
        described in . The affinity is
        expressed in terms of the Extended Admin Group (EAG), as defined in .
        The sub-TLV has the following format:
        
          Flexible Algorithm Exclude-Any Affinity Sub-TLV
          
 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           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|             Exclude-Any EAG (variable)                       //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+   

        
        
          where:
          
            
              Type:
              1040
              Length:
              The total length of the value field in octets dependent
              on the size of the EAG. It MUST be a non-zero value and a multiple
              of 4.
              Exclude-Any EAG:
              The EAG value, as defined in .
            
          
        
        The information in the Flexible Algorithm Exclude-Any Affinity
        sub-TLV is derived from the IS-IS and OSPF protocol-specific Flexible
        Algorithm Exclude Admin Group sub-TLV, as defined in .
      
      
        Flexible Algorithm Include-Any Affinity Sub-TLV
        The Flexible Algorithm Include-Any Affinity sub-TLV is an optional
        sub-TLV that is used to carry the affinity constraints associated with
        the FAD and enable the inclusion of links carrying any of the
        specified affinities in the computation of the specific algorithm, as
        described in . The affinity is
        expressed in terms of the EAG, as defined in .
        The sub-TLV has the following format:
        
          Flexible Algorithm Include-Any Affinity Sub-TLV
          
 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           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|             Include-Any EAG (variable)                       //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  

        
        
          where:
          
            
              Type:
              1041
              Length:
              The total length of the value field in octets dependent
              on the size of the EAG. It MUST be a non-zero value and a multiple
              of 4.
              Include-Any EAG:
              The EAG value, as defined in .
            
          
        
        The information in the Flexible Algorithm Include-Any Affinity
        sub-TLV is derived from the IS-IS and OSPF protocol-specific Flexible
        Algorithm Include-Any Admin Group sub-TLV, as defined in .
      
      
        Flexible Algorithm Include-All Affinity Sub-TLV
        The Flexible Algorithm Include-All Affinity sub-TLV is an optional
        sub-TLV that is used to carry the affinity constraints associated with
        the FAD and enable the inclusion of links carrying all of the
        specified affinities in the computation of the specific algorithm, as
        described in . The affinity is
        expressed in terms of the EAG, as defined in .
        The sub-TLV has the following format:
        
          Flexible Algorithm Include-All Affinity Sub-TLV
          
 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           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|             Include-All EAG (variable)                       //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  

        
        
          where:
          
            
              Type:
              1042
              Length:
              The total length of the value field in octets dependent
              on the size of the EAG. It MUST be a non-zero value and a multiple
              of 4.
              Include-All EAG:
              The EAG value, as defined in .
            
          
        
        The information in the Flexible Algorithm Include-All Affinity
        sub-TLV is derived from the IS-IS and OSPF protocol-specific Flexible
        Algorithm Include-All Admin Group sub-TLV, as defined in .
      
      
        Flexible Algorithm Definition Flags Sub-TLV
        The Flexible Algorithm Definition Flags sub-TLV is an optional
        sub-TLV that is used to carry the flags associated with the FAD that
        are used in the computation of the specific algorithm, as described in
        .
        The sub-TLV has the following format:
        
          Flexible Algorithm Definition Flags Sub-TLV
          
 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           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                       Flags (variable)                       //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+  

        
        
          where:
          
            
              Type:
              1043
              Length:
              The total length of the value field in octets dependent
              on the size of the flags. It MUST be a non-zero value and a
              multiple of 4.
              Flags:
              The bitmask used to represent the flags for the FAD, as
              defined in .
            
          
        
        The information in the Flexible Algorithm Definition Flags sub-TLV
        is derived from the IS-IS and OSPF protocol-specific Flexible
        Algorithm Definition Flags sub-TLV, as defined in .
      
      
        Flexible Algorithm Exclude SRLG Sub-TLV
        The Flexible Algorithm Exclude SRLG sub-TLV is an optional sub-TLV
        that is used to carry the Shared Risk Link Group (SRLG) information
        associated with the FAD and enable the exclusion of links that are
        associated with any of the specified SRLG in the computation of the
        specific algorithm, as described in . The SRLGs associated with a link
        are carried in the BGP-LS Shared Risk Link Group (TLV 1096) .
        The sub-TLV has the following format:
        
          Flexible Algorithm Exclude SRLG Sub-TLV
          
 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           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|           Shared Risk Link Group Values (variable)           //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+   

        
        
          where:
          
            
              Type:
              1045
              Length:
              The total length of the value field in octets dependent
              on the number of SRLG values carried. It MUST be a non-zero value
              and a multiple of 4.
              Shared Risk Link Group Values:
              One or more SRLG values, each with a 
              size of 4 octets, as defined in .
            
          
        
        The information in the Flexible Algorithm Exclude SRLG sub-TLV is
        derived from the IS-IS and OSPF protocol-specific Flexible Algorithm
        Exclude SRLG sub-TLV, as defined in .
      
      
        Flexible Algorithm Unsupported Sub-TLV
        The OSPF and IS-IS signaling for FAD allows for extensions via new
        sub-TLVs under the respective IGP's Flexible Algorithm Definition TLV.
        As specified in , it is important that the entire FAD
        be understood by anyone using it for computation purposes. Therefore,
        the FAD is different from most other protocol extensions, where the
        skipping or ignoring of unsupported sub-TLV information does not
        affect the base behavior.
        The Flexible Algorithm Unsupported sub-TLV is an optional sub-TLV
        that is used to indicate the presence of unsupported FAD sub-TLVs. The
        need for this sub-TLV arises when the BGP-LS implementation on the
        advertising node does not support one or more of the FAD sub-TLVs
        present in the IGP advertisement.
        The sub-TLV has the following format:
        
          Flexible Algorithm Unsupported Sub-TLV
          
 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           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|  Protocol-ID  | sub-TLV types (variable) ...                 //
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+   

        
        
          where:
          
            
              Type:
              1046
              Length:
               The total length of the value field in octets
            (including any included sub-TLV types).
              Protocol-ID:
               Indicates the BGP-LS Protocol-ID of the protocol
            from which the FAD is being advertised via BGP-LS. The values are
            from the IANA "BGP-LS Protocol-IDs" subregistry 
            under the "Border Gateway Protocol - Link State (BGP-LS) Parameters"
	    registry .
              sub-TLV types:
               Zero or more sub-TLV types that are not
            supported by the node originating the BGP-LS advertisement. The
            size of each sub-TLV type depends on the protocol indicated by the
            Protocol-ID field. For example, for IS-IS, each sub-TLV type would
            be 1 octet in size, while for OSPF, each sub-TLV type would be 2 octets
            in size.
            
          
        
        The node originating the advertisement MUST include the Flexible
        Algorithm Unsupported sub-TLV when it comes across an unsupported
        sub-TLV in the corresponding FAD in the IS-IS and OSPF advertisement.
        When advertising the Flexible Algorithm Unsupported sub-TLV, the
        protocol-specific sub-TLV types that are not supported SHOULD be
        included. This information serves as a diagnostic aid.
        The discussion on the use of the FAD information by the consumers
        of the BGP-LS information is beyond the scope of this document.
        However, it is RECOMMENDED that the choice of the node used for
        originating the IGP topology information into BGP-LS be made such that
        the advertising node supports all the FAD extensions in use in its
        part of the network. This avoids the scenario where an incomplete FAD
        gets advertised via BGP-LS.
      
    
    
      Flexible Algorithm Prefix Metric TLV
      This document defines a new optional BGP-LS Attribute TLV associated
      with the Prefix NLRI called the "Flexible Algorithm Prefix Metric TLV
      ("FAPM TLV" for short), and its format is as follows:
      
        Flexible Algorithm Prefix Metric TLV
         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           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|   Flex Algo   |     Flags     |            Reserved           |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                            Metric                             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      
      
        where:
        
          
            Type:
            1044
            Length:
            8 octets
            Flexible Algorithm (Flex Algo):
            Single octet value carrying the
            Flexible Algorithm number between 128 and 255 inclusive, as defined
            in .
            Flags:
            Single octet value and only applicable for OSPF, as defined
            in . The value MUST be set
	    to 0 for IS-IS.
            Reserved:
            2-octet value that MUST be set to 0 by the
	    originator and MUST be ignored by the receiver.
            Metric:
            4-octet field to carry the metric information.
          
        
      
      The FAPM TLV that is advertised in the BGP-LS Attribute along with
      the Prefix NLRI from a node is derived from the following IGP
      protocol-specific advertisements:
      
        in the case of IS-IS, from the IS-IS Flexible Algorithm Prefix
        Metric sub-TLV in 
        in the case of OSPFv2/OSPFv3, from the OSPF Flexible Algorithm
        Prefix Metric sub-TLV in 
      
      The BGP-LS Attribute associated with a Prefix NLRI may include one or
      more FAPM TLVs corresponding to the Flexible Algorithm Prefix Metric for
      each algorithm associated with that particular prefix.
    
    
      IANA Considerations
      IANA has allocated code points in the "BGP-LS Node
      Descriptor, Link Descriptor, Prefix Descriptor, and Attribute TLVs" registry
      
      based on the table below for the TLVs/sub-TLVs introduced by this
      document.
      Flexible Algorithm Code Points
        
        
          
            TLV Code Point
            Description
          
        
        
          
            1039
            Flexible Algorithm Definition
          
          
            1040
            Flexible Algorithm Exclude-Any Affinity
          
          
            1041
            Flexible Algorithm Include-Any Affinity
          
          
            1042
            Flexible Algorithm Include-All Affinity
          
          
            1043
            Flexible Algorithm Definition Flags
          
          
            1044
            Flexible Algorithm Prefix Metric
          
          
            1045
            Flexible Algorithm Exclude SRLG
          
          
            1046
            Flexible Algorithm Unsupported
          
        
      
    
    
      Manageability Considerations
      The new protocol extensions introduced in this document augment the
      existing IGP topology information that can be distributed via . Procedures and protocol extensions defined in this
      document do not affect the BGP protocol operations and management other
      than what is discussed in the "Manageability Considerations" section of . Specifically, the malformed NLRIs attribute tests in
      the "Fault Management" section of  now encompass
      the new TLVs for the BGP-LS NLRI in this document.
      The extensions specified in this document do not specify any new
      configuration or monitoring aspects in BGP or BGP-LS. The specification
      of BGP models is an ongoing work based on .
    
    
      Security Considerations
      Security considerations for acquiring and distributing BGP-LS
      information are discussed in .
      The TLVs introduced in this document are used to propagate the IGP
      Flexible Algorithm extensions defined in . It is assumed that the IGP instances
      originating these TLVs will support all the required security (as
      described in ) for Flexible
      Algorithm deployment.
      This document specifies extensions for the advertisement of node and
      prefix-related Flexible Algorithm information. Tampering with this
      Flexible-Algorithm-related information may affect applications using it,
      including impacting route calculation and programming. As the
      advertisements defined in this document are related to a specific
      Flexible Algorithm topology, the impact of tampering is similarly
      limited in scope.
    
  
  
    
    
    
      References
      
        Normative References
        
          
            Key words for use in RFCs to Indicate Requirement Levels
            
            
            
              In many standards track documents several words are used to signify the requirements in the specification.  These words are often capitalized.  This document defines these words as they should be interpreted in IETF documents.  This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.
            
          
          
          
          
        
        
          
            Extended Administrative Groups in MPLS Traffic Engineering (MPLS-TE)
            
            
            
              MPLS Traffic Engineering (MPLS-TE) advertises 32 administrative groups (commonly referred to as "colors" or "link colors") using the Administrative Group sub-TLV. This is defined for OSPFv2 (RFC 3630), OSPFv3 (RFC 5329) and IS-IS (RFC 5305).
              This document adds a sub-TLV to the IGP TE extensions, "Extended Administrative Group". This sub-TLV provides for additional administrative groups (link colors) beyond the current limit of 32.
            
          
          
          
        
        
          
            North-Bound Distribution of Link-State and Traffic Engineering (TE) Information Using BGP
            
            
            
            
            
            
            
              In a number of environments, a component external to a network is called upon to perform computations based on the network topology and current state of the connections within the network, including Traffic Engineering (TE) information. This is information typically distributed by IGP routing protocols within the network.
              This document describes a mechanism by which link-state and TE information can be collected from networks and shared with external components using the BGP routing protocol. This is achieved using a new BGP Network Layer Reachability Information (NLRI) encoding format. The mechanism is applicable to physical and virtual IGP links. The mechanism described is subject to policy control.
              Applications of this technique include Application-Layer Traffic Optimization (ALTO) servers and Path Computation Elements (PCEs).
            
          
          
          
        
        
          
            Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words
            
            
            
              RFC 2119 specifies common key words that may be used in protocol specifications.  This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings.
            
          
          
          
          
        
        
          
            IGP Flexible Algorithm
            
              
            
            
              
            
            
              
            
            
              
            
            
              
            
            
          
          
          
        
      
      
        Informative References
        
          
            BGP YANG Model for Service Provider Networks
            
              Kloud Services
            
            
              Arrcus
            
            
              Huawei
            
            
              Juniper Networks
            
            
            
                 This document defines a YANG data model for configuring and managing
   BGP, including protocol, policy, and operational aspects, such as
   RIB, based on data center, carrier, and content provider operational
   requirements.

              
            
          
          
          Work in Progress
        
        
          
            BGP Link State Extensions for SRv6
            
              
            
            
              
            
            
              
            
            
              
            
            
              
            
            
              
            
            
          
          
          
          Work in Progress
        
        
          
            RSVP-TE: Extensions to RSVP for LSP Tunnels
            
            
            
            
            
            
            
            
              This document describes the use of RSVP (Resource Reservation Protocol), including all the necessary extensions, to establish label-switched paths (LSPs) in MPLS (Multi-Protocol Label Switching).  Since the flow along an LSP is completely identified by the label applied at the ingress node of the path, these paths may be treated as tunnels.  A key application of LSP tunnels is traffic engineering with MPLS as specified in RFC 2702. [STANDARDS-TRACK]
            
          
          
          
        
        
          
            Segment Routing Architecture
            
            
            
            
            
            
            
            
              Segment Routing (SR) leverages the source routing paradigm. A node steers a packet through an ordered list of instructions, called "segments". A segment can represent any instruction, topological or service based. A segment can have a semantic local to an SR node or global within an SR domain. SR provides a mechanism that allows a flow to be restricted to a specific topological path, while maintaining per-flow state only at the ingress node(s) to the SR domain.
              SR can be directly applied to the MPLS architecture with no change to the forwarding plane. A segment is encoded as an MPLS label. An ordered list of segments is encoded as a stack of labels. The segment to process is on the top of the stack. Upon completion of a segment, the related label is popped from the stack.
              SR can be applied to the IPv6 architecture, with a new type of routing header. A segment is encoded as an IPv6 address. An ordered list of segments is encoded as an ordered list of IPv6 addresses in the routing header. The active segment is indicated by the Destination Address (DA) of the packet. The next active segment is indicated by a pointer in the new routing header.
            
          
          
          
        
        
          
            IS-IS Application-Specific Link Attributes
            
            
            
            
            
            
            
              Existing traffic-engineering-related link attribute advertisements have been defined and are used in RSVP-TE deployments.  Since the original RSVP-TE use case was defined, additional applications (e.g., Segment Routing Policy and Loop-Free Alternates) that also make use of the link attribute advertisements have been defined.  In cases where multiple applications wish to make use of these link attributes, the current advertisements do not support application-specific values for a given attribute, nor do they support indication of which applications are using the advertised value for a given link.  This document introduces new link attribute advertisements that address both of these shortcomings.
            
          
          
          
        
        
          
            OSPF Application-Specific Link Attributes
            
            
            
            
            
            
            
              Existing traffic-engineering-related link attribute advertisements have been defined and are used in RSVP-TE deployments.  Since the original RSVP-TE use case was defined, additional applications (e.g., Segment Routing Policy and Loop-Free Alternates) that also make use of the link attribute advertisements have been defined.  In cases where multiple applications wish to make use of these link attributes, the current advertisements do not support application-specific values for a given attribute, nor do they support indication of which applications are using the advertised value for a given link.  This document introduces new link attribute advertisements in OSPFv2 and OSPFv3 that address both of these shortcomings.
            
          
          
          
        
        
          
            Border Gateway Protocol - Link State (BGP-LS) Extensions for Segment Routing
            
            
            
            
            
            
            
              Segment Routing (SR) allows for a flexible definition of end-to-end paths by encoding paths as sequences of topological subpaths, called "segments". These segments are advertised by routing protocols, e.g., by the link-state routing protocols (IS-IS, OSPFv2, and OSPFv3) within IGP topologies.
              This document defines extensions to the Border Gateway Protocol - Link State (BGP-LS) address family in order to carry SR information via BGP.
            
          
          
          
        
        
          
            Segment Routing Policy Architecture
            
            
            
            
            
            
            
              Segment Routing (SR) allows a node to steer a packet flow along any path. Intermediate per-path states are eliminated thanks to source routing. SR Policy is an ordered list of segments (i.e., instructions) that represent a source-routed policy. Packet flows are steered into an SR Policy on a node where it is instantiated called a headend node. The packets steered into an SR Policy carry an ordered list of segments associated with that SR Policy.
              This document updates RFC 8402 as it details the concepts of SR Policy and steering into an SR Policy.
            
          
          
          
        
        
          
            Application-Specific Link Attributes Advertisement Using the Border Gateway Protocol - Link State (BGP-LS)
            
            
            
            
            
              Extensions have been defined for link-state routing protocols that enable distribution of application-specific link attributes for existing as well as newer applications such as Segment Routing (SR).  This document defines extensions to the Border Gateway Protocol - Link State (BGP-LS) to enable the advertisement of these application-specific attributes as a part of the topology information from the network.
            
          
          
          
        
      
    
    
      Acknowledgements
      The authors would like to thank , , ,
      , and  for
      their reviews and contributions to this work. The authors would like to thank  for his shepherd review. The authors would like to thank  for his detailed AD review and suggestions for improving this
      document.
    
    
      Authors' Addresses
      
        Cisco Systems
        
          
            
            
            
            
            India
          
          ketant.ietf@gmail.com
        

      
      
        Cisco Systems
        
          
            
            
            
            
            Slovakia
          
          ppsenak@cisco.com
        

      
      
        LinkedIn
        
          
            
            
            
            United States of America
          
          szandi@linkedin.com
        

      
      
        LinkedIn
        
          
            
            
            
            United States of America
          
          gdawra.ietf@gmail.com

TLV Code Point	Description
1039	Flexible Algorithm Definition
1040	Flexible Algorithm Exclude-Any Affinity
1041	Flexible Algorithm Include-Any Affinity
1042	Flexible Algorithm Include-All Affinity
1043	Flexible Algorithm Definition Flags
1044	Flexible Algorithm Prefix Metric
1045	Flexible Algorithm Exclude SRLG
1046	Flexible Algorithm Unsupported