[Search] [txt|pdfized|bibtex] [Tracker] [Email] [Nits]
Versions: 00                                                            
BESS                                                         T. Murakami
Internet-Draft                                                  K. Patel
Intended status: Standards Track                                  Arrcus
Expires: September 8, 2022                                 S. Matsushima
                                                                SoftBank
                                                                J. Zhang
                                                        Juniper Networks
                                                              S. Agrawal
                                                           Cisco Systems
                                                           March 7, 2022


          BGP Extensions for the Mobile User Plane (MUP) SAFI
                    draft-mpmz-bess-mup-safi-00.txt

Abstract

   This document defines a new SAFI known as a BGP Mobile User Plane
   (BGP-MUP) SAFI to support MUP Extensions and a extended community for
   BGP.  This document also provides BGP signaling and procedures for
   the new SAFI to convert mobile session information into appropriate
   IP forwarding information.  These extensions can be used by operators
   between MUP PE, MUP GW and MUP Controller for integrating mobile user
   plane into BGP MUP network using the IP based routing.

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 September 8, 2022.

Copyright Notice

   Copyright (c) 2022 IETF Trust and the persons identified as the
   document authors.  All rights reserved.





Murakami, et al.        Expires September 8, 2022               [Page 1]


Internet-Draft                BGP MUP SAFI                    March 2022


   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
     1.1.  Requirements Notation . . . . . . . . . . . . . . . . . .   3
   2.  Terminology . . . . . . . . . . . . . . . . . . . . . . . . .   3
   3.  BGP MUP Extensions  . . . . . . . . . . . . . . . . . . . . .   4
     3.1.  BGP MUP SAFI  . . . . . . . . . . . . . . . . . . . . . .   4
       3.1.1.  BGP Interwork Segment Discovery route . . . . . . . .   5
       3.1.2.  BGP Direct Segment Discovery route  . . . . . . . . .   6
       3.1.3.  BGP Type 1 Session Transformed (ST) Route . . . . . .   6
       3.1.4.  BGP Type 2 Session Transformed (ST) Route . . . . . .   8
     3.2.  BGP MUP Extended Community  . . . . . . . . . . . . . . .   9
     3.3.  Operation . . . . . . . . . . . . . . . . . . . . . . . .  10
       3.3.1.  Generation of the Interwork Segment Discovery route .  10
       3.3.2.  Withdrawal of the Interwork Segment Discovery route .  10
       3.3.3.  Processing of the Interwork Segment Discovery routes   11
       3.3.4.  Generation of the Direct Segment Discovery route  . .  11
       3.3.5.  Withdrawal of the Direct Segment Discovery route  . .  12
       3.3.6.  Processing of the Direct Segment Discovery routes . .  12
       3.3.7.  Generation of the Type 1 ST Route . . . . . . . . . .  13
       3.3.8.  Withdrawing of the Type 1 ST Route  . . . . . . . . .  14
       3.3.9.  Processing of the Type 1 ST Route . . . . . . . . . .  14
       3.3.10. Generation of the Type 2 ST Route . . . . . . . . . .  15
       3.3.11. Withdrawing of the Type 2 ST Route  . . . . . . . . .  15
       3.3.12. Processing of the Type 2 ST Route . . . . . . . . . .  16
   4.  Security Considerations . . . . . . . . . . . . . . . . . . .  16
   5.  IANA Considerations . . . . . . . . . . . . . . . . . . . . .  17
   6.  Contributors  . . . . . . . . . . . . . . . . . . . . . . . .  17
   7.  References  . . . . . . . . . . . . . . . . . . . . . . . . .  18
     7.1.  Normative References  . . . . . . . . . . . . . . . . . .  18
     7.2.  Informative References  . . . . . . . . . . . . . . . . .  19
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  20

1.  Introduction

   [I-D.mhkk-dmm-srv6mup-architecture] defines the Segment Routing IPv6
   Mobile User Plane (SRv6 MUP) architecture for Distributed Mobility
   Management.  As part of the architecture, the document defines a new



Murakami, et al.        Expires September 8, 2022               [Page 2]


Internet-Draft                BGP MUP SAFI                    March 2022


   SRv6 segment type called as a MUP Segment, new routing information
   that can carried within BGP, and 3 new network nodes; MUP PE, MUP GW
   and a MUP Controller.

   This document defines a new SAFI known as a BGP Mobile User Plane
   (BGP-MUP) SAFI to support MUP Extensions for BGP.  This draft also
   provides BGP signaling and procedures for the new SAFI to convert
   mobile session information into appropriate IP routing information.
   These extensions can be used by operators between the MUP PE, MUP GW
   and MUP Controller for integrating mobile user plane into BGP MUP
   network using the IP based routing.  These extensions also works with
   routing instances accomodationg two new wellknown segment types known
   as Interwork and Direct [I-D.mhkk-dmm-srv6mup-architecture].
   Finally, the BGP encoding and procedures defined in this document
   that uses SRv6 as the forwarding fabric follows the SRv6 MUP
   architecture defined in [I-D.mhkk-dmm-srv6mup-architecture].  The BGP
   extensions to build networks that use forwarding mechanisms other
   than SRv6 (SRv6 MUP) are outside the scope of this document.

1.1.  Requirements Notation

   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 [RFC2119] [RFC8174] when, and only when, they appear in all
   capitals, as shown here.

2.  Terminology

   MUP: Mobile User Plane

   MUP Segment: Representation of mobile user plane segment

   MUP PE: Provider Edge node in a MUP network

   MUP GW: Gateway node to interwork with another mobile user plane
   networks

   MUP Controller: Controller node for a MUP network

   UE: User Equipment, as per [TS.23501]

   gNodeB: 3GPP-compliant implementation of 5G-NR base station, as per
   [TS.23501]

   UPF: 3GPP-compliant implementation of User Plane Function, as per
   [TS.23501]




Murakami, et al.        Expires September 8, 2022               [Page 3]


Internet-Draft                BGP MUP SAFI                    March 2022


   TEID: Tunnel Endpoint Identifier, as per [TS.29281]

3.  BGP MUP Extensions

3.1.  BGP MUP SAFI

   This draft defines a new BGP SAFI known as a BGP-MUP SAFI.  The value
   of this SAFI is to be assigned by IANA from the Subsequent Address
   Family Identifiers (SAFI) registry.

   This document also defines a new BGP NLRI known as the BGP-MUP NLRI.
   The following is the format of the BGP-MUP NLRI:

         +-----------------------------------+
         |    Architecture Type (1 octet)    |
         +-----------------------------------+
         |       Route Type (2 octets)       |
         +-----------------------------------+
         |         Length (1 octet)          |
         +-----------------------------------+
         |  Route Type specific (variable)   |
         +-----------------------------------+


   The Architecture Type field defines the encoding of the rest of BGP-
   MUP NLRI for a given Mobile User Plane architecture.  This draft
   defines the following architecture type for BGP-MUP NLRI:

           + 1 - 3gpp-5g;

   The Route Type field defines the encoding of the rest of BGP-MUP NLRI
   (Route Type specific BGP-MUP NLRI) for a given architecture type.

   The Length field indicates the length in octets of the Route Type
   specific field of the BGP-MUP NLRI.

   This document defines the following Route Types for BGP-MUP NLRI.

           + 1 - Interwork Segment Discovery route;
           + 2 - Direct Segment Discovery route;
           + 3 - Type 1 Session Transformed (ST) route;
           + 4 - Type 2 Session Transformed (ST) route;

   These Route Types are applicable for the 3gpp-5G architecture type as
   per [I-D.mhkk-dmm-srv6mup-architecture].  Other new architectures can
   share them if it is applicable as well.





Murakami, et al.        Expires September 8, 2022               [Page 4]


Internet-Draft                BGP MUP SAFI                    March 2022


   The BGP-MUP NLRI is carried in BGP [RFC4271] using BGP Multiprotocol
   Extensions [RFC4760] with an Address Family Identifier (AFI) of 1 or
   2 and a Subsequent AFI (SAFI) of BGP-MUP.  The NLRI field in the
   MP_REACH_NLRI/MP_UNREACH_NLRI attribute contains the BGP-MUP NLRI
   (encoded as specified above).  The value of the AFI field in the
   MP_REACH_NLRI/MP_UNREACH_NLRI attribute that carries the BGP-MUP NLRI
   determines whether the addresses carried in the routes are IPv4 or
   IPv6 addresses (AFI 1 indicates IPv4 addresses, AFI 2 indicates IPv6
   addresses).

   In order for two BGP speakers to exchange BGP-MUP NLRIs, they must
   use a BGP Capabilities Advertisement to ensure that they both are
   capable of properly processing such an NLRI.  This is done as
   specified in [RFC4760], by using capability code 1 (multiprotocol
   BGP) with an AFI of 1 or 2 and an SAFI of BGP-MUP.

   This document defines 4 Route Types for 3gpp-5G architecture type.
   Any other Route Types MUST be silently ignored upon a receipt if a
   BGP speaker supports only 3gpp-5G architecture type.  An
   implementation MAY log an error when such Route Types are ignored.
   An implementation MAY considered retrieving any discarded Route Types
   by simply resetting the session or issuing a Route-REFRESH message
   [RFC2918] if the Route Refresh Capability is successfully negotiated.

   The following sections describes the format of the Route Type
   specific BGP-MUP NLRI for various Route Types defined in this
   document.

3.1.1.  BGP Interwork Segment Discovery route

   A BGP Interwork Segment Discovery route Type specific BGP-MUP NLRI
   consist of the following:

         +-----------------------------------+
         |           RD  (8 octets)          |
         +-----------------------------------+
         |       Prefix Length (1 octet)     |
         +-----------------------------------+
         |        Prefix (variable)          |
         +-----------------------------------+

   The Interwork Segment Discovery route Type NLRI consist of RD which
   is encoded as described in [RFC4364].  It also has an prefix
   associated with Interwork segment connected locally.  For the purpose
   of BGP route key processing, only the RD, Prefix Length and Prefix
   are considered to be part of the prefix in the NLRI.





Murakami, et al.        Expires September 8, 2022               [Page 5]


Internet-Draft                BGP MUP SAFI                    March 2022


   In 3GPP 5G specific case, a prefix used for a N3 interface of the
   gNodeB connected locally MAY be used as this prefix.  The prefix
   length of one octet indicating length of the prefix.  If the AFI is
   IPv4, then the maximum value of the Prefix Length is 32 bits
   otherwise it is considered as a malformed NLRI.  If the AFI is IPv6,
   then the maximum value of of the Prefix length is 128 bits otherwise
   it is considered as a malformed NLRI.  A BGP speaker MUST handle such
   a malformed NLRI as a "Treat-as-withdraw" [RFC7606].  A BGP speaker
   MUST skip such NLRIs and continue processing of rest of the Update
   message.

