Subject: Re: [DMM] SRv6 for Mobile User-Plane

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

(+ Charlie)

From: dmm <[email-masked]> on behalf of "Pablo Camarillo (pcamaril)" <[email-masked]>
Date: Monday, 26 February 2018 at 21:05
To: "[email-masked]" <[email-masked]>
Cc: "Voyer, Daniel" <[email-masked]>, "cf(mailer list)" <[email-masked]>, "Miya Kohno (mkohno)" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: [DMM] SRv6 for Mobile User-Plane

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: Satoru Matsushima <[email-masked]>
Date: Mon, 26 Feb 2018 23:46:33 -0500

Pablo,

First of all, thank you for your thorough review on the draft, and concrete proposal to improve it.
I think I agree almost on the three proposals. Let me comment on some of your points.

> [...snip...]

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

Yes.

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

So ‘End.MAP’ function you proposed looks that the dest address in outer header works as last SID in SRH but just one SID doesn’t require SRH in the packet over the wire. If it corrects, I think it’s a good idea. I’d appreciate if you can contribute text and pseudo code for End.MAP to the draft. I tend to replace basic mode with it.

> 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…

That sounds make sense. I’ve studied and shared a comparison of total overhead size for various deployment cases. That study shows it as well.

> 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, r…

Maybe you have seen End.B6 defined as L2-anchor function in the section of aggregate mode. I think that the current draft doesn’t cover the case of N2 no-change. But I have to admit that the text need to be more clear to mention for that. Any text for it would be really welcome.

> 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 architecture…

I think that we are on the same page. Deploying srv6 for mobile user-plane provides programmability of data-path for not only existing style of mobility management, but also any other type of optimization logics from various aspects, such as ID-LOC, ETSUN for example.

> 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-po…

Yes indeed. IPv6/GTP case should be supported in addition to the IPv4/GTP case.

> The overall workflow is the following:

That looks good. Can you propose texts, pseudo code and diagram for that?

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

Don’t you need to care about TEID at SRGW in aggregate mode?
I think it is okay for uplink in basic mode since it allocates SID per tunnel.

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

That looks it works.

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

Yes, it enables legacy networks can be integrated into flexible/programmable platform.
BTW do you think that it could also be applicable for basic mode? I think your intention that applying SRGW to such case might not motivate operators to do that since no additional value out there. But It would make user plane transition easy from GTP-U to SRv6. Even you can keep N2 as it is to support aggregate mode, N4 need to be aware for it. Keeping N4 or previous generation’s c-plane as it is makes the hurdle much lower for the transition.

> 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…

BTW, do you have any ideas for naming of the functions?
Some SRv6 guys suggest to reserve namespace of End.M** for mobile specific SRv6 functions.

Cheers,
--satoru

---

From: Miya Kohno <[email-masked]>
Date: Tue, 27 Feb 2018 15:51:23 +0900

It sounds that IP network was envisaged to be monolithic and seamless. But
at least in the current best practice, filtering and data plane source
validation are done at the edge of controlled administrative domain. So the
basic assumption may be different?

Miya

On Tue, Feb 27, 2018 at 1:46 PM, Satoru Matsushima <
[email-masked]> wrote:

> > 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.
>
> Yes.
>
>
> > 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.
> So ‘End.MAP’ function you proposed looks that the dest address in outer
> header works as last SID in SRH but just one SID doesn’t require SRH in the
> packet over the wire. If it corrects, I think it’s a good idea. I’d
> appreciate if you can contribute text and pseudo code for End.MAP to the
> draft. I tend to replace basic mode with it.
>
>
> >
> > 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).
>
> That sounds make sense. I’ve studied and shared a comparison of total
> overhead size for various deployment cases. That study shows it as well.
>
>
> >
> > =======
> >
> > 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.
>
>
> Maybe you have seen End.B6 defined as L2-anchor function in the section of
> aggregate mode. I think that the current draft doesn’t cover the case of N2
> no-change. But I have to admit that the text need to be more clear to
> mention for that. Any text for it would be really welcome.
>
>
> >
> > 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).
>
> I think that we are on the same page. Deploying srv6 for mobile user-plane
> provides programmability of data-path for not only existing style of
> mobility management, but also any other type of optimization logics from
> various aspects, such as ID-LOC, ETSUN for example.
>
>
>
> >
> > =======
> >
> > 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].
> BTW do you think that it could also be applicable for basic mode? I think
> your intention that applying SRGW to such case might not motivate operators
> to do that since no additional value out there. But It would make user
> plane transition easy from GTP-U to SRv6. Even you can keep N2 as it is to
> support aggregate mode, N4 need to be aware for it. Keeping N4 or previous
> generation’s c-plane as it is makes the hurdle much lower for the
> transition.
>
>
> >
> > 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: Miya Kohno <[email-masked]>
Date: Tue, 27 Feb 2018 16:13:00 +0900

Sorry, replied to the wrong message. This was regarding the SRH insertion
topic..

On Tue, Feb 27, 2018 at 3:51 PM, Miya Kohno <[email-masked]> wrote:

>> > 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:
>> > 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.
>>
>>
>> Maybe you have seen End.B6 defined as L2-anchor function in the section
>> of aggregate mode. I think that the current draft doesn’t cover the case of
>> N2 no-change. But I have to admit that the text need to be more clear to
>> > 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).
>>
>> I think that we are on the same page. Deploying srv6 for mobile
>> user-plane provides programmability of data-path for not only existing
>> style of mobility management, but also any other type of optimization
>> logics from various aspects, such as ID-LOC, ETSUN for example.
>>
>>
>>
>> >
>> > =======
>> >
>> trivial to implement it in VPP [https://wiki.fd.io/view/VPP/W
>> hat_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: "Pablo Camarillo (pcamaril)" <[email-masked]>
Date: Wed, 28 Feb 2018 16:03:42 +0000

Hi Satoru,

Thank you for your detailed comments. Replies inline [PC].

Cheers,

Pablo.

On 27/02/2018, 05:46, "Satoru Matsushima" <[email-masked]> wrote:

    Pablo,

    Yes.

[PC]: I have proposed some text with the packet workflow in the github repository for this draft. Please review it.

[PC]: Your understanding is correct. I have added the pseudocode of this function in the github repository for this document.

[PC]: Yes. Your study is very complete and indeed it was showing the lower overhead of SRv6. Thank you for taking the time to elaborate it. I think it’s worth keeping your study.

[PC]: Indeed, you are right. The current text is ambiguous. I have proposed some text clarifying this in the github repository for this draft.

[PC]: We are in the same page. SRv6 is providing the flexibility and scalability in the data-path. Then many other techniques as ID-LOC for example might leverage it in the future to build even more interesting stuff.

[PC]: I have proposed some text, pseudocode and diagram in your github repository. Please review it. Thank you

[PC]: For the basic mode, yes it is ok. For the aggregate mode, we can ignore the TEID since we don’t have scaling issues on the BSID. A BSID is an indirecton to an SR policy, and hence we can have many BSIDs pointing to the same SR policy. Hence I would not expect any scalability issue here.

    That looks it works.

[PC]: Yes, I agree with you. Both this mechanism, as well as the already interworking solution documented in the I-D, can work both for the basic mode as well as the aggregate one. I have proposed some text in the github repo for this I-D to clarify it.

[PC]As co-author of the SRv6 Network Programming draft I support that initiative. All the functions which are only to be used for mobility should indeed be End.M.*****.

However, this does not apply to all of your functions. For example, the rate limiting function it’s necessary in the use-case of mobility but it might also be used in different contexts. For this one I would not name it under End.M.***.

For the rest of the functions indeed they should be End.M.**. I have proposed some of this renaming in the github repository for this draft. Please check it out.

    Cheers,

    --satoru