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

2017-01-31 Thread Marco Liebsch 
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 
mailto:charles.perk...@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-boun...@ietf.org] On Behalf Of Satoru Matsushima
Sent: Donnerstag, 29. Dezember 2016 03:31
To: Charlie Perkins
Cc: 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
https://www.ietf.org/mailman/listinfo/dmm


___
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

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

2017-01-31 Thread Bertz, Lyle T [CTO] 
+1

From: dmm [mailto:dmm-boun...@ietf.org] On Behalf Of Marco Liebsch
Sent: Tuesday, January 31, 2017 3:04 AM
To: Charlie Perkins 
Cc: dmm@ietf.org
Subject: 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 
mailto:charles.perk...@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-boun...@ietf.org] On Behalf Of Satoru Matsushima

Sent: Donnerstag, 29. Dezember 2016 03:31

To: Charlie Perkins

Cc: 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

https://www.ietf.org/mailman/listinfo/dmm




This e-mail may contain Sprint proprietary information intended for the sole 
use of the recipient(s). Any use by others is prohibited. If you are not the 
intended recipie

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

2017-01-31 Thread Bales, Mark [CTO] 
+1

From: dmm [mailto:dmm-boun...@ietf.org] On Behalf Of Bertz, Lyle T [CTO]
Sent: Tuesday, January 31, 2017 7:56 AM
To: Marco Liebsch ; Charlie Perkins 

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

+1

From: dmm [mailto:dmm-boun...@ietf.org] On Behalf Of Marco Liebsch
Sent: Tuesday, January 31, 2017 3:04 AM
To: Charlie Perkins 
mailto:charles.perk...@earthlink.net>>
Cc: dmm@ietf.org
Subject: 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 
mailto:charles.perk...@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-boun...@ietf.org] On Behalf Of Satoru Matsushima

Sent: Donnerstag, 29. Dezember 2016 03:31

To: Charlie Perkins

Cc: 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] Review of draft-ietf-dmm-4283mnids-04

2017-01-31 Thread Dale Worley 
Reviewer: Dale Worley
Review result: Ready with Issues

I am the assigned Gen-ART reviewer for this draft.  The General Area
Review Team (Gen-ART) reviews all IETF documents being processed
by the IESG for the IETF Chair.  Please treat these comments just
like any other last call comments.

For more information, please see the FAQ at
.

Document:  draft-ietf-dmm-4283mnids-04
Reviewer:  Dale R. Worley
Review Date:  31 Jan 2017
IETF LC End Date:  2 Feb 2017
IESG Telechat date:  16 Feb 2017

Summary:

   This draft is on the right track but has open issues,
described
   in the review.

Technical issues:

1. The Introduction states

   Other types of identifiers are in
   common use, and even referenced in RFC 4283.

For the reader's sanity, some sort of accounting needs to be made of
these "other types of identifiers", especially because each type of
identifier needs an identifier type number.  The text in 4283 is

   Some examples of identifiers
   include Network Access Identifier (NAI), Fully Qualified Domain
Name
   (FQDN), International Mobile Station Identifier (IMSI), and Mobile
   Subscriber Number (MSISDN).

Are there any other types "in common use"?

- NAI (type 1) is defined by 4283.
- Fully Qualified Domain Name (FQDN) seems not to be specified
- International Mobile Station Identifier (IMSI) (type 3) is defined
in
  this draft
- Mobile Subscriber Number (MSISDN) seems not to be specified

2. Is it intended to have an IMEI identifier type?  The introduction
mentions an IMEI type, but there is no specification for it, nor is
there an identifier type number assigned for it.

   ... types for IMSI
   [ThreeGPP-IDS], P-TMSI [ThreeGPP-IDS], IMEI [ThreeGPP-IDS], and
GUTI
   [ThreeGPP-IDS].

Initially I suspected it was it was present in an earlier revision
and
then later deleted without this reference being updated.  But all
versions of draft-ietf-dmm-4283mnids and its predecessor
draft-perkins-dmm-4283mnids mention IMEI in this way as one
identifier
type, but none specify it in any way.  The only discussion I can find
on the DMM mailing list of IMEI is:

   
https://mailarchive.ietf.org/arch/msg/dmm/pNmtaq6-JOQ4RuXy_D7Zc2JgvYk/?qid=d29575f767ce67a1e67a7767008ee6af

From: Marco Liebsch 
To: DMM
Date: Wed, 10 September 2014 13:29 UTC
Re: [DMM] regarding the re-chartering..

It seems the MNID is somehow overloaded to carry both,
node-specific
IDs, e.g. MAC, as well as subscriber IDs, which is the IMSI.
There may be value in adding the IMEI to the list of possible
types of
node-specific IDs. 

Either the presence of IMEI in this list is a simple mistake that has
persisted in all versions of the draft, or specifying IMEI has always
been intended but has always been overlooked.

3. The definition of identifier types for both EUI-48 and EUI-64
suggests that it might be desirable to define an identifier type for
arbitrary hardware (link-level) addresses.  It seems that the natural
differentiator for that purpose is the "hardware type" used in ARP,
so
a EUI-48 address would be represented as

MN identifier type (one octet) 5 (say)
hardware type (two octets) 1
EUI-48 (six octets)

and an EUI-64 similarly, with hardware type 27.

Although with only two subtypes in common use, generalizing this
might
not be worth the effort.

4. Several of the identifier types can be represented as URNs:

- IMEI can be represented as a URN as urn:gsma:imei:...
- all of the RFID types have a URN representation (called the
  "pure-identity URI" in the RFID specifications), which starts
  urn:epc:id:...

Since all URN types are ensured of being unique and persistent, it
seems that we could define a MNID type for URNs generally, and then
any RFID URI or an IMEI (as a URN) could be used as a value of that
type.

If this idea is adopted, it seems that the other 3GPP types (IMSI,
P-TMSI, and GUTI) should be given defined encodings as URNs in new
sub-namespaces of the "gsma" URN namespace, to parallel the encoding
of IMEIs defined in RFC 7254.

This consolidation could be significantly beneficial.  It allows MNID
to use any URN scheme as an identifier.  It reduces the three
different RFID representations to one.  It incorporates any future
expansion of RFID schemes (because all schemes will have a
pure-identity URN representation).  A disadvantage is that the URN
encodings are long, but the security considerations section states
that MNIDs are used only on the first registration at the home agent,
so there isn't much need for brevity.

Similarly, this approach incorporates any future expansion of mobile
identifiers that GSMA decides to define, as long as GSMA provides a
URN representation for it.

The most significant disadvantage is that some URN schemes allow
several character strings to "mean" the same URN.  In most URN
schemes, the allowed variation is limited to the case of letters, and
the common convention is to always use l