3.1.2.  BGP Direct Segment Discovery route

   A BGP Direct Segment Discovery route Type specific BGP-MUP NLRI
   consist of the following:

         +-----------------------------------+
         |           RD  (8 octets)          |
         +-----------------------------------+
         |        Address (4 or 16 octets)   |
         +-----------------------------------+

   The Direct Segment Discovery route Type NLRI consist of RD which is
   encoded as described in [RFC4364].  It also has an Address of
   originating BGP speaker.  For the purpose of BGP route key
   processing, only the RD and Address are considered to be part of the
   prefix in the NLRI.

   If the AFI is IPv4 then the address length is 4 octets otherwise it
   is considered as a malformed NLRI.  If the AFI is IPv6 then the
   address length is 16 octets otherwise it is considered as a malformed
   NLRI.  A BGP speaker MUST handle such a malformed NLRI as a "Treat-
   as-withdraw" [RFC7606].  A BGP speaker MUST skip such NLRIs and
   continue processing of rest of the Update message.

3.1.3.  BGP Type 1 Session Transformed (ST) Route

   A BGP Type 1 ST Route Type specific BGP-MUP NLRI consist of the
   following:












Murakami, et al.        Expires September 8, 2022               [Page 6]


Internet-Draft                BGP MUP SAFI                    March 2022


         +-----------------------------------+
         |           RD  (8 octets)          |
         +-----------------------------------+
         |      Prefix Length (1 octet)      |
         +-----------------------------------+
         |         Prefix (variable)         |
         +-----------------------------------+
         | Architecture specific (variable)  |
         +-----------------------------------+

   The Type 1 ST Route Type NLRI consist of RD which is encoded as
   described in [RFC4364].  It also has Prefix length of one octet
   indicating length of the Prefix.  For the purpose of BGP route key
   processing, only the RD, Prefix Length and Prefix are considered to
   be part of the prefix in the NLRI.

   In 3GPP 5G specific case, Prefix is the prefix allocated to a UE.  If
   the AFI is IPv4, then the maximum value of the Prefix Length field is
   32.  If the AFI is IPv6, then the maximum value of the Prefix Length
   field is 128.  Any other length field is considered a a malformed
   NLRI.  A BGP speaker MUST handle such a malformed NLRI as a "Treat-
   as-withdraw" [RFC7606].  A BGP speaker MUST skip such NLRIs and
   continue processing of rest of the Update message.

   The architecture specific encoding values will follow after the
   variable length Prefix.

3.1.3.1.  3gpp-5g Specific BGP Type 1 ST Route

   A BGP 3gpp-5g Type 1 ST Route Type specific BGP-MUP NLRI consist of
   the following:

         +-----------------------------------+
         |          TEID (4 octets)          |
         +-----------------------------------+
         |          QFI (1 octet)            |
         +-----------------------------------+
         | Endpoint Address Length (1 octet) |
         +-----------------------------------+
         |    Endpoint Address (variable)    |
         +-----------------------------------+

   The TEID has a fixed length of 4 octets.  The TEID value of 0 is
   considered as an invalid and a malformed TEID.  A BGP speaker MUST
   handle such a malformed NLRI as a "Treat-as-withdraw" [RFC7606].  A
   BGP speaker MUST skip such NLRIs and continue processing of rest of
   the Update message.




Murakami, et al.        Expires September 8, 2022               [Page 7]


Internet-Draft                BGP MUP SAFI                    March 2022


   The QFI has a fixed length of 1 octet.

   The Endpoint Address Length has a fixed length of 1 octet.  Endpoint
   Address field contains of an IPv4 address, then the value of the
   Endpoint Address Length field is 32.  If the Endpoint Address field
   contains of an IPv6 Address, then the value of the Endpoint Address
   Length field is 128.  Any other value is considered as an invalid and
   a malformed Endpoint Address.  A BGP speaker MUST handle such a
   malformed NLRI as a "Treat-as-withdraw" [RFC7606].  A BGP speaker
   MUST skip such NLRIs and continue processing of rest of the Update
   message.

   The NLRI architecture field MUST be encoded as shown above if a BGP
   speaker receives 3gpp-5g specific BGP Type 1 ST route.  Otherwise the
   NLRI is considered as a malformed.  A BGP speaker MUST handle such a
   malformed NLRI as a "Treat-as-withdraw" [RFC7606].  A BGP speaker
   MUST skip such NLRIs and continue processing of rest of the Update
   message.

3.1.4.  BGP Type 2 Session Transformed (ST) Route

   A BGP Type 2 ST Route Type specific BGP-MUP NLRI consist of the
   following:

         +-----------------------------------+
         |           RD  (8 octets)          |
         +-----------------------------------+
         |      Endpoint Length (1 octet)    |
         +-----------------------------------+
         |      Endpoint Address (variable)  |
         +-----------------------------------+
         | Architecture specific Endpoint    |
         |         Identifier (variable)     |
         +-----------------------------------+

   The Type 2 ST Route Type NLRI consist of RD which is encoded as
   described in [RFC4364].  It also has Endpoint length of one octet
   indicating length of the Endpoint Address and the Architecture
   specific Endpoint Identifier as per
   [I-D.mhkk-dmm-srv6mup-architecture] defines aggregation capability by
   the Type2 ST Route.  If the AFI is IPv4 and the Endpoint Length is
   longer than 32 then the Architecture specific endpoint Identifier
   field exists with the IPv4 Endpoint Address.  If the AFI is IPv6 and
   the Endpoint Length is longer than 128 then the Architecture specific
   endpoint Identifier field exists with then the IPv6 Endpoint Address.
   For the purpose of BGP route key processing, only the RD, Endpoint
   Address and Architecture specific Endpoint Identifier are considered
   to be part of the prefix in the NLRI.



Murakami, et al.        Expires September 8, 2022               [Page 8]


Internet-Draft                BGP MUP SAFI                    March 2022


   In 3GPP 5G specific case, the Endpoint Address is a N3 interface
   address of the UPF.  If the AFI is IPv4, then the maximum Endpoint
   length is 64 otherwise it is considered as a malformed NLRI.  If the
   AFI is IPv6, then the maximum Endpoint length is 160 otherwise it is
   considered as a malformed NLRI.  A BGP speaker MUST handle such a
   malformed NLRI as a "Treat-as-withdraw" [RFC7606].  A BGP speaker
   MUST skip such NLRIs and continue processing of rest of the Update
   message.

   The architecture specific encoding values will follow after the
   variable length Prefix.

3.1.4.1.  3gpp-5g Specific BGP Type 2 ST Route

   A BGP 3gpp-5g Type 2 ST Route Type specific BGP-MUP NLRI consist of
   the following:

         +-----------------------------------+
         |          TEID (0-4 octets)        |
         +-----------------------------------+

   The maximum length of TEID is 4 octets.  The TEID value of 0 is
   considered as an invalid and a malformed TEID.  A BGP speaker MUST
   handle such a malformed NLRI as a "Treat-as-withdraw" [RFC7606].  A
   BGP speaker MUST skip such NLRIs and continue processing of rest of
   the Update message.

   The NLRI architecture field MUST be encoded as shown above if a BGP
   speaker receives 3gpp-5g specific BGP Type 2 ST route.  Otherwise the
   NLRI is considered as a malformed.  A BGP speaker MUST handle such a
   malformed NLRI as a "Treat-as-withdraw" [RFC7606].  A BGP speaker
   MUST skip such NLRIs and continue processing of rest of the Update
   message.

3.2.  BGP MUP Extended Community

   This document defines a new BGP Extended community known as BGP MUP
   Extended community as per [I-D.mhkk-dmm-srv6mup-architecture].

   This is a BGP MUP specific Extended Community, of an extended type,
   and is transitive across AS boundaries [RFC4360].

   The Type value of this Extended community is set to MUP type, to be
   assigned by IANA from BGP Extended community transtive registry.  The
   Sub-Type value is set to Direct-Type Segment Identifier type, to be
   assigned by IANA from BGP Extended community transtive registry.  The
   value field of the community is set to the 6 bytes of configurable
   segment identifier value.



Murakami, et al.        Expires September 8, 2022               [Page 9]


Internet-Draft                BGP MUP SAFI                    March 2022


   The usage of this Extended community is described in the
   Section 3.3.12 and Section 3.3.10

3.3.  Operation

   BGP speakers acting as a MUP PE, MUP GW and a MUP Controller MUST
   establish a BGP session to exchange BGP-MUP NLRIs for both, IPv4 and
   IPv6 AFIs.  Once the session is established successfully, BGP
   speakers can exchange the Discovery routes as well as Session
   Transformed routes.  This information is specific to a given routing
   instance.  BGP-MUP SAFI is expected to work with routing instances
   accomodationg MUP segments.  In 3GPP 5G specific case, the routing
   instances are depicted as N3RAN and N6DN instances defined in
   [I-D.mhkk-dmm-srv6mup-architecture].  The subsequent sections
   describes procedures of generating and processing of each route
   types.

3.3.1.  Generation of the Interwork Segment Discovery route

   The Interwork Segment Discovery route is generated by the MUP GW when
   a routing instance accommodates an Interwork type MUP Segment, e.g.,
   N3 interfaces or routes on RAN side in 3GPP 5G specific case.  It
   generates route per each N3RAN IP prefix and stores the route in the
   routing instance of N3RAN.  The IP prefix MAY include a gNodeB
   address which is connecting to the MUP GW.  The BGP AFI for BGP
   MP_REACH_NLRI attribute to carry the Discovery route is decided based
   on the AFI of the prefix.

   When advertising the Interwork Segment Discovery route, a MUP GW MUST
   attach the export BGP Route Target Extended Community of the
   associated routing instance.

   When advertising the Interwork Segment Discovery route, a MUP GW MUST
   use the IPv6 address of the MUP GW as the nexthop address in the
   MP_REACH_NLRI attribute.

   The Interwork Segment Discovery route update MUST have a prefix SID
   attribute which the SID consists of the MUP GW locater followed by a
   function.  In 3GPP 5G specific case, if the BGP AFI is IPv4, the
   function MUST be GTP4.E [I-D.ietf-dmm-srv6-mobile-uplane], or MUST be
   GTP6.E [I-D.ietf-dmm-srv6-mobile-uplane] if the BGP AFI is IPv6.

3.3.2.  Withdrawal of the Interwork Segment Discovery route

   The Interwork Segment Discovery route is withdrawn by the MUP GW when
   it detects that the MUP Segment no longer present for the N3RAN.  The
   BGP AFI for BGP MP_UNREACH_NLRI attribute to carry the Discovery
   route is decided based on the AFI of the prefix.



Murakami, et al.        Expires September 8, 2022              [Page 10]


Internet-Draft                BGP MUP SAFI                    March 2022


   When withdrawing the Interwork Segment Discovery route, a MUP GW MUST
   attach the export BGP Route Target Extended Community of the
   associated routing instance.

