Skip to main content

BGP Extensions for Services in SRv6 and MPLS Coexisting Network
draft-ls-bess-srv6-mpls-coexisting-vpn-00

The information below is for an old version of the document.
Document Type
This is an older version of an Internet-Draft whose latest revision state is "Expired".
Authors Yao Liu , Bing Song
Last updated 2020-09-06
RFC stream (None)
Formats
Stream Stream state (No stream defined)
Consensus boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-ls-bess-srv6-mpls-coexisting-vpn-00
BGP Working Group                                               Yao. Liu
Internet-Draft                                                Bing. Song
Intended status: Standards Track                         ZTE Corporation
Expires: March 10, 2021                                September 6, 2020

    BGP Extensions for Services in SRv6 and MPLS Coexisting Network
               draft-ls-bess-srv6-mpls-coexisting-vpn-00

Abstract

   This document proposes a method to achieve VPN/EVPN in a network
   which supports both SRv6 and MPLS in a given domain, including
   extensions of BGP.

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 March 10, 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
   (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.

Liu & Song               Expires March 10, 2021                 [Page 1]
Internet-Draft           IGP for Service Segment          September 2020

Table of Contents

   1.  Introduction  . . . . . . . . . . . . . . . . . . . . . . . .   2
   2.  the Co-existence Scenario . . . . . . . . . . . . . . . . . .   2
   3.  BGP extensions  . . . . . . . . . . . . . . . . . . . . . . .   4
   4.  Illustration  . . . . . . . . . . . . . . . . . . . . . . . .   5
   5.  Security Considerations . . . . . . . . . . . . . . . . . . .   5
   6.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .   6
   7.  References  . . . . . . . . . . . . . . . . . . . . . . . . .   6
     7.1.  Normative References  . . . . . . . . . . . . . . . . . .   6
     7.2.  Informative References  . . . . . . . . . . . . . . . . .   6
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .   6

1.  Introduction

   The incremental deployment of SRv6 into existing networks require
   SRv6 to interwork and co-exist with SR-MPLS/MPLS.

   Currently [I-D.agrawal-spring-srv6-mpls-interworking] and
   [I-D.pzm-bess-spring-interdomain-vpn] discuss about the SRv6 and MPLS
   interworking method.

   In the progress of upgrading some network, some of the legacy devices
   that support only MPLS/SR-MPLS will coexist with the new devices
   capable SRv6 for a long time.  The co-existence scenario also need to
   be further addressed.

   This document proposes a method to achieve VPN/EVPN in a network
   which supports both SRv6 and MPLS in a given domain, including
   extensions of BGP.

2.  the Co-existence Scenario

                      +----R1----R2----+
                      |                | +----+CE21
                      |                | |
            CE1+----+PE1              PE2+
                      |                | |
                      |                | +----+CE22
                      +----R3----R4----+

                      Figure 1: Reference Topology 1

Liu & Song               Expires March 10, 2021                 [Page 2]
Internet-Draft           IGP for Service Segment          September 2020

                      +----R1----R2----+
                      |                |
            CE1+----+PE1               |
                                      PE2+----+CE2
            CE3+----+PE3               |
                      |                |
                      +----R3----R4----+

                      Figure 2: Reference Topology 2

   As shown in Figure 1 and Figure 2, R3 and R4 are capable of SRv6, R1
   and R2 are legacy devices which only support SR-MPLS/MPLS.

   In Figure 1, PE2 is connected to different services with different
   SLA requirements.Different SLA requirements may correspond to
   different forwarding paths, these paths may be SRv6 capable, or may
   pass through the devices that only support SR-MPLS/MPLS.

   In Figure 2, to reach for the same service, the underlay path from
   PE1 to PE2 support SRv6 forwarding, while the path from PE3 to PE2
   passes through the devices that only support SR-MPLS/MPLS.

   Based on the above scenarios, this document proposes a method:

   The egress PE allocates MPLS label(s) and SRv6 SID(s) for the same
   service and signals them with the BGP overlay service route.

   After receiving the BGP advertisement, the ingress PE should add the
   prefix with the MPLS label and SRv6 SID information to the RIB.

   When encapsulating packets, the ingress PE selects whether to use
   MPLS label or SRv6 SID according to the attribute of the underlay
   path.

   If there is a route reflector in the network, it must support the
   extended BGP message too.

   Currently, the MPLS-based VPN/EVPN service information is encoded in
   the MPLS Label field of the corresponding NLRI, and the SRv6-based
   VPN/EVPN service information is encoded as SRv6 service SIDs such as
   END.DT*/END.DX*/END.DT2 with BGP Prefix-SID attribute [RFC8669]
   extended to carry SRv6 service SIDs information
   [I-D.ietf-bess-srv6-services]

   But how does the egress PE indicate in the BGP advertisement that a
   service supports both MPLS and SRv6 identification is not clearly
   described.

Liu & Song               Expires March 10, 2021                 [Page 3]
Internet-Draft           IGP for Service Segment          September 2020

3.  BGP extensions

   For the convenience of understanding and reading, the two methods of
   notifying SRv6 SID in [I-D.ietf-bess-srv6-services] are described
   briefly below.

   In the first method, SRv6 Service SIDs are encoded as a whole in the
   SRv6 Services TLVs.  In this case, the MPLS Label field(s) of the
   corresponding NLRI is set to Implicit NULL.

   The second method is called Transposition Scheme of encoding, where
   the SRv6 SID Structure Sub-Sub-TLV describes the sizes of the parts
   of the SRv6 SID and to also indicate offset of variable part along
   with its length in SRv6 SID value.  The function and/or the argument
   part of the SRv6 SID is encoded in the MPLS Label field of the NLRI
   and the SID value in the SRv6 Services TLV carries only the locator
   part with the SRv6 SID Structure Sub-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
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |   TLV Type    |         TLV Length            |M| RESERVED    |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       //  SRv6 Service Sub-TLVs                                      //
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                   Figure 3: Extended SRv6 Service TLVs

   This document introduces a M-flag in the RESERVED field of SRv6
   Services TLVs as shown in figure 3, when set, it indicates that this
   service supports both MPLS label and SRv6 service SID identification.

   If the advertisement message carries multiple SRv6 Service TLVs at
   the same time, for example, in the EVPN scenario, the M-flag of the
   these TLVs must be set to the same.  If not, the advertisement MUST
   be discarded.

   The MPLS-based VPN/EVPN service information is always encoded in the
   MPLS Label field of the NLRI.

   If the Transposition Scheme of encoding is needed, the egress PE MUST
   allocate SRv6 service SIDs with the function and/or the argument part
   same as the MPLS VPN label.

Liu & Song               Expires March 10, 2021                 [Page 4]
Internet-Draft           IGP for Service Segment          September 2020

   Otherwise, SRv6 SIDs and MPLS labels can be of independent values,
   and SRv6 Service SIDs are encoded as a whole in the SRv6 Services
   TLVs.

   The allocation of SRv6 SIDs and MPLS labels for VPN/EVPN on egress
   PEs is an implementation thing, and it is outside the scope of this
   document.

   More processing details will be further discussed.

4.  Illustration

   The reference topology is show in Figure 2.  PEs support both SRv6
   and SR-MPLS capabilities.

   Take IPv4 VPN as an example, PE2 assigns an MPLS label vpn2 and an
   SRv6 service SID(eg, END.DX4) sid2 for CE2, and the function part of
   the SID is vpn2.

   Label field of IPv4-VPN NLRI is encoded as specified in [RFC8277]
   with the Label Value set to vpn2.

   If Transposition Scheme of encoding is used, the locator part of the
   SRv6 Service SID is encoded in the SRv6 L3 Service TLV with the
   M-flag set to 1.

   PE1 and PE3 learn through M-flag that CE2 has both MPLS and SRv6
   identification, and obtain the corresponding MPLS label and SRv6 SID
   carried in the BGP update messages.

   When a service prefix is received on PE1, by looking at the local
   forwarding table, PE1 finds that the service is related to an MPLS
   label and an SRv6 SID, and the corresponding path is a segment list
   consisting of SR-MPLS SIDs , such as <Label 1, Label 2>.  PE1 then
   encapsulates the payload packet with an MPLS label stack <Label 1,
   Label 2, vpn2>.

   Similarly, PE3 finds out that the underlay path is based on SRv6 such
   as <SID3, SID4>, then it encapsulates the payload packet in an outer
   IPv6 header with the segment list <SID3, SID4, sid2>.

5.  Security Considerations

   TBD

Liu & Song               Expires March 10, 2021                 [Page 5]
Internet-Draft           IGP for Service Segment          September 2020

6.  IANA Considerations

   TBD

7.  References

7.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",
              draft-ietf-bess-srv6-services-04 (work in progress), July
              2020.

   [RFC8277]  Rosen, E., "Using BGP to Bind MPLS Labels to Address
              Prefixes", RFC 8277, DOI 10.17487/RFC8277, October 2017,
              <https://www.rfc-editor.org/info/rfc8277>.

   [RFC8669]  Previdi, S., Filsfils, C., Lindem, A., Ed., Sreekantiah,
              A., and H. Gredler, "Segment Routing Prefix Segment
              Identifier Extensions for BGP", RFC 8669,
              DOI 10.17487/RFC8669, December 2019,
              <https://www.rfc-editor.org/info/rfc8669>.

7.2.  Informative References

   [I-D.agrawal-spring-srv6-mpls-interworking]
              Agrawal, S., Ali, Z., Filsfils, C., Voyer, D., and Z. Li,
              "SRv6 and MPLS interworking", draft-agrawal-spring-srv6-
              mpls-interworking-03 (work in progress), August 2020.

   [I-D.pzm-bess-spring-interdomain-vpn]
              Zhang, Z., Peng, S., Mirsky, G., and Y. Wang, "SRv6 and
              MPLS interworking for VPN service", draft-pzm-bess-spring-
              interdomain-vpn-02 (work in progress), August 2020.

Authors' Addresses

   Liu Yao
   ZTE Corporation

   Email: liu.yao71@zte.com.cn

   Song Bing
   ZTE Corporation

   Email: song.bing@zte.com.cn

Liu & Song               Expires March 10, 2021                 [Page 6]