Subject: [DMM] SRv6 for Mobile User-Plane

From: "Pablo Camarillo (pcamaril)" <[email-masked]>
Date: Mon, 26 Feb 2018 20:05:11 +0000

Hello authors, DMM,

I have reviewed your I-D on SRv6 for mobile user-plane and I would like to make some proposals. I have already discussed and brainstormed the details with some of the authors of the draft and they agree to this changes, however I would like to get the WG feedback on it.

Thank you,

Pablo.

I believe its straightforward to support IPv4 UE traffic by doing SRv6 with T.Encaps behavior. Hence, I think this should be documented in the draft.

The encapsulation behavior should be the default one, both for IPv4 and IPv6 UE traffic. However, a specific provider is allowed to do SRH insertion within a controlled domain [draft-voyer-6man-extension-header-insertion-02] for UE IPv6 traffic.

Also, in order to reduce overhead at the UPFs when using encapsulation, I would replace the End.B6 function for a new End.MAP function.

For example, if we consider the following topology:

UE----gNB----UPF1----UPF2

Then the uplink packet flow for the basic mode would look like this:

UE_out: (A, Z)

gNB_out: (gNB, U1::1) (A, Z) -> T.Encaps  <U1::1>

UPF1_out:  (gNB, U2::1) (A, Z) -> End.MAP

UPF2_out:  (A, Z) -> End.DT

The End.MAP function is simply replacing the UPF1 SID for the UPF2 SID.

Notice that using encapsulation, if you compare it with today user-plane using IPv6/GTP, the result is that SRv6 is just adding 40B of overhead (IPv6 header), while GTP over IPv6 is using 56B (IPv6, UDP, GTP).

=======

With respect to the aggregation mode, aside from using the encapsulation mode as described before, I would also like to add a note on the I-D on the fact that we can support the aggregation mode without changes in the N2 interface:

The current I-D for aggregation mode assumes that the gNB (uplink) has knowledge of an SR policy that contains all the SIDs belonging to TE, NFV and so on. Even though the I-D does not describe how the gNB is retrieving this information, I would like to make a statement on the fact that there are two alternatives:

A. The N2 interface is modified in order to signal a SID list to the gNB.

B. The N2 interface is not modified. In this case, we signal through the N2 interface an SRv6 BindingSID, that the gNB is going to resolve into a SID list via an SDN controller either using PCEP, reverse DNS lookup or LISP.

I’m aware that the I-D focuses on the user-plane, however I believe it’s important to state this alternatives since it simplifies the adoption and reduces impact in the existing mobile architectures (without going into the details on the mechanisms for each one of the alternatives of LISP, PCEP, reverse DNS-lookup).

=======

On the other hand, the current I-D proposes a mechanism for stateless interworking with legacy access networks that doesn’t support SRv6 (SGW and/or eNB). This mechanism presented in the I-D is limited to IPv4/GTP legacy networks. I would like to propose a mechanism to support interworking with legacy gNBs that does not support SRv6 but do support IPv6/GTP.

The main benefit comes from the fact that we can leverage an SRv6 BindingSID to have remote classification and steering of the UE traffic over an SR policy [draft-filsfils-spring-segment-routing-policy].

In this scenario, I propose that we add the notion of an SR GW -as the current stateless interworking node in the I-D-. This SR GW can be either a software based platform -e.g. VPP- or any existing router -the mechanism is simple and can be supported in existing HW-. This SR GW receives through the control plane the SR policies and installs the required Binding SIDs.

Then, for any UE connecting to a gNB, the N2 interface is going to signal an IPv6 address and a TEID. However, the difference is that with this new mechanism the IPv6 address that we are going to signal is going to be an SRv6 BindingSID instantiated at the SR GW.

The overall workflow is the following:

Uplink

Note: S1, S2 represent service functions and C1 represents a node for TE purposes

UE sends its packet (A, Z) on a specific wireless bearer to its gNB

gNB’s CP associates the session from the UE (A) with IPv6 address B and TEID T (N2 interface unchanged)

gNB_out: (gNB, B) (GTP: TEID T) (A, Z)                       ;; Interface N3 is unchanged

SR_GW_out: (SRGW, S1) (U2::1, C1; SL=2)(A, Z)       ;; new End.GTP.UP

S1_out: (SRGW, C1) (U2::1, C1; SL=1)(A, Z)

C1_out: (SRGW, U2::1) (A, Z)                                      ;; assuming PSP

UPF2_out:  (A, Z)                                                        ;; End.DT

Downlink

UPF2_in: (Z, A)                                                                       ;; UPF2 maps the flow with SID list <C1, S1, SRGW::TEID, gNB>

