Hi Arashmid, please find my take inline [ml].
From: dmm [mailto:[email protected]] On Behalf Of Arashmid Akhavain Sent: Donnerstag, 3. Mai 2018 23:38 To: Sri Gundavelli; [email protected] Subject: [DMM] draft-gundavelli-dmm-mfa Hi Sri, Please find below some questions and comments. Best regards, Arashmid 1- This technique certainly eliminates the need for fixed anchor points from the data plane point of view. However, it is not clear what happens to other functions provided by the existing 3GPP fixed anchor points. It should be possible to program the nodes for these additional functions as well. I think a list of existing functions or those required by 5G in 3GPP would be a good starting point for the discussion. [ml] Good point, if we think about the MN's AG is a traditional data plane anchor with some extensions that enable it to be changed per the operation described in this draft, all functions may move to the edge where the AG is deployed. That may work for metering, paging initiation and QoS in case downstream labels are required for compatibility with the RAN. But then there is no QoS enforcement in a large part of the network in between the CN and the MN's AG. Hence, the approach would benefit from enforcement of downlink QoS rules on the CN's anchor /CNA. What do you think? 2- Performance is another issue. How fast can we detect and then program MFA nodes? This is the issue that applies to all different approaches. I think performance merits a section in the draft. [ml] The draft depicts a reactive approach, which should work and in the worst case it suffers from some packets' re-ordering after enforcing the optimized route. Pro-active extensions should be possible and improve that situation. 3- An example with SRv6 and/or SRv6 with ID-LOC might serve the document well. Appendix? [ml] Are you asking for details about other data plane protocols that are currently being discussed in the IETF? Since the MFA controller enforces policies in the network edges (MN and CN side), these policies can result also in ILA or LISP mappings per an ingress node operation for the packets, no? The current draft states at the beginning that it's not dependent on a particular data plane but it focuses on SRv6 so far. Which of the alternative data plane protocols you think should be covered in the appendix? 4- Page 5, end of MFA-MNA paragraph: " Typically, the MFA-MNA function will be collocated with the UPF in the 3GPP 5G system architecture." Couldn't it be collocated with the gNB as well? Or did you purposely took gNB out to avoid touching the N3 interface? [ml] The draft is supposed to be independent of a particular access network.. Move the MNA closer to the access network and you may run your last mile protocol on a 1meter patch cable to the NB. That's loose coupling and keeps the interface between control plane and the MNA decoupled from the interface between NB and control plane. Of course you may collocate and run the MNA tightly coupled with any access-specific node and even merge the interfaces to the control plane. 5- When correspondent nodes are mobile themselves. e..g. UE-UE communication, isn't the MFA-CNA is just another MFA-MNA? Some clarification in the draft might come handy. [ml] Sure. To differentiate between policy enforcement points on the data plane which are associated with the MN or the CN we chose these abbreviations. They may be of the same type of node. 6- Page 14, figure 5: Need to change MFA-NMA-->MFA-MNA, and MFA-CAN--> MFA-CNA in the figure. [ml] Thanks for spotting this, we'll correct in the update. 7- How does paging work? Not sure about this one, but is it possible for a UE to go to be idle (a new inactive state has also been added in the spec) in one gNB and wake in another that connects to a different first hop router? [ml] adopting the IETF DMM terminology of past work ;-), the dormant monitoring agent could be in the anchor or current MN-AG and detect packets that are addressed to a MN in dormant mode. Different options exist here. Also, in case of a reactive mode per this version of the draft, the MN's dormant state may be known only to the MFA NC, which initiates paging instead of updating the CN's AG and the MN's current AG (which is not known as the MN is in dormant mode..). Multiple good or worse approaches are possible and this initial draft does not focus on them yet as we want to sketch the key principles first and solicit feedback. 8- Page 19 after step 10: It might be useful to talk about how and when MFA-CN removes the rule for H1::/64 from AG-2. I guess it is something along what described in 4.3. [ml] Definitely, more details need to be covered. Also here, multiple options are possible, either remove them after the data session terminated, or keep them until the MN enters dormant mode. 9- Page 20, section 4.3, step 1: Might be useful to indicate how the system would know when a flow is inactive and hence the rules associated with it are no longer need. [ml] Yes, I agree. Another question is whether data flow termination should serve as only indication to remove these states. In the view of reducing control plane load, other events should be considered to remove states. Best regards, marco
_______________________________________________ dmm mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmm
