Hi Satoru,
Thank you for your detailed comments. Replies inline [PC].
Cheers,
Pablo.
On 27/02/2018, 05:46, "Satoru Matsushima" wrote:
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.
[PC]: I have proposed some text with the packet workflow in the github
repository for this draft. Please review it.
> 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:
> UEgNBUPF1UPF2
>
> 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
> 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.
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.
[PC]: Your understanding is correct. I have added the pseudocode of this
function in the github repository for this document.
>
> 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.
[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.
>
> ===
>
> 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.
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.
[PC]: Indeed, you are right. The current text is ambiguous. I have proposed
some text clarifying this in the github repository for this draft.
>
> 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.
[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.
>
> ===
>
> 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.