UPF2_out:  (U2::1, C1) (gNB, SRGW::TEID, S1, SL=3) (Z, A)   ;;  T.Encaps

C1_out: (U2::1, S1) (gNB, SRGW::T, S1, SL=2) (Z, A)

S1_out: (U2::1, SRGW::TEID) (gNB, SRGW::T, S1, SL=1) (Z, A)

SR_GW: (SRGW, gNB)(GTP: TEID=T)(Z, A)                             ;; End.GTP.DN

gNB_out: (Z, A)

The key points are:

- gNB is unchanged and encaps into GTP (N3 interface is not modified). gNB only needs to support IPv6 which is currently common in existing deployments.

- 5G Control-Plane (N2 interface) is unchanged: 1! IPv6 address (i.e. a BSID at the SR GW)

- SR GW removes GTP, finds SID list related to IPv6 DA (BSID), add SRH with SID list

- Same TE, NFV and scale properties as Aggregation mode

- There is NO state for the downlink at the SR gateway

- There is simple state in the uplink at the SR gateway (notice that since we are leveraging the aggregation mode, we expect few SR policies on this node. SR policies are shared across UEs)

- As soon as the packet leaves the gNB (uplink), the traffic is SR-routed. This simplifies considerably network slicing. [draft-hegdeppsenak-isis-sr-flex-algo].

- Traffic is already classified and steered into an SR policy when it arrives to the SR GW.

Finally, I believe that this mechanism is so simple, that it would be trivial to implement it in VPP [https://wiki.fd.io/view/VPP/What_is_VPP%3F] . Hence if the working group believes that this is interesting work and we add it to the I-D, I will analyse how to implement it in this platform.

---

From: Tom Herbert <[email-masked]>
Date: Mon, 26 Feb 2018 12:24:00 -0800

On Mon, Feb 26, 2018 at 12:05 PM, Pablo Camarillo (pcamaril)
<[email-masked]> wrote:
> Hello authors, DMM,
>
>
>
> I have reviewed your I-D on SRv6 for mobile user-plane and I would like to
> make some proposals. I have already discussed and brainstormed the details
> with some of the authors of the draft and they agree to this changes,
> however I would like to get the WG feedback on it.
>
>
>
> Thank you,
>
> Pablo.
>
>
>
> I believe its straightforward to support IPv4 UE traffic by doing SRv6 with
> T.Encaps behavior. Hence, I think this should be documented in the draft.
>
> The encapsulation behavior should be the default one, both for IPv4 and IPv6
> UE traffic. However, a specific provider is allowed to do SRH insertion
> within a controlled domain [draft-voyer-6man-extension-header-insertion-02]
> for UE IPv6 traffic.

Pablo,

That draft received substantial pushback on 6man list. EH insertion is
not allowed by RFC8200 and a host of points were raised why it
shouldn't be allowed. The authors have not responded to this feedback
yet. Also, IMO, the argument that it's okay to do this within a
controlled domain is weak, such an argument could be used to pretty
much justify anything one might do with protocols.

Tom

>
> Also, in order to reduce overhead at the UPFs when using encapsulation, I
> would replace the End.B6 function for a new End.MAP function.
>
> Notice that using encapsulation, if you compare it with today user-plane
> using IPv6/GTP, the result is that SRv6 is just adding 40B of overhead (IPv6
> header), while GTP over IPv6 is using 56B (IPv6, UDP, GTP).
>
>
>
> =======
>
>
>
> With respect to the aggregation mode, aside from using the encapsulation
> mode as described before, I would also like to add a note on the I-D on the
> fact that we can support the aggregation mode without changes in the N2
> interface:
>
> The current I-D for aggregation mode assumes that the gNB (uplink) has
> knowledge of an SR policy that contains all the SIDs belonging to TE, NFV
> and so on. Even though the I-D does not describe how the gNB is retrieving
> this information, I would like to make a statement on the fact that there
> are two alternatives:
>
> B. The N2 interface is not modified. In this case, we signal through the N2
> interface an SRv6 BindingSID, that the gNB is going to resolve into a SID
> list via an SDN controller either using PCEP, reverse DNS lookup or LISP.
>
>
>
> I’m aware that the I-D focuses on the user-plane, however I believe it’s
> important to state this alternatives since it simplifies the adoption and
> reduces impact in the existing mobile architectures (without going into the
> details on the mechanisms for each one of the alternatives of LISP, PCEP,
> reverse DNS-lookup).
>
>
>
> =======
>
>
>
> On the other hand, the current I-D proposes a mechanism for stateless
> interworking with legacy access networks that doesn’t support SRv6 (SGW
> and/or eNB). This mechanism presented in the I-D is limited to IPv4/GTP
> legacy networks. I would like to propose a mechanism to support interworking
> with legacy gNBs that does not support SRv6 but do support IPv6/GTP.
>
> The main benefit comes from the fact that we can leverage an SRv6 BindingSID
> to have remote classification and steering of the UE traffic over an SR
> policy [draft-filsfils-spring-segment-routing-policy].
>
>
>
> In this scenario, I propose that we add the notion of an SR GW -as the
> current stateless interworking node in the I-D-. This SR GW can be either a
> software based platform -e.g. VPP- or any existing router -the mechanism is
> simple and can be supported in existing HW-. This SR GW receives through the
> control plane the SR policies and installs the required Binding SIDs.
>
>
>
> Then, for any UE connecting to a gNB, the N2 interface is going to signal an
> IPv6 address and a TEID. However, the difference is that with this new
> mechanism the IPv6 address that we are going to signal is going to be an
> SRv6 BindingSID instantiated at the SR GW.
>
>
>
> UPF2_in: (Z, A)
> ;; UPF2 maps the flow with SID list <C1, S1, SRGW::TEID, gNB>
>
> - gNB is unchanged and encaps into GTP (N3 interface is not modified). gNB
> only needs to support IPv6 which is currently common in existing
> deployments.
>
> - There is simple state in the uplink at the SR gateway (notice that since
> we are leveraging the aggregation mode, we expect few SR policies on this
> node. SR policies are shared across UEs)
>
> - As soon as the packet leaves the gNB (uplink), the traffic is SR-routed.
> This simplifies considerably network slicing.
> [draft-hegdeppsenak-isis-sr-flex-algo].
>
> Finally, I believe that this mechanism is so simple, that it would be
> trivial to implement it in VPP [https://wiki.fd.io/view/VPP/What_is_VPP%3F]
> . Hence if the working group believes that this is interesting work and we
> add it to the I-D, I will analyse how to implement it in this platform.
>
>
> _______________________________________________
> dmm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dmm
>

---

From: "Voyer, Daniel" <[email-masked]>
Date: Tue, 27 Feb 2018 01:33:44 +0000

Tom,

In respect of this current draft, and highlighted by Pablo’s comments, is to propose adding to this draft the use of encapsulation as default behavior for v4/v6 traffic.

The use of EH insertion is totally the operator’s discretion, within the operator domain if the operator chose to.

I think Pablo’s proposition make sense. Thoughts ?

dan

On 2018-02-26, 3:24 PM, "Tom Herbert" <[email-masked]> wrote:

    Pablo,

    Tom

---

From: Tom Herbert <[email-masked]>
Date: Mon, 26 Feb 2018 19:33:41 -0800

> The use of EH insertion is totally the operator’s discretion, within the operator domain if the operator chose to.
Right, EH insertion could be at an operators discretion. But then so
is deploying proprietary IP protocols, overloading standard protocol
fields with proprietary info, rearranging IP headers, using IPv10,
etc. Doing these sort of things are possible and actually common in
closed networks, but they are not interoperable standards.

I'd also point out that the issues raised in the 6man discussion were
material and raised fundamental questions if header insertion is
robust even in a controlled domain. Even if the argument is that EH
insertion will only ever be done in a controlled domain, these issues
still need to be addressed I think.

Tom

---

From: Arashmid Akhavain <[email-masked]>
Date: Tue, 27 Feb 2018 18:23:51 +0000

Hi Tom,
I believe you are referring to section 4 of RFC8200 where it states:

"Extension headers (except for the Hop-by-Hop Options header) are not
processed, inserted, or deleted by any node along a packet’s delivery
path, until the packet reaches the node (or each of the set of nodes,
in the case of multicast) identified in the Destination Address field
of the IPv6 header."

We copy SID[SL] in to DA as we pass through different segments along the path. 
EH manipulation is allowed as long as we do it at nodes identified by the DA (In SR case this node owns the SID[SL] of course).
Am I missing anything?

Arashmid

-----Original Message-----
From: dmm [mailto:[email-masked]] On Behalf Of Tom Herbert
Sent: 26 February 2018 15:24
To: Pablo Camarillo (pcamaril) <[email-masked]>
Cc: [email-masked]; cf(mailer list) <[email-masked]>; Miya Kohno (mkohno) <[email-masked]>; [email-masked]; Voyer, Daniel <[email-masked]>
Subject: Re: [DMM] SRv6 for Mobile User-Plane

On Mon, Feb 26, 2018 at 12:05 PM, Pablo Camarillo (pcamaril) <[email-masked]> wrote:
> Hello authors, DMM,
>
>
>
> I have reviewed your I-D on SRv6 for mobile user-plane and I would 
> like to make some proposals. I have already discussed and brainstormed 
> the details with some of the authors of the draft and they agree to 
> this changes, however I would like to get the WG feedback on it.
>
>
>
> Thank you,
>
> Pablo.
>
>
>
> I believe its straightforward to support IPv4 UE traffic by doing SRv6 
> with T.Encaps behavior. Hence, I think this should be documented in the draft.
>
> The encapsulation behavior should be the default one, both for IPv4 
> and IPv6 UE traffic. However, a specific provider is allowed to do SRH 
> insertion within a controlled domain 
> [draft-voyer-6man-extension-header-insertion-02]
> for UE IPv6 traffic.

Pablo,

That draft received substantial pushback on 6man list. EH insertion is not allowed by RFC8200 and a host of points were raised why it shouldn't be allowed. The authors have not responded to this feedback yet. Also, IMO, the argument that it's okay to do this within a controlled domain is weak, such an argument could be used to pretty much justify anything one might do with protocols.

Tom

>
> Also, in order to reduce overhead at the UPFs when using 
> encapsulation, I would replace the End.B6 function for a new End.MAP function.
>
> Notice that using encapsulation, if you compare it with today 
> user-plane using IPv6/GTP, the result is that SRv6 is just adding 40B 
> of overhead (IPv6 header), while GTP over IPv6 is using 56B (IPv6, UDP, GTP).
>
>
>
> =======
>
>
>
> With respect to the aggregation mode, aside from using the 
> encapsulation mode as described before, I would also like to add a 
> note on the I-D on the fact that we can support the aggregation mode 
> without changes in the N2
> interface:
>
> knowledge of an SR policy that contains all the SIDs belonging to TE, 
> NFV and so on. Even though the I-D does not describe how the gNB is 
> retrieving this information, I would like to make a statement on the 
> fact that there are two alternatives:
>
> B. The N2 interface is not modified. In this case, we signal through 
> the N2 interface an SRv6 BindingSID, that the gNB is going to resolve 
> into a SID list via an SDN controller either using PCEP, reverse DNS lookup or LISP.
>
>
>
> I’m aware that the I-D focuses on the user-plane, however I believe 
> it’s important to state this alternatives since it simplifies the 
> adoption and reduces impact in the existing mobile architectures 
> (without going into the details on the mechanisms for each one of the 
> alternatives of LISP, PCEP, reverse DNS-lookup).
>
>
>
> =======
>
>
>
> interworking with legacy access networks that doesn’t support SRv6 
> (SGW and/or eNB). This mechanism presented in the I-D is limited to 
> IPv4/GTP legacy networks. I would like to propose a mechanism to 
> support interworking with legacy gNBs that does not support SRv6 but do support IPv6/GTP.
>
> The main benefit comes from the fact that we can leverage an SRv6 
> BindingSID to have remote classification and steering of the UE 
> traffic over an SR policy [draft-filsfils-spring-segment-routing-policy].
>
>
>
> current stateless interworking node in the I-D-. This SR GW can be 
> either a software based platform -e.g. VPP- or any existing router 
> -the mechanism is simple and can be supported in existing HW-. This SR 
> GW receives through the control plane the SR policies and installs the required Binding SIDs.
>
>
>
> - gNB is unchanged and encaps into GTP (N3 interface is not modified). 
> gNB only needs to support IPv6 which is currently common in existing 
> deployments.
>
> - There is simple state in the uplink at the SR gateway (notice that 
> since we are leveraging the aggregation mode, we expect few SR 
> policies on this node. SR policies are shared across UEs)
>
> trivial to implement it in VPP 
> [https://wiki.fd.io/view/VPP/What_is_VPP%3F]
> . Hence if the working group believes that this is interesting work 
> and we add it to the I-D, I will analyse how to implement it in this platform.
>
>

---

From: Tom Herbert <[email-masked]>
Date: Tue, 27 Feb 2018 11:14:35 -0800

> EH manipulation is allowed as long as we do it at nodes identified by the DA (In SR case this node owns the SID[SL] of course).
Arashmid,

When the SR is present in a packet that behavior is correct and
complies with RFC8200-- the SR EH is only processed by nodes that are
identified in the destination address. The question is how did the SR
EH get set in the packet in the first place. If a host sourced a
packet with extension headers then it conforms to RFC8200. Also, if an
intermediate device performs encapsulation, say IP in IP, and sets the
EH in the outer header then that is also conforms to RFC8200 since the
device is taking the role of host in sourcing an encapsulated packet.
However, if an intermediate device inserts an extension header into an
IPv6 packet without encapsulation that is where the problem is. I
think Pablo's comment was that this should be allowed in controlled
domains.

Tom