Network Working Group H. Chen
Internet-Draft China Telecom
Intended status: Standards Track Y. Gu
Expires: January 14, 2021 H. Wang
July 13, 2020

SRv6 SID Bypass Functions


This document introduces the SRv6 SID Bypass Functions to enhance reliability and prevent traffic loop in fast reroute(FRR) scenario.

Requirements Language

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.

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

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 January 14, 2021.

Copyright Notice

Copyright (c) 2020 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 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

In SRv6 EVPN VPWS all-active scenario, a router or switch (CE1) is dual-homed to enterprise site (PE1 and PE2). SRv6 EVPN VPWS service is run between enterprise sites (PE1, PE2, and CPE). When one PE fails, services can be rapidly switched to the other PE, minimizing the impact on services.

As shown in Figure 1, deploy fast reroute(FRR) service on PE1 and PE2. When the AC(attachment circuit) link on PE1 fails, PE1 receives downlink traffic and can bypass it to the PE2 device for forwarding. PE2 is also the same. If the AC side links on PE1 and PE2 fail together, a brief traffic loop between PE1 and PE2 occurs. The traffic loop will waste the forwarding resources of the equipment and cause performance pressure. The length of the traffic loop depends on the convergence of the control plane. That is, PE1 withdraws the per-EVI Ethernet A-D route advertised to PE2. The FRR backup path on PE2 is destroyed. PE2 does not send traffic to PE1. In order to solve the above problem, this document defines the SRv6 SID Bypass Functions that will be contained in the SRv6 SID Information Sub-TLV [I-D.ietf-bess-srv6-services], and to be advertised with per-EVI Ethernet A-D routes.

                                | CE2 |
                                |EVPL1| Local/Remote 
             -------------------| PE3 | Ethernet Tag ID->100/200
                |               +-----+
                |               /      \
                |              /        \
           SRv6 EVPN ELINE    /          \
                |            /            \
                |           /              \
                |      +-----+SRv6 Bypass  +-----+
             --------- | PE1 | Tunnel      | PE2 |
L/R Ethernet           |EVPL1|-------------|EVPL1| L/R Ethernet 
Tag ID->200/100        +-----+             +-----+ Tag ID->200/100
                             \             /
                              \           /
                              ESI1      ESI1
                                \ Trunk /
                                | \   / |
                                 | CE1 |

Figure 1: Basic Networking of the SRv6 EVPN VPWS All-Active Scenario

2. SRv6 SID Bypass Functions

2.1. End.DX2L

The "Endpoint with decapsulation and Layer-2 cross-connect to an local outgoing L2 interface (OIF) only" (End.DX2L for short) is a variant of the endpoint behavior. Allocation is expected from IANA for an End.DX2L function codepoint from the "SRv6 Endpoint Behaviors" sub-registry.

One of the applications of the End.DX2L behavior is the L2VPN/EVPN VPWS [RFC7432][RFC8214] use-case.

The End.DX2L SID MUST be the last segment in a SR Policy, and it is associated with one outgoing interface I.

When N receives a packet destined to S and S is a local End.DX2L SID, N does:

S01. When an SRH is processed {
S02.   If (Segments Left != 0) {
S03.      Send an ICMP Parameter Problem to the Source Address,
             Code 0 (Erroneous header field encountered),
             Pointer set to the Segments Left field.
             Interrupt packet processing and discard the packet.
S04.   }
S05.   Proceed to process the next header in the packet
S06. }

When processing the Upper-layer header of a packet matching a FIB entry locally instantiated as an SRv6 End.DX2L SID, the following is done:

S01. If (Upper-Layer Header type != 143) {
S02.    Process as per Section 4.1.1 of [I-D.ietf-spring-srv6-network-programming]
S03. }
S04. Remove the outer IPv6 Header with all its extension headers and forward the Ethernet frame to the OIF I.
S05. If (OIF I is down) {
S06.    Interrupt packet processing and discard the packet.
S07. }

3. Control Plane Processing

As shown in Figure 1:

4. Data Plane Processing

This section will describe the processes of the downlink Layer 2 packet forwarding cases.

As shown in Figure 1:

5. IANA Considerations


6. Security Considerations


7. Contributors

   Shunwan Zhuang
   Huawei Technologies


   Chongyang Hu
   Huawei Technologies
   Bingshe Liu
   Huawei Technologies


The following individuals gave significant contributions to this document:

8. Acknowledgements

The authors would like to thank xxx for the discussion and review of this document.

9. References

9.1. Normative References

[I-D.ietf-bess-srv6-services] Dawra, G., Filsfils, C., Raszuk, R., Decraene, B., Zhuang, S. and J. Rabadan, "SRv6 BGP based Overlay services", Internet-Draft draft-ietf-bess-srv6-services-03, July 2020.
[I-D.ietf-spring-srv6-network-programming] Filsfils, C., Camarillo, P., Leddy, J., Voyer, D., Matsushima, S. and Z. Li, "SRv6 Network Programming", Internet-Draft draft-ietf-spring-srv6-network-programming-16, June 2020.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997.
[RFC7432] Sajassi, A., Aggarwal, R., Bitar, N., Isaac, A., Uttaro, J., Drake, J. and W. Henderickx, "BGP MPLS-Based Ethernet VPN", RFC 7432, DOI 10.17487/RFC7432, February 2015.
[RFC8214] Boutros, S., Sajassi, A., Salam, S., Drake, J. and J. Rabadan, "Virtual Private Wire Service Support in Ethernet VPN", RFC 8214, DOI 10.17487/RFC8214, August 2017.

9.2. Informative References

[RFC4271] Rekhter, Y., Li, T. and S. Hares, "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, DOI 10.17487/RFC4271, January 2006.
[RFC8200] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", STD 86, RFC 8200, DOI 10.17487/RFC8200, July 2017.

Authors' Addresses

Huanan Chen China Telecom 109, West Zhongshan Road, Tianhe District Guangzhou, 510000 China EMail:
Yunan Gu Huawei Huawei Bld., No.156 Beiqing Rd. Beijing, 100095 China EMail:
Haibo Wang Huawei Huawei Bld., No.156 Beiqing Rd. Beijing, 100095 China EMail: