Hi Arashmid, slowly we move ahead ;-) but let's increase the pace to have a good picture before next meeting and solid material to discuss at IETF102. Inline, please [ml2].
From: Arashmid Akhavain [mailto:arashmid.akhav...@huawei.com] Sent: Donnerstag, 7. Juni 2018 20:19 To: Marco Liebsch; Sri Gundavelli; dmm@ietf.org Subject: RE: draft-gundavelli-dmm-mfa Hi Marco, Sorry about my tardy reply. Please see my comments inline [Arashmid] From: Marco Liebsch [mailto:marco.lieb...@neclab.eu] Sent: 11 May 2018 11:47 To: Arashmid Akhavain <arashmid.akhav...@huawei.com>; Sri Gundavelli <sgund...@cisco.com>; dmm@ietf.org Subject: RE: draft-gundavelli-dmm-mfa Hi Arashmid, please find my take inline [ml]. From: dmm [mailto:dmm-boun...@ietf.org] On Behalf Of Arashmid Akhavain Sent: Donnerstag, 3. Mai 2018 23:38 To: Sri Gundavelli; dmm@ietf.org<mailto:dmm@ietf.org> 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. [Arashmid] Do you mean that we move these functions into the AG itself? If so, then we need a mechanism to move say metering data from one AG to another as MN moves around. [ml2] Today the mobile gateway has all these functions and if we move that gateway to the edge and name it AG, yes, then it's all there. Sri's draft assumes a current AG for a mobile node as well as 1..N correspondent data plane nodes, which are in the proximity of the 1..N correspondent services/nodes. If the correspondent node is a mobile, then this may be an AG, too, if it's a service, e.g. in a data center, then it may be a policy router, PE router or something else. It's up to the control plane to decide which policy to enforce on which of these data plane nodes. Where metering happens depends on the aggregate and probably that needs to happen on the AG for down and uplink. However, other functions, such as QoS enforcement or chargeable event monitoring, may happen on the correspondent side already for downlink traffic. 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? [Arashmid] Yes, it allows policies to be enforced right at the edge. I think we should capture this in the draft. But let's discuss what happens to policies (both uplink and downlink) as MN moves around. [ml2] sure, we can add more on this. 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. [Arashmid] If I am not mistaken, while things are settling down, .the old AG can forward the packets to the new one as well. Yes we might end up with out of order packets due to path latency differentials. But as you said, proactive measures can ease up the situation. Should this be reflected in the draft? [ml2] we focus on the basic principles right now but appreciate such feedback. So far I can imagine some smartness on the control plane to enable a proactive AG relocation, possible with the help of available handover support extensions, such as end marker packets, which in this case should work in a control- data plane separated deployment. What do you think? 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? [Arashmid] I was just thinking about adding an example for SRv6 since the draft singles it out. But a statement regarding ILA and LISP would certainly help to highlight the versatility of the approach. [ml2] I am sure we'll find a good place in the draft where we can address other data plane protocols. 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. [Arashmid] Yes, I agree. Thank you for clarifying. 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. [Arashmid] The MN is usually provided with a paging cycle upon its initial attachment. The MN in dormant mode then wakes up temporarily at each cycle to check paging. The dormant monitoring agent in AG can detect MN and update the system with the new location. No? [ml2] Having the dormant monitoring function in the AG makes sense and it will work. 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. [Arashmid] Are we talking about some sort of inactive time out period? [ml2] it could be a soft state that expires or gets explicitly removed in case the state is not valid anymore. What that means for the control plane load is to be further looked at. marco In the view of reducing control plane load, other events should be considered to remove states. Best regards, marco
_______________________________________________ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm
