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 protected]> wrote: On Mon, Feb 26, 2018 at 12:05 PM, Pablo Camarillo (pcamaril) <[email protected]> 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. > > 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. > > > _______________________________________________ > dmm mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/dmm > _______________________________________________ dmm mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmm
