Subject: [DMM] draft-gundavelli-dmm-mfa

From: Arashmid Akhavain <[email-masked]>
Date: Thu, 3 May 2018 21:38:24 +0000

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.

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.

3- An example with SRv6 and/or SRv6 with ID-LOC might serve the document well. 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?

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.

6- Page 14, figure 5: Need to change MFA-NMA-->MFA-MNA, and MFA-CAN--> MFA-CNA in the figure.

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?

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.

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.

---

From: "Sri Gundavelli (sgundave)" <[email-masked]>
Date: Thu, 3 May 2018 23:39:34 +0000

Hi Arashmid,

Thanks for the review feedback !! I will let Marco respond to this thread.

Regards
Sri

From: Arashmid Akhavain <[email-masked]<mailto:[email-masked]>>
Date: Thursday, May 3, 2018 at 2:38 PM
To: Sri Gundavelli <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: draft-gundavelli-dmm-mfa

Hi Sri,

Best regards,
Arashmid

---

From: Marco Liebsch <[email-masked]>
Date: Fri, 11 May 2018 15:47:10 +0000

Hi Arashmid,

please find my take inline [ml].

From: dmm [mailto:[email-masked]] On Behalf Of Arashmid Akhavain
Sent: Donnerstag, 3. Mai 2018 23:38
To: Sri Gundavelli; [email-masked]
Subject: [DMM] draft-gundavelli-dmm-mfa

Hi Sri,

Best regards,
Arashmid

[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?

[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.

[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?

[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.

[ml] Thanks for spotting this, we'll correct in the update.

[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.

[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.

[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