Sorry, replied to the wrong message. This was regarding the SRH insertion topic..
On Tue, Feb 27, 2018 at 3:51 PM, Miya Kohno <miya.ko...@gmail.com> wrote: > 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 < > satoru.matsush...@gmail.com> 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. >> >> >> > 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. >> >> >> 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: >> > 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. >> >> >> > >> > 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]. >> >> Yes indeed. IPv6/GTP case should be supported in addition to the IPv4/GTP >> case. >> >> >> >> > >> > 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: >> >> That looks good. Can you propose texts, pseudo code and diagram for that? >> >> >> > >> > 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 >> > >> >> 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. >> >> >> >> > 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) >> >> That looks it works. >> >> >> > >> > 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. >> >> 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/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. >> >> 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 >> _______________________________________________ >> dmm mailing list >> dmm@ietf.org >> https://www.ietf.org/mailman/listinfo/dmm >> > >
_______________________________________________ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm
