BGP Extension for SR-MPLS Entropy Label Position

Abstract

This document proposes extensions for BGP to indicate the entropy label position in the SR-MPLS label stack when delivering SR Policy via BGP.¶

1. Introduction

Segment Routing (SR) leverages the source routing paradigm. Segment Routing can be instantiated on MPLS data plane which is referred to as SR-MPLS [RFC8660]. SR-MPLS leverages the MPLS label stack to construct the SR path.¶

Entropy labels (ELs) [RFC6790] are used in the MPLS data plane to provide entropy for load-balancing. The idea behind the entropy label is that the ingress router computes a hash based on several fields from a given packet and places the result in an additional label named "entropy label". Then, this entropy label can be used as part of the hash keys used by an LSR. Using the entropy label as part of the hash keys reduces the need for deep packet inspection in the LSR while keeping a good level of entropy in the load-balancing.¶

[RFC8662] proposes to use entropy labels for SR-MPLS networks and multiple <ELI, EL> pairs may be inserted in the SR-MPLS label stack. The ingress node may decide the number and position of the ELI/ELs which need to be inserted into the label stack, that is termed as ELP (Entropy Label Position) in this document. But in some cases, the controller (e.g. PCE) can be used to perform the TE path computation as well as the Entropy Label Position which is useful for inter-domain scenarios.¶

[I-D.ietf-idr-segment-routing-te-policy] specifies the way to use BGP to distribute one or more of the candidate paths of an SR Policy to the headend of that policy.¶

This document proposes extensions for BGP to indicate the ELP in the segment list when delivering SR Policy via BGP in SR-MPLS networks.¶

2. Conventions used in this document

3. Entropy Label Position in SR-MPLS with the Controller

As described in [RFC8662] section 7, ELI/EL placement is not an easy decision, multiple criteria may be taken into account.¶

First is the Maximum SID Depth (MSD), it defines the maximum number of labels that a particular node can impose on a packet, and it is a limit when the ingress node imposing ELI/EL pairs on the SR label stack.¶

The Entropy Readable Label Depth(ERLD) value is another important parameter to consider when inserting an ELI/EL. The ERLD is defined as the number of labels a router can both read in an MPLS packet received on its incoming interface(s) and use in its load-balancing function. An ELI/EL pair must be within the ERLD of the LSR in order for the LSR to use the EL during load-balancing. It's necessary to get the ERLD of the nodes along the SR path to achieve efficient load-balancing.¶

An implementation MAY try to evaluate if load-balancing is really expected at a particular node based on the segment type of its label, which also influences the ELP of a segment list.¶

Other criteria includes maximizing number of LSRs that will load-balance, preference for a part of the path, and etc. Using which criteria and how to decide the ELP based on the criteria is a matter of implementation.¶

As shown in Figure 1, in the inter-domain scenario, a path from A to Z is required, a centralized controller performs the computation of the end-to-end path, along which traffic load-balancing is required.¶

 ....................   ....................    .....................
 .                  .   .                  .    .                   .
 .+---+       +---+ .   . +---+      +---+ .    .+---+      +----+  .
 .| A |-------| B |------ | C |------| X |-------| Y |------| Z  |  .
 .+---+       +---+ .   . +---+      +---+ .    .+---+      +----+  .
 .     domain 1     .   .      domain 2    .    .     domain 3      .
 ....................   ....................    .....................

When the headend node in the first domain can't get the information of the nodes/SIDs in other domains, e.g, the ERLD of each node or the type of the SID bounded to a node/link, it's difficult for the headend node to decide the ELP of the segment list for the path.¶

Performing the computation of the ELP by the controller is an alternate, since it's easier for the controller to get the required information along the segment list prescribed by itself.¶

For example, the ERLD value can be advertised via IS-IS[RFC9088] and OSPF[RFC9089] within the domain, in each domain, one or more nodes are configured with BGP-LS so the controller can get the ERLD value of all the nodes through BGP-LS[RFC9085]. The controller can acquire the MSD of the headend node or the Binding SID anchor node via BGP-LS[RFC8814] or PCEP[RFC8664].¶

Another benefit of utilizing the controller to calculate ELP is that if the criteria or calculation algorithm is changed, the corresponding modification only needs to be made on the controller instead of each headend node in the network.¶

When the controller performs the computation of the the ELP for a segment list, the considerations for the placement of ELI/ELs introduced in [RFC8662] are still applicable. How the controller computes the ELP is out of scope of the document.¶

After the ELP of an SR path is decided, the controller SHOULD inform the result to the headend node of the path, so the node knows where to insert the ELI/ELs when needed. Section 4 proposes the detailed extensions for BGP to carry this information.¶

4. BGP Extensions for ELP in SR Policy

As defined in [I-D.ietf-idr-segment-routing-te-policy], the SR Policy encoding structure is as follows:¶

      SR Policy SAFI NLRI: <Distinguisher, Policy-Color, Endpoint>
      Attributes:
         Tunnel Encaps Attribute (23)
            Tunnel Type: SR Policy
                Binding SID
                Preference
                Priority
                Policy Name
                Explicit NULL Label Policy (ENLP)
                Segment List
                    Weight
                    Segment
                    Segment
                    ...
                ...

This document defines a new ELP sub-TLV within Segment List sub-TLV. The ELP sub-TLV has the following format:¶

    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      |         RESERVED              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Where,¶

Type: TBD.¶

Length: Specifies the length of the value field (i.e., not including Type and Length fields) in terms of octets. The value MUST be 2.¶

RESERVED: 2 octet of reserved bits. SHOULD be unset on transmission and MUST be ignored on receipt.¶

The ELP sub-TLV, when present, indicates that the <ELI, EL> label pair SHOULD be inserted at this position. It MAY appear multiple times in the Segment List sub-TLV.¶

The new SR Policy encoding structure with Path Segmentg sub-TLV is expressed as below:¶

      SR Policy SAFI NLRI: <Distinguisher, Policy-Color, Endpoint>
      Attributes:
         Tunnel Encaps Attribute (23)
            Tunnel Type: SR Policy
                Binding SID
                Preference
                Priority
                Policy Name
                Explicit NULL Label Policy (ENLP)
                Segment List
                    Weight
                    Segment
                    Segment
                    ELP
                    Segment
                    ...
                    Segment
                    ELP
                    Segment
                    Segment
                    ...
                ...

5. Operation Considerations

The <ELI, EL> label pair insertion is indicated at the segment list level. The following example shows how a headend node operates after the ELP sub-TLV is introduced.¶

Node A receives an SR Policy NLRI with an Segment List sub-TLV from the controller. The Segment List sub-TLV contains multiple Segment sub-TLVs and ELP sub-TLVs, e.g, <S1, S2, S3,ELP, S4, S5, S6, ELP>, it indicates that if load-balancing is required, two <ELI, EL> pairs SHOULD be inserted into the label stack of the SR-TE forwarding entry, respectively after the Label for S3 and Label for S6.¶

The value of EL is supplemented by the ingress node according to load-balancing function of the appropriate keys extracted from a given packet. After inserting ELI/ELs, the label stack on the ingress node would be <S1, S2, S3, ELI, EL, S4, S5, S6, ELI, EL>.¶

If an SR policy segment list does not contain the ELP sub-TLV, the headend node MAY still insert ELI/ELs based on its own descretion, as the legacy behavior of ELI/EL insertion defined in [RFC8662], making it inconvenient for network operation and troubleshooting. So it is RECOMMENDED that at at least within the same SR policy, the behavior SHOULD be consistent, that is, either the headend node inserts the ELI/ELs based on the ELP sub-TLV received or it makes its own decision regardless of the existence of the ELP sub-TLV.¶

The Maximum SID Depth defines the maximum number of labels that a particular node can impose on a packet. When ELI/EL insertion is required, the number of segments and ELI/ELs to be inserted in the segment list SHOULD not exceed the MSD limit. In this case, depending on whether ELI/EL(s) are required to be inserted and whether the headend node has sufficient MSD, the segment list delivered by the controller to the headend MAY be different. And with the additional constraints on ELI/EL insertion, the number of valid paths may be reduced, in some cases there may be no available path. Whether the ELI/EL insertion should be considered when computing the SR policy MAY be based on the configuration or local policy on the controller, or some control plane mechanism between the headend and the controller MAY be used, the details are out of the scope of this document.¶

6. IANA Considerations

This document defines a new sub-TLV in the registry "SR Policy List Sub-TLVs" [I-D.ietf-idr-segment-routing-te-policy] to be assigned by IANA:¶

        Codepoint   Description                           Reference
        -------------------------------------------------------------
        TBD         ELP Sub-TLV                         This document

7. Security Considerations

Procedures and protocol extensions defined in this document do not introduce any new security considerations beyond those already listed in [RFC8662] and [I-D.ietf-idr-segment-routing-te-policy].¶

8. Acknowledgement

The authors would like to thank Ketan Talaulikar and Jie Dong for their helpful review and comments.¶

9. References