Folks, at IETF91 we received the valid comment to converge on a definition of the term 'anchor'. In the FPSM discussion, we so far distinguished Data-Plane Anchor (DPA), traditionally a downlink encap function, Data-Plane Node (DPN), which is more located in the access to terminate tunnels, and regular transport nodes. Another comment was about a scenario where a single flow may traverse multiple DPAs on its way to the MN.
I'd like to propose and discuss the following: In a decentralized data-plane and a control-/data-plane separated deployment, I consider it a reasonable assumption that each of the so far unambiguously named data-plane nodes can take the role of the other. So, we may solely refer to a single type of function, e.g. Data-Plane Anchor (DPA), which receives policies from the Control-Plane. For a certain deployment, it's the Control-Plane that determines the role and associated policies for each involved DPA. Data-Plane nodes are agnostic to the role they play in mobility management. Control-Plane determines the role of each DPA according to the preferred deployment and configures the policies accordingly. I think such assumption allows flexible deployment and eases description in our specifications. I am not good in drawing ASCII, but I gave it a try (for downlink operation only). Using PMIP6 terms, the middle-DPA in the figure below serves as kind of LMA, left DPA as MAG, right DPA (one or multiple) may enforce per-host rules for traffic steering. Would be happy to get your opinion on this proposal. marco +--------------------------+ | Control-Plane | +--------------------------+ | | | | | | | | | \ / V V V +--+ -o- +---+ +---+ +---+ +--+ |MN| ---- |---|DPA|<========|DPA|<----|DPA|<--|CN| +--+ | +---+ +---+ +---+ +--+ Rules: Rules: Rules: Decap, Encap, host-route Forward Forward, qos
_______________________________________________ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm