Compressed SRv6 SID List Analysis
draft-srcompdt-spring-compression-analysis-00-01

Abstract

Several mechanisms have been proposed to compress the SRv6 SID list. This document analyzes each mechanism with regard to the requirements stated in the companion requirements document.

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."

This Internet-Draft will expire on August 15, 2021.

Copyright Notice

Copyright (c) 2021 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 (https://trustee.ietf.org/license-info) 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 Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.

Table of Contents

• 1. Introduction
• 2. SRv6 Compression Requirements
• 2.1. Encapsulation Header Size
• 2.1.1. Reference Scenario 1
• 2.1.2. Reference Scenario Set 1-30
• 2.2. Forwarding Efficiency
• 2.2.1. Headers Parsed (PRS)
• 2.2.2. Lookups Performed (LKU)
• 2.3. State Efficiency
• 3. SRv6 Specific Requirements
• 3.1. SRv6 Based
• 3.2. Functional Requirements
• 3.2.1. SRv6 Functionality
• 3.2.2. Heterogeneous SID Lists
• 3.2.3. SID List Length
• 3.2.4. SID Summarization
• 3.3. Operational Requirements
• 3.3.1. Lossless Compression
• 3.4. Scalability Requirements
• 4. Protocol Design Requirements
• 4.1. SRv6 Base Coexistance
• 5. Security Requirements
• 5.1. Security Mechanismns
• 5.2. SR Domain Protection
• 6. Conclusions
• 7. Normative References
• Authors' Addresses

1. Introduction

The following mechanisms are proposed to compress the SRv6 SID list:

• CSID - [I-D.filsfilscheng-spring-srv6-srh-comp-sl-enc] - Describes two new SRv6 SIDs, a combination of SIDs from [I-D.filsfils-spring-net-pgm-extension-srv6-usid] and [I-D.cl-spring-generalized-srv6-for-cmpr]
• CRH - [I-D.bonica-6man-comp-rtg-hdr] - Requires two new routing header types and a label mapping technique.
• VSID - [I-D.decraene-spring-srv6-vlsid] - Defines a set of SID behaviors to access smaller SIDs within the SR header.
• UID - [I-D.mirsky-6man-unified-id-sr] - Extends the SRH to carry MPLS labels or IPv4 addresses.

This document analyzes each mechanism against the requirements stated in [I-D.srcompdt-spring-compression-requirement]. Each section of this document corresponds to a similarly named section in [I-D.srcompdt-spring-compression-requirement]. Each section reiterates corresponding requirements and analyzes each proposal against the those requirements.

2. SRv6 Compression Requirements

An SR domain consisting of 3 sub-domains is shown to illustrate the scenarios associated with encapsulation header size, forwarding efficiency and state efficiency

        + * * * * * * * * * * * * * * * * * * * * * * * * * * +
        *                                                     *
        * - - - - - - - - + - - - - - - - - + - - - - - - - - *
        *                 |                 |                 *
        *   [M1_0]      [B5]  [C_0]       [B7]  [M2_0]        *
[H1]--[E3]                |                 |                [E4]---[H2]
        *        [M1_i] [B6]        [C_j] [B8]       [M2_k]   *
        *                 |                 |                 *
        *     Metro 1     |      Core       |     Metro 2     *
        *- - - - - - - - - - - - - - - - - - - - - - - - - - -*
        *                                                     *
        *                      SR domain                      *
        + * * * * * * * * * * * * * * * * * * * * * * * * * * +

• H1 and H2 are hosts outside the SR domain
• E3 and E4 are SR domain edge routers
• Metro 1, Core and Metro 2 are sub-domains with independent IGP instances
• B5 and B6 are border routers between the Metro 1 and Core
• B7 and B8 are border routers between the Metro 2 and Core
• M1_1..M1_i are routers in Metro 1
• C_1..C_j are routers in Core
• M2_1..M2_k are routers in Metro 2

2.1. Encapsulation Header Size

The compression proposal MUST reduce the size of the SRv6 encapsulation header.

Encapsulation header size is evaluated against multiple reference scenarios.

2.1.1. Reference Scenario 1

A service provider offers a VPN service with underlay optimization in the SR domain.

• Hosts H1 and H2 are located in two different sites of a VPN customer.
• Edge nodes E3 and E4 encapsulate/decapsulate traffic between H1 and H2 to provide the VPN service.
• A VPN SID is added to the encapsulation between E3 and E4.
• An SR policy is applied consisting of 2 transport SIDs per domain.
• The resulting segment list is described as 3D(2T).V (3 domains, 2 transport SIDs per domain, one VPN SID)
  • It contains at least 7 SIDs,
  • some proposals may require more SIDs be added to:
    • traverse domains
    • reach the egress node
• This reference scenario is considered for different sub-domain sizes (i.e. number of routers in the sub-domain)
  • Proposals offering 16 or 32-bit segment sizes are evaluated.
  • A 48-bit SRv6 block size is used.

This scenario results in E and ES for 16-bit and 32-bit variants of each proposal.

Conclusion: In this scenario CSID and CRH performs better than other proposals

2.1.2. Reference Scenario Set 1-30

Twenty nine additional scenarios are generated using the same parameters as scenario 1 (D,T,V) by:

• Varying the number of sub-domains in which traffic engineering is required (1 to 3).
• Varying the number of transport SID per sub-domain (0 to 15), such that a scenario's segment list does not exceeding 16 SIDs (including the VPN SID).

This results in a total of thirty segment lists, six for 3D(0..5T).V, eight for 2D(0..7T).V, and sixteen for 1D(0..15T).V

The average encapsulation savings across all scenarios, for 16-bit and 32-bit variants of each proposal is documented in the following tables.

Conclusion: In this scenario set, CSID and VSID perform better than other proposals.

2.2. Forwarding Efficiency

The compression proposal SHOULD minimize the number of required hardware resources accessed to process a segment.

2.2.1. Headers Parsed (PRS)

Forwarding efficiency is calculated against reference scenarios one to thirty. This section records and summarizes differences in header parsing for different SID types.

• Segment lists may contain transport, adjacency, service, binding or VPN segments.
• When processing a segment, all proposals process the IPv6 header and routing header, if present.
• CRH always parse the outer IPv6 header and CRH to process a segment.
• CSID and VSID use [RFC8754] reduced behavior when a segment list can be expressed as a single destination address to omit the SRH and avoid processing it.
  • For the 16-bit variant of CSID in the scenarios, only a single header need be parsed for segment lists consisting of fewer than 4 transport SIDs.
  • For the 32-bit variants of CSID and VSID, global VPN SIDs may be used to encode the VPN SID in a single segment.

Conclusion: CSID and VSID require less header parsing.

2.2.2. Lookups Performed (LKU)

Some proposals require a different number of lookups per packet, depending on the SID type and segment list.

A strict TE path is considered with a 1D(1..15T).V segment list, where each transport segment is an adjacency segment.

When lookups are performed at each adjacency segment endpoint:

• CSID and VSID require an LPM lookup for the destination address.
• CRH requires an LPM lookup for the destination address, and an EM lookup for the next label in the CRH to retrieve the next segment address.

Conclusion: CSID and VSID require fewer lookups for strict TE paths.

A loose TE path consists of a combination of prefix and adjacency segments

• At prefix segments, where the next segment is a prefix segment
  • CSID and VSID require an LPM for the IPv6 DA and one for the next prefix segment.
  • CRH require an LPM for the IPv6 DA and one EM for the next label.
• At adjacency segments, preceded by a prefix segment
  • CSID 16-bit requires an LPM for the IPv6 DA containing the combined prefix and adjacency segment.
  • VSID 16-bit requires an LPM for the IPv6 DA containing the prefix segment and a second LPM for the local adjacency segment.
  • CRH 16-bit and 32-bit require an LPM for the IPv6 DA and an EM for the next adjacency segment in all scenarios.
• A note on EM vs LPM
  • Implementation of a lookup as an LPM or EM is a local decision.
  • The above designation of lookups as EM or LPM may not match a specific implementation.

Conclusion: CSID requires fewer lookups for loose TE paths.

2.3. State Efficiency

The compression proposal SHOULD minimize the amount of additional forwarding state stored at a node.

State efficiency is analyzed in a single sub-domain of the SR domain, where three parameters are considered:

• N: the number of nodes in the sub-domain
• I: the number of IGP algorithms [I-D.ietf-lsr-flex-algo] configured
• A: the number of local adjacency SIDs

For a core sub-domain with 1000 nodes, two IGP algorithms, and 100 adjacencies per node:

• N=1000, I=2, A=100

CSID and VSID require:

• One FIB entry per node (N=1000) for prefix segments.
  • One FIB entry per node for each additional IGP algorithm
• One FIB entry per local adjacency SID (A=100) **Note1

CRH requires:

• One CFIB entry per node (N=1000) for prefix segments in the native IGP algorithm
  • One CFIB entry per node (N=1000) for each IGP algorithm greater than 1 (I=2)
• One CFIB entry per local adjacency segment (A=100) **Note1
• One FIB entry per node (N=1000) per additional IGP algorithm
  • IP Flex Algo requires
    • a loopback address per algorithm per node
    • CRH assigns a CFIB entry per prefix

** Note1: there may be additional adjacency SIDs for protected, unprotected, and per algorithm adjacencies but these are equal among all proposals so are omitted.

Conclusion: CSID and VSID perform equally, CRH requires additional state.

3. SRv6 Specific Requirements

3.1. SRv6 Based

A solution to compress SRv6 SID Lists SHOULD be based on the SRv6 architecture, control plane and data plane. The compression solution MAY be based on a different data plane and control plane, provided that it derives sufficient benefit.

This section records the use of SRv6 standards for compression.

Conclusion: CSID is compliant with all SRv6 specifications, requiring no updates.

3.2. Functional Requirements

3.2.1. SRv6 Functionality

A solution to compress an SRv6 SID list MUST support the functionality of SRv6. This requirement ensures no SRv6 functionality is lost. It is particularly important to understand how a proposal, as evaluated in section "SRv6 Based", provides this functionality.

Functional requirements and the drafts defining how a proposal provides the functionality are documented in the table below.

Conclusion: CSID satisfies all functional requirements using the existing SRv6 standards or working group drafts.

3.2.2. Heterogeneous SID Lists

The compression proposal SHOULD support a combination of compressed and non-compressed segments in a single path. As an example, a solution may satisfy this requirement without being SRv6 based by using a binding SID to impose an additional SRv6 header (IPv6 header plus optional SRH) with non-compressed SID.

Note: Binding SIDs add additional network state and encapsulation overhead.

Conclusion: CSID provides heterogeneous SID list support natively, the others require binding SIDs.

3.2.3. SID List Length

The compression proposal MUST be able to represent SR paths that contain up to 16 segments.

Conclusion: All proposals support segment lists of at least 16 segments.

3.2.4. SID Summarization

The solution MUST be compatible with segment summarization.

In inter sub-domain deployments with summarization:

• Any node can reach any other node in another sub-domain via a prefix segment.
• Prefixes are summarized for advertisement between domains.

Without summarization, border router SIDs must be leaked:

• An additional global prefix segment is required for each domain border to be traversed.

SRv6 utilizes IPv6 summarization for SIDs, SRv6 based proposals can support the summarization of SIDs.

Conclusion: CSID and VSID both support summarization.

3.3. Operational Requirements

3.3.1. Lossless Compression

A path traversed using a compressed SID list MUST always be the same as the path traversed using the uncompressed SID list if no compression was applied.

Conclusion: CSID provides lossless compression for all deployments.

3.4. Scalability Requirements

The compression proposal MUST be capable of representing 65000 adjacency segments per node.

The compression proposal MUST be capable of representing 1 million prefix segments per SID numbering space.

The compression proposal MUST be capable of representing 1 million services per node.

Conclusion: All proposals support 16-bit and 32-bit variants to support large scale deployments

4. Protocol Design Requirements

4.1. SRv6 Base Coexistance

The compression proposal MUST support deployment in existing SRv6 networks.

Conclusion: All proposals can be deployed simultaneously with the SRv6 base solution.

5. Security Requirements

5.1. Security Mechanismns

The compression solution SHOULD be able to address security issues that it introduces, using existing security mechanisms.

Conclusion: All proposals resolve known security issues they are susceptible to.

5.2. SR Domain Protection

A compression solution must not require nodes outside the SR domain to know SID values within the SR domain, and it must provide the ability to block nodes outside an SR domain from accessing SIDS.

Conclusion: All proposals describe how SIDs within the SR domain are protected.

6. Conclusions

Encapsulation Header Size

• Scenario 1: In this scenario CSID and CRH performs better than other proposals.
• Scenario set 1-30: In this scenario set, CSID and VSID perform better than other proposals.

Forwarding Efficiency

• Headers Parsed: CSID and VSID require less header parsing.
• Lookups Performed: CSID and VSID require fewer lookups for strict TE paths.
• Lookups Performed: CSID requires fewer lookups for loose TE paths.

State Efficiency

• CSID and VSID perform equally, CRH requires additional state.

SRv6 Based

• CSID is SRv6 compliant with all SRv6 specifications, requiring no updates.

SRv6 Functionality

• CSID satisfies all functional requirements using the existing SRv6 standards or working group drafts.

Heterogeneous SID lists

• CSID provides heterogeneous SID list support natively, the others require binding SIDs.

SID List Length

• All proposals support segment lists of at least 16 segments

SID Summarization

• CSID and VSID both support summarization.

Operational Requirements

• CSID provides lossless compression for all deployments.

Protocol Design Requirements

• All proposals can be deployed simultaneously with the SRv6 base solution.

Scalability Requirements

• All proposals support 16-bit and 32-bit variants to support large scale deployments

Protocol Design Requirements

• All proposals can be deployed simultaneously with the SRv6 base solution.

Security Requirements

• All proposals resolve known security issues they are susceptible to.
• All proposals describe how SIDs within the SR domain are protected.

7. Normative References

Authors' Addresses