Subject: [DMM] Review comments on draft-matsushima-spring-dmm-srv6-mobile-uplane-02

From: "Sri Gundavelli (sgundave)" <[email-masked]>
Date: Mon, 13 Nov 2017 09:03:24 +0000

Authors:

Good work! Some high level comments on the draft.

1.) It will be useful to identify the key data plane features used today in conjunction with the tunnel based approach and how those features are impacted when using SRv6 user plane.

2.) There are heartbeat protocols that is used for path check between the access and anchor. Assuming those mechanisms are still in use between the access and anchor, I am wondering how these failure events impact the SRv6 states? For exam

3.) Discussion on definition of new SRv6 functions needed to support this architecture will help

4.) It will be good if this document sets the overall context, allowing additional drafts to focus on specific aspects.

Please see inline for additional comments.

---------------------------------------------------------

               Segment Routing IPv6 for Mobile User-Plane
           draft-matsushima-spring-dmm-srv6-mobile-uplane-02

Abstract

   This document discusses the applicability of SRv6 (Segment Routing
   IPv6) to user-plane of mobile networks that SRv6 source routing
   capability with its programmability can fulfill the user-plane
   functions, such as access and anchor functions.  It takes advantage
   of underlying layer awareness and flexibility to deploy user-plane
   functions that enables optimizing data-path for applications.
   Network slicing and an interworking way between SRv6 and existing
   mobile user-plane are also discussed in this 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 http://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 May 3, 2018.

Copyright Notice

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

Matsushima, et al.         Expires May 3, 2018                  [Page 1]

Internet-Draft             SRv6-mobile-uplane               October 2017

   (http://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
   2.  Conventions and Terminology . . . . . . . . . . . . . . . . .   3
   3.  Motivations . . . . . . . . . . . . . . . . . . . . . . . . .   3
   4.  Mobile User-Plane . . . . . . . . . . . . . . . . . . . . . .   3
   5.  Segment Routing IPv6 for Mobile User-Plane Functions  . . . .   5
   6.  SRv6 Functions and Behaviors for User-Plane . . . . . . . . .   6
     6.1.  Per Session Segment for Basic User-Plane  . . . . . . . .   6
       6.1.1.  Uplink  . . . . . . . . . . . . . . . . . . . . . . .   6
       6.1.2.  Downlink  . . . . . . . . . . . . . . . . . . . . . .   7
     6.2.  Aggregated Segment for Basic User-Plane . . . . . . . . .   8
       6.2.1.  Uplink  . . . . . . . . . . . . . . . . . . . . . . .   8
       6.2.2.  Downlink  . . . . . . . . . . . . . . . . . . . . . .   8
     6.3.  Stateless Interworking  . . . . . . . . . . . . . . . . .   9
     6.4.  Rate Limit Function . . . . . . . . . . . . . . . . . . .  10
   7.  Network Slicing Considerations  . . . . . . . . . . . . . . .  11
   8.  Control Plane Considerations  . . . . . . . . . . . . . . . .  11
   9.  Security Considerations . . . . . . . . . . . . . . . . . . .  12
   10. IANA Considerations . . . . . . . . . . . . . . . . . . . . .  12
   11. References  . . . . . . . . . . . . . . . . . . . . . . . . .  12
     11.1.  Normative References . . . . . . . . . . . . . . . . . .  12
     11.2.  Informative References . . . . . . . . . . . . . . . . .  12
   Authors' Addresses  . . . . . . . . . . . . . . . . . . . . . . .  13

1.  Introduction

   In mobile networks, mobility management systems provide connectivity
   while mobile nodes move around.  While the control-plane of the
   system signals movements of a mobile node, user-plane establishes
   tunnel between the mobile node and anchor node over IP based backhaul
   and core networks.

   This document discusses the applicability of SRv6 (Segment Routing
   IPv6) to those mobile networks.  SRv6 provides source routing to
   networks where operators can explicitly indicate route for the
   packets from and to the mobile node.  SRv6 endpoint nodes act as
   roles of anchor of mobile user-plane.

Matsushima, et al.         Expires May 3, 2018                  [Page 2]

Internet-Draft             SRv6-mobile-uplane               October 2017

2.  Conventions and Terminology

   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 [RFC2119].

   All segment routing and SRv6 network programming terms are defined in
   [I-D.ietf-spring-segment-routing] and
   "[I-D.filsfils-spring-srv6-network-programming].

3.  Motivations

   Today's and future applications are requiring highly optimized data-
   path between mobile nodes and the entities of those applications in
   perspectives of latency, bandwidth, etc,. However current
   architecture of mobile management is agnostic about underlying
   topologies of transport layer.  It rigidly fragments the user-plane
   in radio access, core and service networks and connects them by
   tunneling techniques through the user-plane functions such as access
   and anchor nodes.  Those agnostic and rigidness make it difficult for
   the operator to optimize the data-path.

   While the mobile network industry has been trying to solve that,
   applications shift to use IPv6 data-path and network operators adopt
   it as their IP transport as well.  SRv6 integrates both application
   data-path and underlying transport layer in data-path optimization
   aspects that does not require any other techniques.

[Sri] May be worth rephrasing with more details.

   SRv6 source routing capability with programmable functions
   [I-D.filsfils-spring-srv6-network-programming] could fulfills the
   user-plane functions of mobility management.  It takes advantage of
   underlying layer awareness and flexibility to deploy user-plane
   functions.  Those are the motivations to adopt SRv6 for mobile user-
   plane.

4.  Mobile User-Plane

   This section describes user-plane using SRv6 for mobile networks.
   This clarifies mobile user-plane functions to which SRv6 endpoint
   applied.

   Figure 1 shows mobile user-plane functions which are connected
   through IPv6-only networks.  In the Figure 1, an mobile node (MN)
   connects to an SRv6 endpoint serving access point role for the MN.
   When the endpoint receives packets from the MN, it pushes SRH to the
   packets.  The segment list in the SRH indicates the rest of user-
   plane segments which are L2 and L3 anchors respectively.  Then the
   endpoint send the packets to the IPv6 network.  In opposite

Matsushima, et al.         Expires May 3, 2018                  [Page 3]

Internet-Draft             SRv6-mobile-uplane               October 2017

   direction, when an SRv6 endpoint serving L3 anchor role for the MN
   receives packets to it, the endpoint push SRH consist of the L2
   anchor and access point segments to the packets.

[Sri] I realize the control-plane extensions are outside the scope of this work, but might be worth explaining how the CP influences the segment list generation at the endpoint. I am assuming the User Plan Anchor selection, the IP address allocation would influence this segment list selection. May be you want to cover this in Appendix section for PMIP-based and GTP-based control plane as examples.

                                User-plane
                                Function
                               <L2 Anchor>
                                O------O
                                | SRv6 |
                                | End  |
                                | Point|
                                O------O
              User-plane           ||           User-plane
    [MN]      Function        _____||_____      Function
      |     <Access Point>   /            \    <L3 Anchor>
   ___v___     O------O     /              \     O------O     ________
  /  Radio \   | SRv6 |    /                \    | SRv6 |    /        \
 /  Access  \==| End  |===/     IPv6-Only    \===| End  |===/ Service  \
 \    NW    /  | Point|   \      Network     /   | Point|   \    NW    /
  \________/   O------O    \                /    O------O    \________/
                            \              /
                             \____________/

                   Figure 1: Mobile User-plane with SRv6

   An SRv6 segment represents those each function, such as Access Point,
   Layer-2 (L2) Anchor and Layer-3 (L3) Anchor.  This makes mobile
   networks highly flexible to deploy any user-plane functions to which
   nodes in user flow basis.  An SRv6 segment can represent a set of
   flows in any granularity of aggregation even though it is just for a
   single flow.

[Sri] May be some more explanation will greatly help

   Figure 2 shows that an SRv6 endpoint connects existing IPv4 mobile
   user-plane, which is defined in [RFC5213] and [TS.29281].  An SRv6
   segment in the endpoint represents interworking function which
   enables interworking between existing access point and SRv6 anchor
   segment, or SRv6 access point segment and existing anchor node.

   Existing mobile user-plane with IPv6 underlay is expected to be
   widely deployed.  As IPv6 network should be interoperable with SRv6
   endpoints can be accommodated on it, interworking with existing IPv6
   network is out of scope of this document.

Matsushima, et al.         Expires May 3, 2018                  [Page 4]

Internet-Draft             SRv6-mobile-uplane               October 2017

     ________                                                 _______
    /        \    O------O                                   /       \
   / Service  \===|L2/L3 |                                  / Service \
   \    NW    /   |Anchor|         User-plane               \    NW   /
    \________/    |Node  |         Function                  \_______/
                  O------O       <Interworking>                  ||
                      \\_______     O------O     ________     O------O
                      /        \    | SRv6 |    /        \    | SRv6 |
                     / Existing \===| End  |===/ IPv6-Only\===| End  |
                     \  IPv4 NW /   | Point|   \  Network /   | Point|
       [MN]           \________/    O------O    \________/    O------O
        |             //                                         ||
     ___v____    O------O                                     ___||__
    / Radio  \   |Access|                                    / Radio  \
   /  Access  \==|Point |                            [MN]~~~/  Access  \
   \    NW    /  |Node  |                                   \    NW    /
    \________/   O------O                                    \________/

           Figure 2: Interworking with Existing Mobile Networks

   The detail of SRv6 segments representing user-plane functions are
   described in Section 5.

5.  Segment Routing IPv6 for Mobile User-Plane Functions

   This section describes mobile user-plane functions to which SRv6 node
   can apply SRv6 functions and behaviors so that the nodes configured
   those segments can fulfills the user-plane functions.  Each function
   consist of two segments which are uplink (UL) from mobile node to the
   correspondent node, and downlink (DL) from the correspondent node to
   mobile node.

   We support following mobile user-plane functions:

   Access Point:

         Access Point function provides SRv6 node the role to which
         mobile node is connected directly.  eNodeB could be referenced
         as an entity implementing the access point in 3GPP term.

[Sri] Should the AP/eNB be impacted for supporting this architecture? Even though the air interface terminates on the AP, for all practical purposes the first-hop router has all the L2 awareness. Unless there is a need to look at the radio parameters/state (Ex: RSSI values ..etc) and if that can impact the SRv6 state machine on the endpoint, I wonder why the AP/eNB should have any SRv6 awareness. Or, may I am missing the point around "SRv6 node the role to which mobile node is connected directly.”.

   Layer-2 Anchor:

         Layer-2 anchor function provides SRv6 node the role to be
         anchor point while mobile node move around within a serving
         area which could be assumed as a layer-2 network.  Serving
         Gateway (SGW) could be referenced as an entity implementing the
         layer-2 anchor in 3GPP term.

[Sri] Does micro-mobility (UE movement within the radio network) under the same L2 anchor has any implication on the SRv6 operation ? Can a L2 handoff trigger some change in SRv6 state machine?

The key question in my above two comments is where does SRv6 begin, at AP or at First-hope router?

   Layer-3 Anchor:

         Layer-3 anchor function provides SRv6 node the role to be
         anchor point across a mobile network consists of multiple
         serving areas.  Packet data network gateway (PGW) could be
         referenced as an entity implementing the layer-3 anchor.

   Stateless Interworking:

         Stateless interworking function provides SRv6 node the role to
         interworking between existing mobile user-plane and SRv6 mobile
         user-plane.  It is expected that the endpoint of interworking
         segment could be unaware from the control-plane of the mobility
         management.  While there are combinations of interworking
         either existing or SRv6 network in which user-plane functions
         accommodate, interworking segment should cover all combinations
         without mobility state.

6.  SRv6 Functions and Behaviors for User-Plane

   This section describes SRv6 functions and behavior applied to mobile
   user-plane roles by use cases.  Terminology of SRv6 endpoint
   functions refers to [I-D.filsfils-spring-srv6-network-programming].
   In addition to that, new SRv6 functions and behaviors are introduced
   to cover some user cases.

6.1.  Per Session Segment for Basic User-Plane

   In this use case, we assume that mobile user-plane consists of SRv6
   segments per session basis.  We expect the user-plane functions as
   same as existing ones except using SRv6.  That means it just provides
   fundamental IPv6 connectivity for MNs and no advanced segment routing
   features introduced to it.

[Sri] What does per-session mean here? A mobile subscriber session with a specific IP address which is anchored on a UP Anchor?

Will all IP flows (Ex: TCP/UDP) for a given subscriber and with a specific source IPv6 address, always have the  anchor (L3 endpoint)?

6.1.1.  Uplink

   In uplink, SRv6 node applies following SRv6 end point functions and
   transit behavior.

   Access Point:  T.Insert

   L2-Anchor:  End.B6

   L3-Anchor:  End.T

Matsushima, et al.         Expires May 3, 2018                  [Page 6]

Internet-Draft             SRv6-mobile-uplane               October 2017

   When the access point node receives a packet destine to "D::1" from a
   mobile node "S::1", it does T.Insert process for the receiving
   packets to push a SRH with SID list (A2::1, D::1) and sets SL=1.  The
   access point node update DA to "A2::1" which indicates the UL
   L2-Anchor SID and forward the packet.

[Sri] Its good explain the above without impacting the AP.

   The L2-anchor node of "A2::1" segment does End.B6 process for the
   receiving packet according to the segment.  The node updates DA to
   next UL L3-anchor segment "A3::1" associated with "A2::1".  In this
   basic use case, just one UL L3-anchor SID with SL=0 is enough to do
   it so that there is no need to push another SRH to the packet in that
   PSP (Penultimate Segment Pop) operation.

   The L3-anchor node of "A3::1" segment does End.T process for the
   receiving packet according to the SRH that the node updates DA to
   D::1, decrement SL and lookup IPv6 table associated with "A3::1".  In
   this basic use case, decremented SL is 0 so that the node does PSP
   operation of popped out the SRH from the packet and forward it.

6.1.2.  Downlink

   In downlink, SRv6 node applies following SRv6 end point functions and
   transit behavior.

   L3-Anchor:  T.Insert

   L2-Anchor:  End.B6

   Access Point:  End.X

   When the L3-anchor node receives a packet destine to "S::1" from a
   correspondant node "D::1", it does T.Insert process for the receiving
   packets to push a SRH with SID list (A2::2, S::1) and sets SL=1.  The
   access point node update DA to "A2::2" which indicates the DL
   L2-Anchor SID and forward the packet.

   The L2-anchor node of "A2::2" segment does End.B6 process for the
   receiving packet according to the segment.  The node updates DA to
   next DL access point segment "A1::2" associated with "A2::2".  In
   this basic use case, just one DL access point SID with SL=0 is enough
   to do it so that there is no need to push another SRH to the packet
   in that PSP (Penultimate Segment Pop) operation.

   The access point node of "A1::2" segment does End.X process for the
   receiving packet according to the SRH that the node updates DA to
   S::1, decrement SL and forward the packet to the mobile node through
   its associated radio channel.  In this basic use case, decremented SL

Matsushima, et al.         Expires May 3, 2018                  [Page 7]

Internet-Draft             SRv6-mobile-uplane               October 2017

   is 0 so that the node does PSP operation of popped out the SRH from
   the packet and forward it.

6.2.  Aggregated Segment for Basic User-Plane

   We assume that basic user-plane as well as Section 6.1 here, however
   this section describes that SRv6 nodes allocate an aggregated segment
   for multiple sessions, not in per session basis.  Thank to IPv6 GUA,
   there is no need to employ additional identifier to distinguish each
   session.  This benefits SRv6 node allows to apply one segment to
   mobile sessions which belong to same policy.

[Sri] Some explanations on the assumption around “session" definition will help

6.2.1.  Uplink

   In uplink, SRv6 node applies following SRv6 end point functions and
   transit behavior.

   Access Point:  T.Insert

   L2-Anchor:  End.B6

   L3-Anchor:  End.T

   When the access point node receives a packet destine to "D::1" from a
   mobile node "S::1", it does T.Insert process for the receiving
   packets to push a SRH with SID list (AG20::, D::1) and sets SL=1.
   The access point node update DA to "AG20::" which indicates
   aggregated UL L2-Anchor SID and forward the packet.

   The aggregated L2-anchor node of "AG20::" segment does End.B6 process
   for the receiving packet according to the segment.  The node updates
   DA to aggregated UL L3-anchor segment "AG30::" associated with
   "AG20::".  In this basic use case, just one UL L3-anchor SID with
   SL=0 is enough to do it so that there is no need to push another SRH
   to the packet in that PSP (Penultimate Segment Pop) operation.

   The aggregated L3-anchor node of "AG30::" segment does End.T process
   for the receiving packet according to the SRH that the node updates
   DA to D::1, decrement SL and lookup IPv6 table associated with
   "AG30::".  In this basic use case, decremented SL is 0 so that the
   node does PSP operation of popped out the SRH from the packet and
   forward it.

6.2.2.  Downlink

   In downlink, SRv6 node applies following SRv6 end point functions and
   transit behavior.

Matsushima, et al.         Expires May 3, 2018                  [Page 8]

Internet-Draft             SRv6-mobile-uplane               October 2017

   L3-Anchor:  T.Insert

   L2-Anchor:  End.B6

   Access Point:  End.X

   When the L3-anchor node receives a packet destine to "S::1" from a
   correspondant node "D::1", it does T.Insert process for the receiving
   packets to push a SRH with SID list (AG21::, S::1) and sets SL=1.
   The access point node update DA to "AG21::2" which indicates the
   aggregated DL L2-Anchor SID and forward the packet.

   The aggregated L2-anchor node of "AG21::" segment does End.B6 process
   for the receiving packet according to the segment.  The node updates
   DA to aggregated DL access point segment "AG11::" associated with
   "AG21::".  In this basic use case, just one aggregated DL access
   point SID with SL=0 is enough to do it so that there is no need to
   push another SRH to the packet in that PSP (Penultimate Segment Pop)
   operation.

   The aggregated access point node of "AG11::" segment does End.X
   process for the receiving packet according to the SRH that the node
   updates DA to S::1, decrement SL and forward the packet to the mobile
   node through its associated radio channel.  In this basic use case,
   decremented SL is 0 so that the node does PSP operation of popped out
   the SRH from the packet and forward it.

6.3.  Stateless Interworking

   SRv6 SID for stateless interworking function is encoding identifiers
   of corresponding tunnel in existing network as argument of the SID.
   This document define an SRv6 end function, "End.TM", and a transit
   behavior "T.Tmap" using following SID encoding:

                +----------------------+------+-------+-------+
                |Locater of interwork  |  DA  |  SA   | Tun-ID|
                +----------------------+------+-------+-------+
                        128-a-b-c          a      b       c

               Figure 3: Stateless Interworking SID Encoding

   In SRv6 to existing network direction, an endpoint of interworking
   allocates End.TM function to a SID prefix, say "T0::".  When the
   endpoint receives packet and the active segment of the packet
   indicates that SID prefix, the endpoint does End.TM process that pops
   the SRH of the SID, and then the endpoint encaps the payload with the

Matsushima, et al.         Expires May 3, 2018                  [Page 9]

Internet-Draft             SRv6-mobile-uplane               October 2017

   encoded information in the SID which are tunnel identifier of tunnel
   header, source and destination IPv4 address of IPv4 header described
   in Figure 3.  Then the endpoint send out the packet to the existing
   network along with its routing policy.

   In existing network to SRv6 network direction, existing network
   allocates IPv4 address spaces routed to interworking SRv6 network.
   SRv6 network allocates a domain-wise SID prefix for interworking
   segments, say "T1::".  When a SRv6 endpoint connects to existing
   network receives packet destined to the allocated IPv4 address, the
   endpoint does T.Tmap behavior that decaps outer IPv4 and tunnel
   header, and then pushs an SRH with the SID which consists of the
   allocated SID prefix "T1::", source and destination addresses, and
   tunnel identifier as described in Figure 3.  Then the endpoint send
   out the packet to the SRv6 network along with its routing policy.

   In case of IPv4 flow packet over the user-plane, the endpoint does
   IPv6 header encaps and decaps instead of SRH insert and pop process.
   The IPv6 header includes interworking segment SID in the SRH.

   Noted that to make sure stateless interworking, entities of control-
   plane in mobile management should cooperate with SRv6 user-plane
   settings.  Further control-plane consideration is discussed in
   Section 8.

6.4.  Rate Limit Function

   Mobile user-plane requires rate-limit feature.  SID is able to encode
   limiting rate as an argument in SID.  Multiple flows of packets
   should have same group identifier in SID when those flows are in an
   same AMBR group.  This helps to keep user-plane stateless.  That
   enables SRv6 endpoint nodes which are unaware from the mobile
   control-plane information.  Encoding format of rate limit segment SID
   is following:

                +----------------------+----------+-----------+
                | Locater of rate-limit| group-id | limit-rate|
                +----------------------+----------+-----------+
                          128-i-j            i          j

               Figure 4: Stateless Interworking SID Encoding

   In case of j bit length is zero in SID, the node should not do rate
   limiting unless static configuration or control-plane sets the limit
   rate associated to the SID.

[Sri] In addition to Rate Limiting, probably few other QoS elements have to supported here.

Matsushima, et al.         Expires May 3, 2018                 [Page 10]

Internet-Draft             SRv6-mobile-uplane               October 2017

7.  Network Slicing Considerations

   Mobile network may be required to create a network slicing that
   represent a set of network resources and isolate those resource from
   other slices.  User-plane functions represented as SRv6 segments
   would be part of a slice.

   To represent a set of user-plane function segments for a slice,
   sharing same prefix through those SIDs within the slice could be a
   straightforward way.  SIDs in a network slice may include other type
   of functions in addition to the mobile user-plane functions described
   in this document, and underlay integration to meet SLA and quality
   requirements.

   While network slicing has been discussed in the IETF and other
   standardization bodies, what functionalities are required for network
   slicing in mobile user-plane is further study item and to be
   discussed.

[Sri] I am not sure if slicing discussion is relevant here

8.  Control Plane Considerations

   Mobile control-plane entities must allocate SIDs to user-plane
   function segments in case of those entities are distributed to
   accommodate in the SRv6 nodes, or those are separated from the
   endpoint but each of them corresponds to each SRv6 node.  In latter
   case, control-plane entity must advertise allocated SID to the
   endpoint through some means which are out of scope of this document.

   Noted that in the case of aggregated segments for mobile user-plane
   functions, allocated SIDs for the segments can be pre-configured to
   SRv6 nodes.  The control-plane should utilize those SIDs to manage
   mobility sessions especially when increasing number of sessions is
   expected to hit the upper-limit of the user-plane nodes.

   When a centralized controller interfaces to mobile control-planes is
   capable to allocate SIDs to the controlling SRv6 endpoints, the
   mobile control-planes just need to indicate the endpoint nodes and
   their user-plane functions to the controller.  In this case, the
   controller must allocate appropriate SIDs for the user-plane roles to
   the indicated SRv6 endpoints.  The controller must advertise
   allocated SIDs to the endpoints.  To build centralized controller for
   mobile user-plane is out of scope of this document.

   However, to indicate endpoints and their user-plane functions from
   mobile control-plane to user-plane, the endpoint or the controller
   could take advantage of [I-D.ietf-dmm-fpc-cpdp].  It provides
   interface to the control-plane to manage the user-plane of mobile
   networks.

Matsushima, et al.         Expires May 3, 2018                 [Page 11]

Internet-Draft             SRv6-mobile-uplane               October 2017

   In case of stateless interworking, SID allocating entity needs to be
   aware SID prefix which interworking SRv6 endpoint and SRv6 domain
   allocate discussed in Section 6.3.  The mobile control-plane also
   need to allocate tunnel endpoint IPv4 address to which corresponding
   interworking segment destined from existing user-plane that is also
   discussed in Section 6.3.

9.  Security Considerations

   TBD

10.  IANA Considerations

   This document has no actions for IANA.

11.  References

11.1.  Normative References

   [I-D.filsfils-spring-srv6-network-programming]
              Filsfils, C., Leddy, J., [email-masked], d.,
              [email-masked], d., Steinberg, D., Raszuk, R.,
              Matsushima, S., Lebrun, D., Decraene, B., Peirens, B.,
              Salsano, S., Naik, G., Elmalky, H., Jonnalagadda, P.,
              Sharif, M., Ayyangar, A., Mynam, S., Henderickx, W.,
              Bashandy, A., Raza, K., Dukes, D., Clad, F., and P.
              Camarillo, "SRv6 Network Programming", draft-filsfils-
              spring-srv6-network-programming-02 (work in progress),
              October 2017.

   [I-D.ietf-spring-segment-routing]
              Filsfils, C., Previdi, S., Ginsberg, L., Decraene, B.,
              Litkowski, S., and R. Shakir, "Segment Routing
              Architecture", draft-ietf-spring-segment-routing-13 (work
              in progress), October 2017.

   [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>.

11.2.  Informative References

   [I-D.ietf-dmm-fpc-cpdp]
              Matsushima, S., Bertz, L., Liebsch, M., Gundavelli, S.,
              Moses, D., and C. Perkins, "Protocol for Forwarding Policy
              Configuration (FPC) in DMM", draft-ietf-dmm-fpc-cpdp-09
              (work in progress), October 2017.

Matsushima, et al.         Expires May 3, 2018                 [Page 12]

Internet-Draft             SRv6-mobile-uplane               October 2017

   [RFC5213]  Gundavelli, S., Ed., Leung, K., Devarapalli, V.,
              Chowdhury, K., and B. Patil, "Proxy Mobile IPv6",
              RFC 5213, DOI 10.17487/RFC5213, August 2008,
              <https://www.rfc-editor.org/info/rfc5213>.

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

Authors' Addresses

   Satoru Matsushima
   SoftBank
   Tokyo
   Japan

   Email: [email-masked]

   Clarence Filsfils
   Cisco Systems, Inc.
   Belgium

   Email: [email-masked]

   Miya Kohno
   Cisco Systems, Inc.
   Japan

   Email: [email-masked]

   Daniel Voyer
   Bell Canada
   Canada

   Email: [email-masked]

Matsushima, et al.         Expires May 3, 2018                 [Page 13]

---

From: Satoru Matsushima <[email-masked]>
Date: Mon, 13 Nov 2017 20:14:39 +0800

Thank you Sri, for your review.

> 1.) It will be useful to identify the key data plane features used today in conjunction with the tunnel based approach and how those features are impacted when using SRv6 user plane. 

