Re: [DMM] Change "Port" to ? [ was Re: I-D Action: draft-ietf-dmm-fpc-cpdp-05.txt]

Hello Charlie,

If we keep the port term, your proposal is very good. I support the adoption of the vport term.

Thanks and best regards,
Marco

On 25 Jan 2017, at 19:14, Charlie Perkins <charles.perkins@earthlink.net<mailto:charles.perkins@earthlink.net>> wrote:

Hello Marco,

What would you think about replacing the term "port" by "virtual port", which would usually be shortened to "vport" (or "Vport")?

I think it would have several benefits:

  *   it seems intuitively appealing, at least to me
  *   it avoids the unacceptable clash with the traditional meanings of the word "port"
  *   it fits well with my understanding of "data-plane node" and "context".
  *   it's a relatively easy editorial change to the draft

Regards,
Charlie P.

On 1/17/2017 1:05 AM, Marco Liebsch wrote:

The meaning of port changed throughout the evolution of this draft. Up to version 3 a port was a
forwarding construct that binds traffic selectors to traffic treatment actions. Any other term,
e.g. rule, could have made it. These are created (attach), modified (handover) or deleted per
the mobile node's location, IP address, etc.

>From version 4, what has been a port before is now more the 'context' structure, whereas
the inherited port term is used to group policies and bind them to context. A different term would be more obvious.
Policy group binding (PGB) or even the proposed FPG are ok, though I am a bit puzzled why Flow appears in here.

marco

-----Original Message-----
From: dmm [mailto:dmm-bounces@ietf.org] On Behalf Of Satoru Matsushima
Sent: Donnerstag, 29. Dezember 2016 03:31
To: Charlie Perkins
Cc: dmm@ietf.org<mailto:dmm@ietf.org>
Subject: [DMM] Change "Port" to ? [ was Re: I-D Action: draft-ietf-dmm-fpc-cpdp-05.txt]

Hi Charlie,

First, thank you for raising this point to be discussed. I second that it needs to be more intuitive.

I am in the process of reviewing the FPC document.  It is an important document and will be foundational for subsequent work in [dmm].

Yep, I really appreciate that you see this draft as a foundation for further works.

 I would like to suggest a change in terminology.  I think the way "Port" is currently defined in the document is very confusing, because it is not very intuitively related to the traditional uses of "port" as in TCP, or in switches.

Right. The coauthors had discussed this point many times but, me at least, couldn’t figure out more appropriate term instead of that so far...

As I understand it, "Policy" lives on the control plane side of the interface, and "Port" is intended to denote a concept that is important on the data plane side of the interface.

If you mean “control plane” as abstracted data-plane model in FPC agent,  I think that both “Policy” and “Port” exist on the control plane. In the current version of draft, Port is defined as “A set of forwarding policies.”

 "Flow" is another word that is closely tied to the data plane, and it seems to me that as currently defined in the document a "Port" is a collection of flows that correspond to a specific Policy or Policy Group.

For me, “Flow” seems not to exactly indicate specific policy applied flow. It could indicate flow(s) which just have same characteristics in natural.

So, I would like to propose that the word "Port" should be replaced by the term "Flow Group".  Another alternative would be "Flow Policy Group", which could then be abbreviated FPG. However, the latter has the perhaps undesirable effect of tying the word "Policy" to a data-plane concept.

I think that the successor of port should keep same meaning of “A set of forwarding policies.” In that sense, FPG sounds make sense to me.

in another aspect, we use Context as abstracted mobility session. I can see this as source of flow(s) and it looks already represent a group of those flows which are received and sent on each node. Attaching Context to a Port intends that applying a set of policies to a group of flows which are attributed to the context.

Thanks for any comments on this proposal to modify the terminology.

I think it is important to make the terminology as unambiguous and intuitive as we possibly can, especially because the document is necessarily written at a high level of abstraction.

Yes, I fully agree with you, let’s keep the discussion.

Regards,
Charlie P.

Best regards,
--satoru

_______________________________________________
dmm mailing list
dmm@ietf.org<mailto:dmm@ietf.org>
https://www.ietf.org/mailman/listinfo/dmm