3.3.3.  Processing of the Interwork Segment Discovery routes

   Both, the MUP GW and the MUP PE MAY receive the Discovery Interwork
   routes from other MUP GWs in the BGP MUP network.  A BGP speaker
   acting as a MUP PE or a MUP GW MAY keep the received MUP Interwork
   Segment Discovery routes advertised from other MUP GWs.  The
   receiving BGP speaker will perform the importing of the received MUP
   Interwork Segment Discovery routes in the configured routing instance
   based on the Route Target extended communities.  The IP prefixes for
   the received segments are imported into the configured routing
   instance table.  Thereby the receiving BGP speaker can provide
   network connectivity between the nodes that exist in the segments.  A
   BGP speaker MAY discard the received Interwork Segment Discovery
   route if the speaker fails to import the route based on the Route
   Target extended communities.

   The BGP speaker receiving the Interwork Segment Discovery routes
   SHOULD ignore the nexthop in the MP_REACH_NLRI attribute.  However,
   the receiving BGP speaker MUST ensure that the value of Address filed
   in the NLRI is an address of the originator of the locator value in
   the prefix SID attribute.  The originator of the locator value can be
   resolved from the IPv6 IGP table.  If the result of the match is not
   identical then the receiving BGP speaker MUST consider it as a
   malformed NLRI and the "Treat-as-withdraw procedure of [RFC7606] is
   applied.  A BGP speaker MUST skip such NLRIs and continue processing
   of rest of the Update message.

   When a BGP speaker receives a MP_REACH_NLRI attribute update message
   with a Discovery Internetwork NLRI without a prefix SID attribute,
   than it MUST be treated as if it contained a malformed prefix SID
   attribute and the "Treat-as-withdraw procedure of [RFC7606] is
   applied.  A BGP speaker MUST skip such NLRIs and continue processing
   of rest of the Update message.

   When a BGP speaker receives an MP_UNREACH_NLRI attribute update
   message it MUST delete the withdrawn Interwork Segment Discovery
   route from the routing instance table where it was created.

3.3.4.  Generation of the Direct Segment Discovery route

   The Direct Segment Discovery route is generated by the MUP PE when a
   routing instance accommodates a Direct type MUP Segment, e.g., N6
   interface or routes on DN side in 3GPP 5G specific case.  It
   generates the Direct Segment Discovery route per each routing



Murakami, et al.        Expires September 8, 2022              [Page 11]


Internet-Draft                BGP MUP SAFI                    March 2022


   instance for the MUP Segment.  The address in the BGP-MUP NLRI MUST
   be a unique MUP PE identifier.  The BGP AFI for BGP MP_REACH_NLRI
   attribute to carry the Direct Segment Discovery route is decided
   based on the AFI of the MUP PE identifier
   [I-D.mhkk-dmm-srv6mup-architecture].

   When announcing the Direct Segment Discovery route, a MUP PE MUST
   attach a BGP MUP Extended community of the associated routing
   instance.  The sub-type of the Extended community is Direct-Type
   Segment Identifier.

   When advertising the Direct Segment Discovery route, a MUP PE MUST
   use the IPv6 address of the MUP PE as the nexthop address in the
   MP_REACH_NLRI attribute.

   The Direct Segment Discovery route update MUST have a prefix SID
   attribute which the SID consists of the MUP PE locator followed by a
   function.  The function MAY be End.DT4/6 or End.DX4/6.

3.3.5.  Withdrawal of the Direct Segment Discovery route

   The Direct Segment Discovery route is withdrawn by the MUP PE when it
   detects that the MUP Segment no longer present for the routing
   instance.  The BGP AFI for BGP MP_UNREACH_NLRI attribute to carry the
   Discovery route is decided based on the AFI of the MUP PE identifier.

   When withdrawing the Direct Segment Discovery route, a BGP speaker
   MUST attach a BGP MUP Extended community of the associated routing
   instance.

3.3.6.  Processing of the Direct Segment Discovery routes

   Both, the MUP GW and the MUP PE MAY receive the Discovery Direct
   routes from other MUP PEs in the BGP MUP network.  A BGP speaker
   acting as a MUP PE or a MUP GW MAY keep the received MUP Direct
   Segment Discovery routes advertised from other MUP PEs.  The
   receiving BGP speaker will perform the importing of the received MUP
   Direct Segment Discovery routes in the configured routing instance
   based on the Route Target extended communities.  The IP prefixes for
   the received segments are imported into the configured routing
   instance table.  Thereby the receiving BGP speaker can provide
   network connectivity between the nodes that exist in the segments.  A
   BGP speaker MAY discard the received Direct Segment Discovery route
   if the speaker fails to import the route based on the Route Target
   extended communities.

   The BGP speaker receiving the Direct Segment Discovery routes SHOULD
   ignore the nexthop in the MP_REACH_NLRI attribute.  However, the



Murakami, et al.        Expires September 8, 2022              [Page 12]


Internet-Draft                BGP MUP SAFI                    March 2022


   receiving BGP speaker MUST ensure that the received nexthop value in
   the MP_REACH_NLRI attribute is identical to the originator of the
   locator value in the prefix SID attribute.  The originator of the
   locator value can be resolved from the IPv6 IGP table.  If the result
   of the match is not identical then the receiving BGP speaker MUST
   consider it as a malformed NLRI and the "Treat-as-withdraw procedure
   of [RFC7606] is applied.  A BGP speaker MUST skip such NLRIs and
   continue processing of rest of the Update message.

   When a BGP speaker receives a MP_REACH_NLRI attribute update message
   with a Direct Segment Discovery route without a prefix SID attribute,
   than it MUST be treated as if it contained a malformed prefix SID
   attribute and the "Treat-as-withdraw procedure of [RFC7606] is
   applied.  A BGP speaker MUST skip such NLRIs and continue processing
   of rest of the Update message.

   When a BGP speaker receives an MP_UNREACH_NLRI attribute update
   message it MUST delete the withdrawn Direct Segment Discovery route
   from the routing instance table where it was created.

3.3.7.  Generation of the Type 1 ST Route

   A BGP speaker acting as a MUP controller generates Type 1 ST route
   from corresponding session information through a northbound API as
   per [I-D.mhkk-dmm-srv6mup-architecture].  The northbound API
   definition for ST1 route creation is out of scope of this document.

   In 3GPP 5G specific case, to compose a Type 1 ST route the MUP
   controller acquires UE address or prefix, Tunnel Endpoint address of
   GTP [TS.29281] tunnel, TEID, and QFI for access side as input
   parameters from the northbound API.  The MUP controller decides the
   RD of the Type 1 ST route based on operator policy.

   When advertising the Type 1 ST route, the MUP controller SHOULD
   attach a Route Target Extended community which the MUP PEs are
   importing into the routing instance for the corresponding Direct
   segment.

   The MUP controller MUST set the nexthop of the route to the address
   of the MUP Controller.

   The MUP controller MUST announce this route using a AFI of the route
   and the SAFI of BGP-MUP to all other BGP speakers within the SRv6
   domain.







Murakami, et al.        Expires September 8, 2022              [Page 13]


Internet-Draft                BGP MUP SAFI                    March 2022


3.3.8.  Withdrawing of the Type 1 ST Route

   A BGP speaker acting as a MUP controller withdraws Type 1 ST route
   based on deletion of corresponding session information through a
   northbound API as per [I-D.mhkk-dmm-srv6mup-architecture].  The
   northbound API definition for ST1 route withdraw is out of scope of
   this document.

   In 3GPP 5G specific case, to withdraw a Type 1 ST route the MUP
   controller acquires the UE address or prefix, Tunnel Endpoint address
   of GTP[TS.29281] tunnel, TEID,and QFI for access side as input
   parameters from the northbound API.  The MUP controller MUST
   advertise the withdraws of the Type 1 ST route.

   When withdrawing the Type 1 ST route, the MUP controller SHOULD
   attach the Route Target Extended community which the MUP PEs are
   importing into the routing instance accomodating the corresponding
   Direct segment to the Route Target Extended community.

3.3.9.  Processing of the Type 1 ST Route

   Both, the MUP GW and the MUP PE MAY receive the Type 1 ST routes from
   the MUP Controller in the BGP MUP network.  A BGP speaker acting as a
   MUP PE or a MUP GW MAY keep the received MUP Type 1 ST routes
   advertised from the MUP Controller.  The receiving BGP speaker will
   perform the importing of the received MUP Type 1 ST routes in the
   configured N6DN routing instance based on the Route Target extended
   communities.  A BGP speaker MAY discard the received Type 1 ST route
   if the speaker fails to import the route based on the Route Target
   extended communities.

   In case of a BGP speaker receiving a Type 1 ST routes is a MUP PE,
   the MUP PE SHOULD use the received Tunnel Endpoint Address in this
   NLRI as a key to lookup the associated Interwork Segment Discovery
   route and extract the locator and the function in the prefix SID
   attribute of the Interwork route.

   In 3GPP 5G specific case, the MUP PE extracts TEID, QFI and Tunnel
   Endpoint address from the NLRI.  Then the MUP PE SHOULD generate the
   forwarding SID for GTP4/6.E based on the procedures mentioned in the
   [I-D.ietf-dmm-srv6-mobile-uplane].  If the MUP PE cannot generate the
   prefix SID, then it SHOULD mark the received Type 1 ST route as an
   invalid route.  The MUP PE MAY hold such an invalid route until the
   route as a valid route upon successful generation of prefix SID.

   The MUP PE receiving Type 1 ST routes SHOULD ignore the received
   nexthop in the MP_REACH_NLRI attribute.




Murakami, et al.        Expires September 8, 2022              [Page 14]


Internet-Draft                BGP MUP SAFI                    March 2022


   The MUP PE receiving Type 1 ST routes in MP_UNREACH_NLRI attribute
   MUST delete all the routes from the associated routing instance.

3.3.10.  Generation of the Type 2 ST Route

   A BGP speaker acting as a MUP controller generates Type 2 ST route
   from corresponding session information through a northbound API, or
   pre-defined configuration as per [I-D.mhkk-dmm-srv6mup-architecture].
   The northbound API definition for ST2 route creation is out of scope
   of this document.

   In 3GPP 5G specific case, to compose a Type 2 ST route the MUP
   controller acquires the Endpoint consists of Endpoint address of GTP
   [TS.29281] tunnel and TEID for core side with the effective length of
   the Endpoint as input parameters.  The MUP controller decides the RD
   of the Type 2 ST route based on operator policy.

   When advertising the Type 2 ST route, the MUP controller SHOULD
   attach a BGP MUP Extended community corresponding to the Direct
   segment.  The sub-type of the Extended community is Direct-Type
   Segment Identifier.  This Segment Identifier is generated from the
   information received through a northbound API, or a pre-defined
   configuration as per [I-D.mhkk-dmm-srv6mup-architecture].  The
   northbound API definition for receving this information is out of
   scope of this document.

   The MUP controller MUST also attach a Route Target Extended community
   of the routing instances in the MUP GW accomodating the corresponding
   Interwork segment.

   The MUP controller MUST set the nexthop of the route to the address
   of the MUP Controller.

3.3.11.  Withdrawing of the Type 2 ST Route

   A BGP speaker acting as a MUP controller withdraws Type 2 ST route
   based on deletion of corresponding session information through a
   northbound API as per [I-D.mhkk-dmm-srv6mup-architecture].  The
   northbound API definition for ST2 route withdraw is out of scope of
   this document.

   In 3GPP 5G specific case, to withdraw a Type 2 ST route the MUP
   controller acquires the Endpoint consists of Endpoint address of GTP
   [TS.29281] tunnel and TEID for core side with the effective length of
   the Endpoint as input parameters.  The MUP controller MUST advertise
   the withdraws of the Type 2 ST route.





Murakami, et al.        Expires September 8, 2022              [Page 15]


Internet-Draft                BGP MUP SAFI                    March 2022


   When withdrawing the Type 2 ST route, the MUP controller SHOULD
   attach the BGP MUP Extended community corresponding to the Direct
   segment, and the Route Target Extended community which the MUP GWs
   are importing into the routing instance accomodating the
   corresponding Interwork segment to the Route Target Extended
   community.

3.3.12.  Processing of the Type 2 ST Route

   Both, the MUP GW and the MUP PE MAY receive the Type 2 ST routes from
   the MUP Controller in the BGP MUP network.  A BGP speaker acting as a
   MUP PE or a MUP GW MAY keep the received MUP Type 2 ST routes
   advertised from the MUP Controller.  The receiving BGP speaker will
   perform the importing of the received MUP Type 2 ST routes in the
   configured N3RAN routing instance based on the Route Target extended
   communities.  A BGP speaker MAY discard the received Type 2 ST route
   if the speaker fails to import the route based on the Route Target
   extended communities.

   The BGP speaker receiving the Type 2 ST routes SHOULD ignore the
   received nexthop in the MP_REACH_NLRI attribute.

   A MUP GW receiving the Type 2 ST routes in a MP_REACH_NLRI attribute
   without a BGP MUP Extended community SHOULD consider the route as a
   malformed route.  The MUP GW MUST handle such a malformed NLRI as a
   "Treat-as-withdraw" [RFC7606].

   The MUP GW receiving Type 2 ST route with a BGP MUP Extended
   Community should extract the received segment identifier from the
   community.  The segment identifier is used to resolve an appropriate
   Direct segment routing instance.

4.  Security Considerations

   The mechanisms described in this document could reuse the existing
   BGP security mechanisms [RFC4271] [RFC4272].  The security model and
   threats specific to Provider Provisioned VPNs, including L3VPNs, are
   discussed in [RFC4111].  The method defined in [RFC5925] SHOULD be
   used where authentication of BGP control packets is needed.

   This document defines 3 new network nodes; MUP PE, MUP GW and a MUP
   Controller.  These MUP BGP speakers SHOULD NOT establish BGP sessions
   with other BGP speakers in the domains which are not trusted without
   any explicit configuration or an operator intervention.  Usage of
   procedures defined in [RFC5925] SHOULD be enforced at such boundaries
   to ensure the proper authentication of BGP control packets.





Murakami, et al.        Expires September 8, 2022              [Page 16]


Internet-Draft                BGP MUP SAFI                    March 2022


   Furthermore, [RFC5925] will not help to keep the BGP messages
   private.  To protect the BGP messages exchanged between BGP speakers
   from eavesdrop, establishing BGP sessions over encrypted paths SHOULD
   be considered.

   MUP PEs and GWs SHOULD impose an upper bound on number of routes they
   should store to protect their control plane load.  For example, BGP
   implementations MAY provide a configuration knob to impose an upper
   bound on Type 1 ST Routes.

5.  IANA Considerations

   This document defines a new BGP SAFI known as a BGP-MUP SAFI.  IANA
   is requested to assign the value for the new SAFI from the Subsequent
   Address Family Identifiers (SAFI) registry.

   This document defines a new Architecture Type for a BGP-MUP SAFI.
   IANA is requested to create a new Architecture Type NLRI registry for
   BGP-MUP SAFI.  Furthermore, IANA is also requested to assign values
   for the following Architecture Types from the newly created BGP-MUP
   Architecture Type NLRI registry:

         + 1 - 3gpp-5g;

   This document defines new NLRIs for a BGP-MUP SAFI.  IANA is
   requested to create a new NLRI registry for BGP-MUP SAFI.
   Furthermore, IANA is also requested to assign values for the
   following NLRIs from the newly created BGP-MUP NLRI registry:

         + 1 - Discovery Internetwork route;
         + 2 - Direct Segment Discovery route;
         + 3 - Type 1 Session Transformed (ST) route;
         + 4 - Type 2 Session Transformed (ST)  route;

   This document defines a new BGP Extended Community called "SRv6 MUP
   Extended Community".  This Community is of an extended type and is
   transitive.  IANA is requested to assign the Type and the Sub-Type
   value for this Community from the Transitive Extended Community
   registry.

6.  Contributors

   In addition to the authors listed on the front page, the following
   individuals have also made significant contributions to the draft:

       Katsuhiro Horiba
       SoftBank
       Email: katsuhiro.horiba@g.softbank.co.jp



Murakami, et al.        Expires September 8, 2022              [Page 17]


Internet-Draft                BGP MUP SAFI                    March 2022


       Yuya Kawakami
       SoftBank
       Email: yuya.kawakami01@g.softbank.co.jp

       Kalyani Rajaraman
       SoftBank
       Email: kalyanir@arrcus.com

7.  References