Sure. But I’d just cite existing document which well described current approach. It would be sfc for mobile document as one of them:

https://tools.ietf.org/html/draft-ietf-sfc-use-case-mobility

But I couldn’t find tunneled path optimization and service chaining. So it seems to be explained in our I-D, do you think so?

> 2.) There are heartbeat protocols that is used for path check between the access and anchor.

Ok, that would be an OAM feature like ICMPv6 in SRv6. Will try to mention it.

> Assuming those mechanisms are still in use between the access and anchor, I am wondering how these failure events impact the SRv6 states? For exam   

Right. Those are End.TM and T.Tmap introduced for stateless interworking between existing user-plane and SRv6 user-plane. Why “statless” is that not to affect existing c-plane and to avoid more mobile state aware entities because one of DMM purposes is to get rid out of mobile state from DPNs as I understand.

> 4.) It will be good if this document sets the overall context, allowing additional drafts to focus on specific aspects.

Yes, while the revise work I found that at least IPv4 support would be good to explain in an additional draft. But in terms of overall context, it would be nice if we can have another document to explain that overall context in addition to this draft because it mentions specific solution already. I think I can help to work on that generic document in case some volunteers we can involve.

I’ll get back to following your comments on specific part of the draft.

Cheers,
--satoru

> _______________________________________________
> dmm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dmm

---

From: Satoru Matsushima <[email-masked]>
Date: Tue, 14 Nov 2017 01:05:52 +0800

Oh I’ve just noticed that you are referring -02 version. But the latest version is -03.
Please find it from following link:

https://tools.ietf.org/html/draft-matsushima-spring-dmm-srv6-mobile-uplane-03

You can find much more about how stateless interworking works and its benefits.
Control-plane consideration has also been described well than -02 version.

Cheers,
--satoru

> 2017/11/13 20:14、Satoru Matsushima <[email-masked]>のメール:
>