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 https://www.ietf.org/mailman/listinfo/dmm