7.1.  Normative References

   [I-D.mhkk-dmm-srv6mup-architecture]
              Matsushima, S., Horiba, K., Khan, A., Kawakami, Y.,
              Murakami, T., Patel, K., Kohno, M., Kamata, T., Garvia, P.
              C., Voyer, D., Zadok, S., Meilik, I., Agrawal, A.,
              Perumal, K., and J. Horn, "Segment Routing IPv6 Mobile
              User Plane Architecture for Distributed Mobility
              Management", draft-mhkk-dmm-srv6mup-architecture-02 (work
              in progress), March 2022.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119,
              DOI 10.17487/RFC2119, March 1997,
              <https://www.rfc-editor.org/info/rfc2119>.

   [RFC2918]  Chen, E., "Route Refresh Capability for BGP-4", RFC 2918,
              DOI 10.17487/RFC2918, September 2000,
              <https://www.rfc-editor.org/info/rfc2918>.

   [RFC4271]  Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A
              Border Gateway Protocol 4 (BGP-4)", RFC 4271,
              DOI 10.17487/RFC4271, January 2006,
              <https://www.rfc-editor.org/info/rfc4271>.

   [RFC4272]  Murphy, S., "BGP Security Vulnerabilities Analysis",
              RFC 4272, DOI 10.17487/RFC4272, January 2006,
              <https://www.rfc-editor.org/info/rfc4272>.

   [RFC4360]  Sangli, S., Tappan, D., and Y. Rekhter, "BGP Extended
              Communities Attribute", RFC 4360, DOI 10.17487/RFC4360,
              February 2006, <https://www.rfc-editor.org/info/rfc4360>.

   [RFC4760]  Bates, T., Chandra, R., Katz, D., and Y. Rekhter,
              "Multiprotocol Extensions for BGP-4", RFC 4760,
              DOI 10.17487/RFC4760, January 2007,
              <https://www.rfc-editor.org/info/rfc4760>.




Murakami, et al.        Expires September 8, 2022              [Page 18]


Internet-Draft                BGP MUP SAFI                    March 2022


   [RFC7606]  Chen, E., Ed., Scudder, J., Ed., Mohapatra, P., and K.
              Patel, "Revised Error Handling for BGP UPDATE Messages",
              RFC 7606, DOI 10.17487/RFC7606, August 2015,
              <https://www.rfc-editor.org/info/rfc7606>.

   [RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
              2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
              May 2017, <https://www.rfc-editor.org/info/rfc8174>.

   [RFC9012]  Patel, K., Van de Velde, G., Sangli, S., and J. Scudder,
              "The BGP Tunnel Encapsulation Attribute", RFC 9012,
              DOI 10.17487/RFC9012, April 2021,
              <https://www.rfc-editor.org/info/rfc9012>.

7.2.  Informative References

   [I-D.ietf-dmm-srv6-mobile-uplane]
              Matsushima, S., Filsfils, C., Kohno, M., Garvia, P. C.,
              Voyer, D., and C. E. Perkins, "Segment Routing IPv6 for
              Mobile User Plane", draft-ietf-dmm-srv6-mobile-uplane-18
              (work in progress), February 2022.

   [RFC4111]  Fang, L., Ed., "Security Framework for Provider-
              Provisioned Virtual Private Networks (PPVPNs)", RFC 4111,
              DOI 10.17487/RFC4111, July 2005,
              <https://www.rfc-editor.org/info/rfc4111>.

   [RFC4364]  Rosen, E. and Y. Rekhter, "BGP/MPLS IP Virtual Private
              Networks (VPNs)", RFC 4364, DOI 10.17487/RFC4364, February
              2006, <https://www.rfc-editor.org/info/rfc4364>.

   [RFC5925]  Touch, J., Mankin, A., and R. Bonica, "The TCP
              Authentication Option", RFC 5925, DOI 10.17487/RFC5925,
              June 2010, <https://www.rfc-editor.org/info/rfc5925>.

   [RFC6811]  Mohapatra, P., Scudder, J., Ward, D., Bush, R., and R.
              Austein, "BGP Prefix Origin Validation", RFC 6811,
              DOI 10.17487/RFC6811, January 2013,
              <https://www.rfc-editor.org/info/rfc6811>.

   [RFC8205]  Lepinski, M., Ed. and K. Sriram, Ed., "BGPsec Protocol
              Specification", RFC 8205, DOI 10.17487/RFC8205, September
              2017, <https://www.rfc-editor.org/info/rfc8205>.

   [TS.23501]
              3GPP, "System architecture for the 5G System (5GS)", 3GPP
              TS 23.501 17.2.0, September 2021,
              <http://www.3gpp.org/ftp/Specs/html-info/23501.htm>.



Murakami, et al.        Expires September 8, 2022              [Page 19]


Internet-Draft                BGP MUP SAFI                    March 2022


   [TS.29281]
              3GPP, "General Packet Radio System (GPRS) Tunnelling
              Protocol User Plane (GTPv1-U)", 3GPP TS 29.281 16.1.0,
              September 2020.

Authors' Addresses

   Tetsuya Murakami
   Arrcus
   2077 Gateway Place, Suite 400
   San Jose, CA  95110
   USA

   Email: tetsuya@arrcus.com


   Keyur Patel
   Arrcus
   2077 Gateway Place, Suite 400
   San Jose, CA  95110
   USA

   Email: keyur@arrcus.com


   Satoru Matsushima
   SoftBank
   Japan

   Email: satoru.matsushima@g.softbank.co.jp


   Jeffrey Zhang
   Juniper Networks
   USA

   Email: zzhang@juniper.net


   Swadesh Agrawal
   Cisco Systems
   USA

   Email: swaagraw@cisco.com







Murakami, et al.        Expires September 8, 2022              [Page 20]