Hi John, thanks for the feedback. Please see inline [ml].
From: John Kaippallimalil [mailto:[email protected]] Sent: Freitag, 28. September 2018 21:59 To: Marco Liebsch; [email protected] Subject: RE: extended data plane discussion - N6 traffic steering Hi, Marco, N6 aspects are generally underspecified in 3GPP - as it is an interface to an external data network (IP network) but sometimes have specific route and QoS requirements. Descriptions in a draft like this can help to clarify aspects that are not well specified for a local N6 interface. [ml] yes, we thought the same. This was a quick read - assuming that the focus is on local network N6, the discussion in section 4 about traffic treatment looks good. The abstract does confuse me a bit. It goes over GTP-U and other motivation around anchoring, etc. - N3, N9 (interfaces inside 5G system). While the focus of the draft (section 4) seems to be about N6. [ml] Ok, this document mainly addresses IETF folks so far and the abstract tries to position this draft within in a set of other drafts of the data plane discussion. Most drafts discuss the mobile data plane on N9 and N3 and the use of protocol candidates as alternative to the GTP overlay This draft complements the data plane discussion by including N6. Having the possibility to apply policies to N6 traffic treatment enables very interesting use cases as all data plane segments from an application server's network to the UE is covered. However, the abstract may be adjusted to be more focusses in future revisions. That's do be discussed. Some more specific comments: 1. in section 3.2 - the UE to edge data network use case is clear, i.e.., the need for traffic steering policy (along with description in section 4) However, use case UE to UE communication is not clear. If this is about optimal routing between 2 UEs in a 3GPP network, that would be in the scope of 3GPP. If it is UEs in 2 PLMNs, the solution would need much more than just traffic steering. [ml] I see and agree that UE-to-UE seems to be a bit off-topic. It's more to be complete and to cover the UE-to-service as well as the UE-to-UE communication as it's addressed in draft-gundavelli-dmm-mfa-01<https://datatracker.ietf.org/doc/draft-gundavelli-dmm-mfa/>. Dependent on the use cases for UE-to-UE communication, N6 policies are needed. 3GPP has an interface in scope, which can be used, this is N4. Maybe only the semantics need to be extended in support of the target use case. Key aspect of draft-fattore is to cover a policy control interface to the data network, which holds the DPN/AS for N6 policing. Ad such interface is not covered in 3GPP- 2. Local data network/N6 issues around asymmetric return route are not discussed in the draft. In 5G, UE flows to edge network AS can bypass UPF-PSA (IP anchor) as a result of an intermediate UPF routing directly to a local UPF-PSA (not IP anchor) using flow filters. This can result in asymmetric paths - where the return path is still via the IP address anchor UPF-PSA. Note that this is different from N6 next to UPF-PSA that is an IP anchor (Figures 3 & 4 and the descriptions do not cover this) [ml] well, it's covered but maybe we need to spend a few more sentences to make it more obvious. So far we write that downlink traffic should traverse the most suitable UPF_a in case of multiple choices. More text could describe that asymmetric routing can be avoided by solutions in this draft. Asymmetry here is uplink to a local data network traverses UPF_i/UPF_a2, whereas downlink traffic from the local data network traverses UPF_a1. This is what you mean, correct? 2. Section 5 /only includes control plane aspects and binding between 3GPP and N6 control plane (AF ->DPN) There would probably be some specification for the user plane as well. For example - the N6 user plane is probably an IP tunnel between local UPF-PSA and AS? And what if there is a load balancer that removes the tunnel before selecting the AS instance. The return path would not work as expected (i.e., asymmetric path). Should there be requirements to LB - to retain the outer source IP address? Or some explicit header (like NSH) for the AS to route return packet to local UPF (not the anchor). [ml] So far we thought about keeping the protocol out of N6 for traffic steering, which can be ILA or SRv6, or any encap protocol. For us it's just a question of traffic treatment policies. Any of them allows us to achieve the flexibility we want. Important is 'how' and 'when' policies can be enforced on data networks' DPN/AS. But we can include a protocol example as well, no problem. 4. Motivation and introduction sections have a lot of references that are perhaps not needed in the context of the N6 focus of this draft. I would be willing to clarify further and help with details of the draft. [ml] sounds good. Thanks, John. I hope we can schedule a few side meetings in Bangkok. To elaborate on some more details. Best regards, marco BR, John From: dmm [mailto:[email protected]] On Behalf Of Marco Liebsch Sent: Thursday, September 20, 2018 2:37 PM To: [email protected] Subject: [DMM] extended data plane discussion - N6 traffic steering Folks, we submitted a new ID which extends the current data plane discussion from N9/N3 to N6 interfaces of the mobile system's architecture. We could discuss the use cases, problem statement and principles with some before submission, but post this initial draft to get the larger community's feedback before we update with more details and the received feedback. Your comments are appreciated. Best regards, marco Name: draft-fattore-dmm-n6-cpdp-trafficsteering Revision: 00 Title: Control-/Data Plane Aspects for N6 Traffic Steering Document date: 2018-09-20 Group: Individual Submission Pages: 12 URL: https://www.ietf.org/internet-drafts/draft-fattore-dmm-n6-cpdp-trafficsteering-00.txt Status: https://datatracker.ietf.org/doc/draft-fattore-dmm-n6-cpdp-trafficsteering/ Htmlized: https://tools.ietf.org/html/draft-fattore-dmm-n6-cpdp-trafficsteering-00 Htmlized: https://datatracker.ietf.org/doc/html/draft-fattore-dmm-n6-cpdp-trafficsteering Abstract: Current standardization effort on the evolution of the mobile communication system reconsiders the mobile data plane protocol. The IETF DMM Working Group has work that proposes and analyzes various protocols as alternative to the GPRS Tunneling Protocol for User Plane (GTP-U) for an overlay deployment in between the mobile device's assigned data plane anchor and its current radio base station, which are denoted as N9 and N3 interfaces. In the view of some future deployment and the original intent per the very early DMM WG charter, a mobile device's data plane anchor may be highly distributed and re-selected for optimization throughout a mobile device's communication with one or more correspondent services. Such re-configuration has impact on the packet routing in between the mobile device's data plane anchor and the one or multiple data networks hosting the services, which is denoted as N6 interface. This draft proposes and discusses a solution to control, setup and maintain traffic treatment policy on the cellular communication system's N6 interface while taking the UE's PDU session settings per the cellular system's control plane, such as QoS and locator information, into account.
_______________________________________________ dmm mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmm
