Re: [DMM] IPR poll on draft-ietf-dmm-srv6-mobile-uplane-11

[Charlie Perkins]

Dear Chair,

I am not aware of any undisclosed IPR related to this document.


Regards,
Charlie P.



On 4/15/2021 9:56 AM, Voyer, Daniel wrote:


Dear Chair,

I am not aware of any undisclosed IPR related to this document.

Thanks

dan

*From: *dmm  on behalf of "Sri Gundavelli 
(sgundave)" 

*Date: *Wednesday, April 7, 2021 at 1:59 PM
*To: *"dmm@ietf.org" 
*Subject: *[EXT][DMM] IPR poll on draft-ietf-dmm-srv6-mobile-uplane-11

Dear Authors,

We are required to ensure compliance with the IPR guidelines of the IETF.

Can each author please confirm that their direct, personal knowledge 
of any IPR related to this document has already been disclosed, in 
conformance with BCPs 78 and 79?


Note that an answer is required from all authors of the document. The 
DMM list is added in CC for the sake of transparency.


Thanks

Sri

*From: *dmm  on behalf of "Sri Gundavelli 
(sgundave)" 

*Date: *Wednesday, April 7, 2021 at 10:35 AM
*To: *"dmm@ietf.org" 
*Subject: *[DMM] WGLC on draft-ietf-dmm-srv6-mobile-uplane-11

Working Group:

As we discussed in the last IETF meeting, we are issuingWGLCon 
draft-ietf-dmm-srv6-mobile-uplane-11.


The document went through several revisions and there were good amount 
of reviews on this document. I am very pleased with the quality of 
this document. The authors have addressed all the comments and there 
are no open issues that we are tracking at this time. We believe the 
document is ready for IESG reviews and like to confirm the same from 
the working group.


The following message commences a two weekWGLCfor all feedback.

Document Link:

https://www.ietf.org/archive/id/draft-ietf-dmm-srv6-mobile-uplane-11.txt 



Please post any comments/concerns on this document.

Thanks!

Sri


___
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

[DMM] Disaggregated FPC documents

[Charlie Perkins]

Hello folks,

During the [dmm] meeting at IETF 104, I suggested that we should try 
breaking the YANG definitions out into a different document so that 
potential reviewers would not be intimidated by 150+ pages of document 
text.  I got reasonable support for at least trying the idea. If it 
doesn't work, I will volunteer to recombine them in the future.


Briefly scanning the base document, I see that it needs another pass for 
readability as well.  That will take a while, so I propose to do that 
later after the submission of the two companion documents.  I will scan 
both documents for consistency and so on, but they are ready for 
submission now.  In the YANG document, I was considering to include a 
list (without definitions) in the Terminology section for the FPC terms 
that are defined in the base document.  Comments are welcome about that 
suggestion.


Suresh has expressed the opinion that it would be O.K. to have the 
companion YANG document considered to be a WG document.  If anyone in 
the [dmm] group has objections to this proposal, please let me know.


Thanks in advance!

Regards,
Charlie P.



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

Re: [DMM] New Liaison Statement, "CP-173160: New Study Item on User Plane Protocol in 5GC"

[Charlie Perkins]

Hello folks,

The liaison statement seems to suggest that the existing work in 3GPP is 
either to develop the 5G architecture, or to see how well the current 
evolution of GTP-U fits the 5G architecture as developed.  It is natural 
to also expect that the thinking about the 5G architecture has been 
influenced by the known behavior and features of GTP-U.  The further 
guidance in the Liaison statement seems to recommend familiarity with 
23.50{1,2,3} and 33.501.


I've had a look at some of the documents, and they can be pretty heavy 
sledding.


draft-bogineni-dmm-optimized-mobile-user-plane-00 is somewhat more 
compact.  And yet it also focuses a lot of attention on SMF as well as UPF.


Is the IETF expected to make comments only about UPF?

Some previous discussion suggested that whatever UPF would be developed 
in the IETF, needed to be independent of the control plane.  But 
presumably 3GPP would like a UPF that offered the control features that 
are required for SMF as well.  That's a lot of additional features.  It 
seems to place additional constraints on whether or not an IETF 
user-plane protocol would be useful for 3GPP.


If the task is only to provide information to 3GPP about what [dmm] is 
doing, then the task is manageable.  But if we are also required to 
describe how an IETF user-plane protocol meets or does not meet the 
requirements in {2,3}3.50{1,2,3} -- that's a difficult task. Moreover, 
the charging framework has usually been considered outside the 
jurisdiction of IETF if I remember correctly -- something about anti-trust.


Regards,
Charlie P.



On 4/11/2018 11:16 AM, Liaison Statement Management Tool wrote:

Title: CP-173160: New Study Item on User Plane Protocol in 5GC
Submission Date: 2018-04-11
URL of the IETF Web page: https://datatracker.ietf.org/liaison/1572/
Please reply by 2018-07-20
From: Satoru Matsushima 
To: Sri Gundavelli ,Dapeng Liu 
Cc: Dapeng Liu ,Terry Manderson ,Distributed 
Mobility Management Discussion List ,Sri Gundavelli ,Suresh 
Krishnan 
Response Contacts: georg.mayer.hua...@gmx.com,3gppliai...@etsi.org
Technical Contacts:
Purpose: For action

Body: 1. Overall Description:
3GPP working group of CT4 (Core and Terminal) would like to inform the IETF 
that CT4 has initiated a study item on user plane protocol in 5GC for 
Release-16 of 5G phase 2 (see CP-173160).

Based on the outcome from the IETF / 3GPP Coordination meeting at IETF#100, 
3GPP CT4 got aware that IETF DMM WG is currently working on a possible 
candidate protocol for the 3GPP 5G user plane protocol.

3GPP CT4 wants to emphasize that currently there is no related evaluation 
ongoing in 3GPP. Nevertheless, a study item was approved for such a study to 
start in the second half of 2018. The study will evaluate between existing 
solutions within 3GPP and other protocols, based on the Release 16 stage 2 
(system architecture) requirements.

3GPP CT4 would like to point IETF DMM to the following specifications on GTP-U. 
The Release 16 stage 2 requirements are not yet known but it is worth looking 
at latest GTP-U spec which will be evaluated through the study as the existing 
protocol.

•   [1] 3GPP TS 29.281 (V15.1.0): GPRS Tunnelling Protocol User Plane 
(GTPv1-U)


Following technical report provides information of how 3GPP considered GTP-U 
apply to user plane of 5G_ph1:

•   [2] 3GPP TR 29.891 (V15.0.0): 5G System – Phase 1; CT4 Aspects


Furthermore, 3GPP would like to give the following general guidance to IETF 
DMM, regarding user plane transport within 3GPP networks. These are technical 
specifications that include also the necessary information to understand which 
architectural, QoS, security-related and high-level requirements GTP-U 
currently complies to within 5G_ph1.

•   [3] 3GPP TS 23.501 (V15.0.0): System Architecture for the 5G System
•   [4] 3GPP TS 23.502 (V15.0.0): Procedures for the 5G System
•   [5] 3GPP TS 23.503 (V15.0.0): Policy and Charging Framework for the 5G 
System
•   [6] 3GPP TS 33.501 (V0.6.0): Security Architecture (work in progress)

2. Actions:
To IETF DMM:
ACTION: CT4 respectfully asks IETF DMM to provide any information that 
may be relevant to the above CT4 work by July 2018.


3. Date of Next CT and CT4 Meetings:
CT4#83  26th Feb – 2nd Mar 2018 Montreal, CAN
CT#79   19th – 20th Mar 2018Chennai, India
CT4#84  16th – 20th April 2018  Kunming, China
CT4#85  21st – 25th May 2018Osaka, Japan
CT#80   11th – 12th June 2018   La Jolla, USA
CT4#85-bis9th –13th July 2018   TBD, France
CT4#86  20st – 24th Aug 2018TBD, USA
Attachments:

 CP-180116
 
https://www.ietf.org/lib/dt/documents/LIAISON/liaison-2018-04-11-3gpp-tsgct-ct4-dmm-cp-173160-new-study-item-on-user-plane-protocol-in-5gc-attachment-1.doc

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


___
dmm mailing list
dmm@ietf.org
https:/

Re: [DMM] Comment on draft-ietf-dmm-deployment-models

[Charlie Perkins]

Hello Seil,

Please excuse my delay for this clarifying comments.  I have been 
immersed elsewhere.


In order to be as clear as possible, please let me refer to a couple of 
diagrams.  Slide 5 of your presentation at IETF 101 was entitled 
"Model-5: On Demand Control Plane Orchestration Mode".


A URL is: 
https://datatracker.ietf.org/meeting/101/materials/slides-101-dmm-dmm-deployment-models-and-architectural-considerations-01.


And then we have various representations of 3GPP architectural diagrams 
for 5G.  For instance, one can look at slides 4-6 of K. Bogineni et 
al.'s presentation.


A URL for the latter is: 
https://datatracker.ietf.org/meeting/101/materials/slides-101-dmm-optimized-mobile-user-plane-solutions-for-5g-00


My suggestion was to try to correlate the two different representations 
of advanced mobility management architectures. This would involve making 
a correspondence between the [dmm] nomenclature (e.g., H-CPA, A-CPN, 
etc.) and the 3GPP nomenclature.  Plus it would be very nice to express 
the Service Primitives in terms of 3GPP 5G reference points - for at 
least a few of them.  Otherwise there is a reasonable chance that people 
from 3GPP and people from IETF may not see each others' points of view.


As I mentioned in an earlier email, I was somewhat surprised that 
routing between access networks using heterogeneous physical media was 
considered to be a problem, so the mismatch of viewpoints between the 
SDOs really does seem to be a problem.  I hope we can avoid it this next 
time around!  Maybe the FPC design for policy will be helpful.  I could 
imagine writing up a new section for inclusion in 
draft-bogineni-dmm-optimized-mobile-user-plane, but as mentioned 
elsewhere it is not clear just what are the criteria for selection.  Or 
(quite likely) I just missed it, but I'll try find it in the rush of 
relevant emails after the last IETF.


Regards,
Charlie P.




On 3/27/2018 1:52 AM, Seil Jeon wrote:


Hi Charlie,

Thanks for your comments on our update of the I-D.

You commented and suggested that 5G functions in TS 23.501 need to be 
mapped with the CPA/CPN, DPA/DPN introduced in our I-D.


I know you have additional suggestions. Will you specifically mention, 
please?


Regards,

Seil Jeon



___
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] IETF101 DMM WG Meeting Notes #1

[Charlie Perkins]

Hello Arashmid,


if a WiFi network needs to talk to 3GPP network for a roaming device, what 
protocol are they going to use?


They could use Mobile IPv6, which was designed for exactly this purpose.

Do you think that would work?

Regards,
Charlie P.



On 3/27/2018 11:08 AM, Arashmid Akhavain wrote:

Tom,
Are you referring to a use case where the UE moves between different access 
technologies?

Arashmid


IMO Unified concept in that encapsulation doesn’t seem to work i.n that 
circumstance. When it comes to WiFi case, IETF has CAPWAP as the user plane 
protocol which is also a foo-over-UDP variation.


Rigtht so if a WiFi network needs to talk to 3GPP network for a roaming device, 
what protocol are they going to use?





-Original Message-
From: dmm [mailto:dmm-boun...@ietf.org] On Behalf Of Tom Herbert
Sent: 27 March 2018 10:03
To: Satoru Matsushima 
Cc: dmm@ietf.org
Subject: Re: [DMM] IETF101 DMM WG Meeting Notes #1

On Mon, Mar 26, 2018 at 11:57 PM, Satoru Matsushima 
 wrote:

Thank you Tom,

Unfortunately I couldn’t find clear advantage of GUE against GTP-U.
(No offensive, please don’t get me wrong.)

I couldn’t see GUE in NVO WG doc list. But I can see much more foo-over-UDP 
type encapsulation in IETF.

It's not in nvo3, it's now WGLC in intarea. See draft-ietf-intarea-gue and 
draft-ietf-intarea-gue-extensions.


IMO Unified concept in that encapsulation doesn’t seem to work i.n that 
circumstance. When it comes to WiFi case, IETF has CAPWAP as the user plane 
protocol which is also a foo-over-UDP variation.


Rigtht so if a WiFi network needs to talk to 3GPP network for a roaming device, 
what protocol are they going to use?


Nevertheless I think that that aspect would be a criteria for user plane 
protocols comparison provided to 3GPP. But I don’t think it is good idea that 
we provides 3GPP all kind of foo-over-UDP encapsulation protocols in IETF. It 
would be better to pick SRv6 and some generic foo-over-UDP protocol to be 
compared with GTP-U supported functionalities.


GUE is the generic foo-over-UDP protocol for that purpose.


Basic functionalities of GTP-U is that sequence number option, 
extension-headers, and multicast and those should be the part of criteria. IMO 
as you suggested, overhead size, performance, TE, extensibility and encryption 
would be good idea for the criteria in addition to the above fundamental ones.

Best regards,
--satoru




2018/03/27 11:51、Tom Herbert のメール:

On Mon, Mar 26, 2018 at 6:30 PM, Satoru Matsushima
 wrote:

Thank you Tom for your suggestion.

Do you think that GUE has some advantages against GTP-U?

I believe so. GUE is designed to be a general purposed multi use case
encapsulation. The defined GUE extensions deal with problems and
provide features of encapsulation (header security, fragmentation,
payload security, checksum handling etc.). This is done without
resorting to expensive TLV processing. GUE also allows "private data"
that could be used for use case specific info-- so TLVs or GTP
extensions could be encoded so in that sense it's a superset of GTP
functionality. As I mentioned, GUE has a mode for encapsulating IP in
UDP with minimal overhead (direct IP over UDP).


When it comes to foo over UDP capsulation, does GUE benefit user plane beyond 
GTP-U?


I think so. Perhaps the biggest advantage is the GUE can be used
accross different use cases and technologies. It's generic protocol
so it could be used for multiple use cases in a mobile network. For
instance, a UE might talk to a a low latency service application via
GUE. To the server this looks much more like simple virtualization or
encapsulation and GUE includes potential optimizations. Similarly,
GUE also could be use to connect across different access technologies
that might not be 3GPP (like roaming between WIFI and a mobile network).
Conceptually, other IETF defined encapsulations could also be used
for this (e.g. IPIP, LISP, GRE, VXLAN), but GUE is specifically
designed to be multi use case, low overhead, but still extensible.

We intend to use ILA in a similar multi-use case fashion, however
when encapsulation is required (like SR TE is needed, or we need an
encrypted tunnel) then I believe GUE is a good alternative for that
case to provide necessary functionality and extensibility.

Tom


2018/03/27 9:16、Tom Herbert のメール:

On Wed, Mar 21, 2018 at 9:27 AM, Sri Gundavelli (sgundave)
 wrote:

FYI. This is the notes that Carlos captured. Thank you Carlos!!

We are also waiting for Lyle to share his notes. Please review and
comment, if you see any mistakes.


With regards to SR encapsulation: "this is using IP-in-IP as default.
Why not using UDP encapsulation?"

There is some rationale for UDP encapsulation here to maximize
compatibility with the network and potentially intermediate nodes
like firewalls. For example, in the performance numbers that
Kalyani posted, the TPS for SR over IPIP routing was lower than
other encapsulations. The reason for this is that the particu

[DMM] Topology definition in the current FPC draft

[Charlie Perkins]

Hello folks,

When I think of a network topology, I think of the nodes in the network 
and the links between them.  Right now in the FPC document, the 
definition of topology does not easily admit that interpretation.


I would like to modify the top-level Topology definition to be a set of 
"Topological Links", where each such Link has a local Interface, and a 
remote Interface, and some description about the communication channel 
between the the local and remote Interfaces.  Interesting attributes of 
the description might include:


- IP addresses

- tunnel type

- MTU

- available bandwidth

- etc.


Also in the current document there are features which are important for 
creating the topology and configuring the DPNs to realize the topology.  
This involves selection of appropriate DPNs based (roughly speaking) on 
the roles they play in the network. As a result, we should discuss 
Topology as a set of Links that are established at initial network 
configuration time, and infrequently modified as a consequence of 
network events.  For instance there might be a need for load balancing, 
or routing around damaged equipment.


FPC interface directives would include information about the addresses 
and other attributes of the communication channel, as well as enabling 
database references to both DPN endpoints of the Link as part of the 
Topological Link data.


Finally, it should be discussed whether the Topology reflects all 
communication channels configured on DPNs, or only communication 
channels between interfaces of Service Groups.  The latter is a close 
reformulation of what has been previously called a "DPN Group", and 
refers to a group of interfaces on a DPN that are organized together to 
fulfill some specific service need or service function.


Comments will be appreciated!

Thanks in advance,
Charlie P.


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

Re: [DMM] FW: New Liaison Statement, "LS on indicating service continuity usage of the additional IPv6 prefix in Router Advertisement"

[Charlie Perkins]

Hello Sri,

This is more about address coloring than the Liaison statement.


The approach of coloring IPv4 and IPv6 addresses/prefixes with
mobility properties.

This is about standardizing IP address address/prefix ³types". Each ³type"
has a certain behavior that the network is expected to provide. Section
3.1, of draft-ietf-dmm-ondemand-mobility-13 defines the following four
address types, which are applicable to both IPv4 and IPv6 addresses and
prefixes.

#a. Fixed IP Address
#b. Session-lasting IP Address
#c. Non-persistent IP Address
#d. Graceful Replacement IP Address


If one gets a non-persistent IP address and somehow as events unfold 
there is a need for a persistent IP address, is it required to change 
addresses?  Or can one change the color of the address in use?


If one gets a fixed IP address, but never hosts any persistent sessions, 
can the address be re-colored?


Is the expectation that users will be charged different rates depending 
upon the color of their address?  If the address could be re-colored, 
would the charging regime change at the time the address gets a new color?


Regards,
Charlie P.


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

[DMM] Reformulation of policy lifecycle ideas in FPC draft

[Charlie Perkins]

Hello folks,

I would like to propose a bit of reorganization for the current policy 
handling as specified in the current FPC document.


Roughly speaking, a policy can exist in one of three "forms".

A policy definition can be referenced in an Indexed Set by making use of 
a Policy Key.  This key enables an FPC Client or FPC Agent to retrieve 
the policy definition.  The policy attributes are exhibited in the 
policy definition within the data structure in the Indexed Set.  Some of 
the attributes may not have any values, because the values need to be 
determined for any particular scenario in which the policy is enforced.  
Some of the attributes may have default values, which can be changed 
(e.g., port on which a certain kind of streaming data is received).  
Some of the attributes do not require any value (e.g., an Action to 
"drop all packets"), or have a particular value which is never changed.


When an FPC Client configures an FPC Agent with a set of Policies as 
retrieved from the Indexed Set, the Client can supply some needed 
attribute values, or non-default attribute values, as part of the 
configuration process.  Then the Agent has access to those policies for 
future data-plane operations.  Such attribute values are called 
"Settings" or "Values" in the current document.  For the purposes of 
this email, I will call these configured attribute values to be 
Settings.  In policy definitions, Settings can apply either to the 
Descriptors or the Actions of the Rules in the policy.


When a mobile node arrives at a DPN (for instance, an access point), the 
FPC agent is triggered to create a Mobility Context for the mobile node 
(MN).  This will involve applying certain policies to the traffic to and 
from MN.  In order to apply the policies, the FPC Agent will likely have 
to insert more Settings to the policy attributes.  For instance, the 
traffic descriptor might need the IP address of the mobile node.  The 
maximum bitrate for MN traffic might depend upon its authorizations, 
which are not available to the FPC Agent until runtime.  Once the policy 
attributes are fully updated with Settings appropriate for MN (the 
mobile node), then the policy can be enforced.  We might say that once 
all attribute values are known, the policy is "activated". New policies 
can be activated (or old policies deactivated) as MN creates or deletes 
new Flows.


The three forms of a Policy, according to the above description, evolve 
according to various specializations that proceed by updating more and 
more policy attributes, until all attribute values have known values, 
and can be used for traffic management to/from the mobile node.  Observe 
that some policies don't necessarily have to be specific to a mobile 
node.  Some are domain-wide policies, and may have all attribute values 
assigned already when the FPC Client configures them into the FPC Agent. 
Throughout this evolution in time, the data structures for a Policy in 
memory (e.g., as known to the FPC Agent) still maintain the same Policy 
Key, but may acquire more and more Settings.


The above description of policy configuration and further configuration 
amounts to another way of looking at the concepts in the current FPC 
document -- in particular, Assigned Policies, Requested Policies, and 
Embedded Policies.  It is an important matter of current discussion 
about what parts of the existing terminology to retain for the upcoming 
revision of the specification.  Input from the [dmm] WG is cordially 
requested.


We have also discussed changing what is now called a "policy definition" 
to instead be a "policy template".  The latter terminology evokes the 
process of configuration and reconfiguration as described above.  Please 
let us know what you think.


Happy Bloody Moon Groundhog Eve,
Charlie P.

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

Re: [DMM] FPC - Topology

[Charlie Perkins]

Hello Lyle,

I have comments on the slides, and could benefit from larger discussion 
on the mailing list.


On slide 3, the presentation indicates three Indexed Sets -- DPNs, 
Domains, and Interface Groups.  Reference to entities of those three 
entity types is made available by Keys into the relevant Indexed Set.  
An Interface, on the other hand, is not shown as referenced by a Key 
into an Indexed Set.  All of the relevant Interface information is 
directly exhibited as attributes and sub-attributes of a DPN.  I think 
this is a consistent and somewhat understandable way of organizing the 
entities and attributes in our Information Model.


On slide 4, there is the following:



Missing – protocol & settings required for selection
Should Reside in Group?



I think it is more natural for the protocols and settings for an 
Interface to be shown as attributes for that Interface.  The Interface 
Group enables access to the list of Interfaces on the DPN.  So, 
selection of a DPN might proceed as follows:

- For each DPN, look at its Interface Groups
  = For each Interface Group, look at the protocols and settings that 
are supported.


If this isn't efficient, then we should reorganize the model. Continuing 
to slide 5, there are three questions, which are relevant to this.



  * How are Interfaces specifically mapped to a Group (DPN with 2
interfaces but only 1 is part of Group)?



Right now the Interface is a part of the DPN definition, and the 
Interface Group was thought to be a way of collecting the information 
about what kinds of interfaces are available.  That is O.K. as far as 
having the ability to partition the Interfaces of a DPN into 
non-overlapping Groups, but there is no reverse structure for getting 
the Interface details from the Interface Group.  If the latter is 
needed, then we should modify the definition of the Interface Group 
appropriately.  We might put an Interface-Key as an attribute of the 
Interface-Group, but the Interface Group is in an Indexed Set and the 
Interface-Key as currently (as an L-Key) defined only makes sense within 
the context of a DPN.


Perhaps we first need to know the structure of the DPN-selection 
Algorithm to know how best to organize Interfaces in the Information Model.





 *




  * What about Interfaces NOT in a group? What do we do with those
settings?



In the current DPN definition, this is not a problem... right?


 *


  * Relation be Roles & Interfaces is unclear



For a DPN to serve a particular role, it needs to have certain types of 
Interfaces.  A substantial part of the "type" of an interface is 
determined by the set of Protocols that the Interface supports. Besides 
that, the Interfaces will have certain Settings that further define 
their usefulness.



Slide 6 encodes a great deal of information, some of which depends on an 
understanding of DDDS.  Maybe it is appropriate to include within the 
FPC document an appendix recounting the salient details of DDDS, with 
some emphasis on the DDDS view of Interface Groups and DPN selection.


If you are willing, I might suggest a reorganization of the graph as 
follows:


- Move "Protocols" up vertically quite a bit

- Move "Features" to fit between "Protocols" and "Interfaces"

Then both instances of the "Features" block could be coalesced, and 
maintain their pointers to "Selection Relevant" and "Other"


Somehow, the idea of a Selection Relevant "Setting" feature is easier to 
grasp than a Selection Relevant "Protocol" feature.  But I understand 
that many protocols have so many features that one has to be careful to 
ensure interoperability even between two conformant implementations of 
the same Protocol.  Can't boil the ocean here and so we just have to 
accept that.


Regarding slide 7:

- (1) is agreeable to me.  Let's try it.

- For (2), we could certainly allow a DPN to have more than one role.  
However, for sanity, I hope we can make it so that the roles are 
independent.  Suppose a DPN could be either a MAG or an LMA. Now let's 
say that it is chosen to be a MAG.  Is it further disqualified from 
being an LMA at the same time?


- (3) - I would be in favor of collapsing Features and Settings.

Regards,
Charlie P.




On 1/30/2018 6:58 AM, Bertz, Lyle T [CTO] wrote:


All,

I’ve put together a quick assessment on Topology (proposed for new 
draft and v09).


We’ll briefly review it today as time permits.

Lyle




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 recipient, please contact the sender and 
delete all copies of the message.



___
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/d

Re: [DMM] FYI - FPC Working sessions

[Charlie Perkins]

Hello Lyle,

I'm not sure I fully understand the scenarios that you have suggested.  
Please let me know if my understandings are correct, as I interpolate 
assertions and questions within the example text.


We’ll try to complete policy. I’ll set up a few use cases as well. 
We’ll only focus on policy aspects of the context.


Here, I reckon "context" means "mobility context".



Proposed Use Case(s) (all assume DPN Selection has occurred)


I understand this to mean that various policies have been supplied to 
the FPC Agents that are operating the DPNs involved with dataplane 
service for the mobile node.  I guess we are dealing with a single 
mobile node -- is that correct?




3 policies are proposed

1. Account for and DROP all port 22 destined to the mobile.

2. Set the AMBR for all traffic from 10.5.5.0 to 3Mbps.

3. For (UE on port 318 and 10.6.5.5 port 9335) account on bucket X, 
set traffic-class to Y, set max bit rate to 2Mbps.


Are these three policies for all mobile nodes (even though we may only 
be dealing with one)?


The term bucket does not appear in the FPC draft document, and traffic 
class seems to have something to do with ranges of IP addresses.


Are we distinguishing between AMBR and max bit rate?  Is AMBR intended 
to be for all mobile nodes, or for all flows of a particular mobile node?




Part 1 – Basic Policy Management

1. Create a Descriptor.

2. Create an Action.

3. Create a Rule.

4. Create a Policy.


Since we have three policies, I guess that these four items are each 
replicated at least three times, with likely more for the Descriptors.  
Performing the four items for Policy #1 might be pretty easy, but the 
other two policies could bring up more subtle points.  Anyway this will 
be a very good exercise.


Any policy that puts a cap on aggregate bit rate from ALL mobile nodes 
in the entire domain is going to require some protocol. Putting a cap on 
the aggregate bit rates from all mobile nodes at a single DPN seems a 
lot more manageable.



Part 2 – Mobility Policy Management (single context).

5. Create a Mobility Context with a pre-configured policy.

6. Create a Mobility Context with a dynamic policy.

7. Change the DPN assigned in the SGW / MAG role (mobile moves), aka 
handover in a

   a. make before break model.
   b. break before make.



In (5) -- does this mean picking one of the three policies and creating 
a Mobility Context?  If we have it so that a Mobility Context is 
associated with a mobile node (my very fond hope), then does the 
preconfigured policy get to be installed at network entry?  Or maybe 
there is a sort of "generalized" Mobility Context that has Settings that 
are configured for a particular mobile node at network entry, and 
modified as needed as the mobile node moves and creates new flows and 
finishes old flows and so on.


Is a Dynamic Policy something that changes as the mobile node moves around?

For (7), presumably the Context Transfer will be very similar, but the 
handover protocol will be different.  Of course I would like it, if FPC 
had something to say about handover protocol.  I did not see anything 
about that yet in the document, but since the term MAG appears, I guess 
we are to assume PMIP.  For the purposes of this discussion, it might be 
nice to have something similar to Figure 16, but redrawn in PowerPoint 
for clarity.


As drawn in Figure 16, let's say that FPC Client lives in the control 
plane on a node called the "LMA Controller (LMA-C)" and makes run-time 
decisions.  Is that your intention?



Part 3 – Secondary context (bearers)

8. Add a secondary context

9. Secondary context update based upon 7a and 7b.

10. Remove a secondary context


The term "Secondary context" does not appear in the FPC draft document.  
But a bearer has some resemblance to a flow.  So maybe you mean that the 
identity of the mobile node establishes a primary context, and flow 
creation establishes a secondary context.  Is that correct?  If so, then 
there should not be much difference between 7a and 7b (I hope!).



Regards,
Charlie P.


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

[DMM] Policy in the FPC draft - definitions, context transfer, keys, indexing, etc.

[Charlie Perkins]

Hello folks,

Policy seems always to be complicated.  I wrote up a scenario that, I 
think, captures many of the complications and relevant areas of 
application.  I also think the explanations about policy management as 
used in the scenario mostly represent the intention of the text 
currently in the FPC draft.  If the description about how policy is 
managed for the handover scenario is appropriate, I would like to use it 
and carry out a slight reorganization of the descriptions in the draft.


Regards,
Charlie P.

==

Example for mobile node movement from DPN-1 to DPN-2.

MN has two flows:

 *      = F1: best effort traffic
 *      = F2: voice call



When MN attaches to the access network of DPN-1, DPN-1 constructs a 
Mobility Context for MN.  It has the following (say, at network entry):


 *      = MN's IP address (MN_IP)
 *      = Policy X for F1
 *      = Policy Y for F2
 *      = other stuff (charging ID, current remaining credit, ...)



When MN moves to the access network of DPN-2, DPN-2 should receive the 
Mobility Context for MN from DPN-1, and make the necessary modifications 
so that the Mobility Context for MN is parameterized for operation with 
DPN-2.


Suppose that for this example, DPN-1 routes all traffic to/from MN 
through a common gateway G-11.  Also suppose that FPC Client has 
installed two policies on both DPN-1 and DPN-2 -- one for best effort 
traffic, one for voice.


Then DPN-1 might store in the Mobility Context for MN the following rules:

 *      = R1: If (packet belongs to flow F1), then route through G11
 *      = R2: If (packet belongs to flow F2), then route through G11
 *      = R3: Else, drop


In simplest terms, at DPN-1 don't support any fancy applications, and 
route all packets through G11.  Observe that the actual rules would 
certainly be different, but I think this is sufficient for the example.  
As this description of the scenario proceeds, the need for other 
policies will be considered.


How did rules R1, R2, and R3 get installed on DPN-1?  Presumably the FPC 
Client has a list of policies that are supported in the Domain (i.e., 
operator's network).  One policy (X) could be called 
"Handling-Best-Effort" with Policy-Key P-12 and the other policy (Y) 
could be called "Handling-Voice" with Policy-Key P-37.  Keys P-12 and 
P-37 are unique within the namespace available to the FPC-Client for 
data-plane nodes in its Domain.


When MN registers at DPN-1, DPN-1 should already have policies P-12 and 
P-37 available for insertion into MN's mobility context. Let's say that 
these two policies are in the set of Assigned Policies at DPN-1 and 
DPN-2, and that the FPC client configures those policies at the time the 
data-plane topology is established that contains DPN-1 and DPN-2.  The 
FPC Client might have more policies that are pertinent to all flows on 
the mobile node, and when a mobile node registers at a DPN, the DPN 
process determines which of those policies are associated with a 
particular mobile node, according to the flow information that is 
provided during registration.  For our mobile node, suppose that policy 
P-51 applies to every flow on the mobile node.


There might be some other policies that are applied for traffic to/from 
every mobile node, regardless of the specific credentials or flows 
supported on that mobile node.  These might be Domain policies, or they 
might be configured only for a particular Interface Group, or both.  
Domain policies might pertain to a particular class of mobile nodes, 
such as visitors from another specific domain.  This is a matter for 
discussion.


There might be another category of policies that are DPN-specific.  Such 
policies would apply to every Mobility Context resident on a particular 
DPN, regardless of the particular mobile node.  But another DPN might 
not have any of the policies of the first DPN, or only some of them.  
Let's call those DPN policies.


Back to the scenario where the MN moves from DPN-1 to DPN-2. Suppose 
that the mobility management system wants to do a smooth handover, and 
that this requires transferring MN's Mobility Context from DPN-1 to 
DPN-2.  Suppose that on DPN-1 there are DPN-specific policies P-40 and 
P-41 that apply to the mobile node, and Domain policies P-50 and P-52.


This depends on how the policy rules are stored on DPN-1.  Here is one 
possibility:


 *      = DPN-specific policies are not transferred with the Mobility
   Context
 *      = Domain policy keys P-50 and P-52 COULD be transferred, or we
   could specify that DPN-2 determines what Domain policies apply even
   though we would expect them to be the same policies.
 *      = MN-specific policy key P-51 is transferred
 *      = Flow-specific policy keys P-12 and P-37 are transferred.



In this formulation, the Mobility Context transfer has to carry the Key 
information for the relevant policies, but not the full policy 
def

[DMM] Slight change in FPC draft terminology and related re-organization of some introductory concepts

[Charlie Perkins]

Hello folks,

Looking at the FPC draft 10, it has the following organization in section 4:

Version 10:

4    FPC Mobility Information Model
4.1    Model Notation and Conventions
4.2    Core Structure - Information Model Components
4.3    Topology
4.3.1    DPN
4.3.2    DPN-Type
4.3.3    DPN-Group
4.3.4    Domain
4.4    Policy
4.5    Configurable Policy
4.6    Mobility-Context
4.7    Monitors
4.8    Namespace and Format
4.9    Attribute Application

I'd like to reorganize this somewhat, while keeping most of the same 
kind of content with modifications according to recent discussion. Here 
is a proposed new organization.  Below the proposed reorganization of 
the sections, I have some comments that will, I hope, be agreeable.


 4    FPC Mobility Information Model
4.1    Model Notation and Conventions
4.2    Namespace and Format
4.3    Attribute Application
4.4    Information Model Components
4.4.1        Domain
4.4.2        Configurable Policy
4.4.3        DPN-Type
4.4.4        Interface
4.4.5        Interface-Group
4.5    Topology Information Model
4.6    DPN Information Model
4.7    Policy Information Model
4.8    Mobility-Context Information Model
4.9    Monitor Information Model

For this reorganization, the major concepts are Topology, DPN, Policy, 
Mobility-Context, and Monitor.  I have promoted each of these major 
concepts to have its own subsection of the FPC Information Model section.


I am proposing a change in the implied meaning of "Component".  In the 
new text, I would use "component" to mean a small-ish building block 
that is used in the major concepts of FPC.  They are secondary in nature 
(compared to the major concepts).  I think that the "Interface" 
component deserves its own small section, and then "Interface-Group" 
[was, DPN-Group] could use that in a natural fashion.


If Interface-Group seems "unlike" the other components, we could 
describe it as an "assembly".  On the other hand, just because something 
is described as a "component" doesn't mean it is unimportant.  For 
instance, "domain" is very important, but in the information model it 
looks like a component of the definition of a Topology.


The Namespace subsection seems to belong nearer the start before getting 
into the technical description of the Components and major sections.  A 
lot of the complication in this document is related to difficulty of 
describing abstract concepts, and naming is crucial to clarify and 
reduce the complications.  So namespace takes some priority.  I have 
more discussion about this later, but for now this is enough to justify 
moving that subsection closer to the front of section 4.


Finally, the method of applying Settings to complete the Attribute 
values of an Information Model object should be described more generally 
and then specialized to Embedded Rules and so forth.  I don't have good 
text for that yet [TBD!!], but it seems important also for the way we 
use Descriptors and Actions in the Policy Information Model.


Regards,
Charlie P.

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

Re: [DMM] Using traffic Descriptors to characterize flows in a Mobility Context

[Charlie Perkins]

Hello Lyle and all,

Follow-up below...

On 1/23/2018 5:38 AM, Bertz, Lyle T [CTO] wrote:

The current Mobility Context uses the assigned address or prefixes in 
conjunction with device information, or similar information in an ancestor (if 
this is a child/descendent), to let the DPN know all traffic serviced with the 
Mobility Context information MUST have a destination/source matching the 
address(es) (per the direction of the traffic).


I think this means that the DPN provides service to a flow in a way that 
depends on the source/destination addresses of the traffic of the flow.




This is an implicit Descriptor if you would like to view it that way.  It was 
placed in the original documents in this manner I would assume for consistency 
with the current and next gen designs.


Check.  In fact, a flow could be defined to also depend on other things 
about the traffic (port number, packet size, ...).




The implication of what you are proposing is a more granular (sub-session) 
context with possible no actions.


I am O.K. with having actions as well.  Granularity is according to 
whatever is convenient for whoever defines the flows.




The current implementation allows Rules to be assigned to DPNs in the 
underlying list.   The Rule containing the Descriptors and associated Actions.


This will very simple to provide, and I will change the rough draft to 
reflect this.  Suppose the Rule is something like "if byte count exceeds 
current payment, send warning".  Is that related to what you have in mind?




I would stick to the current design; placing lists of Descriptors (beyond the 
Addresses) w/o Rule and DPN assignment creates too much ambiguity, validation 
cross checking in the DPN / Agent and would result in large, granular 
hierarchies.


Does the above resolve your concern?  I don't think I grasp the 
implication of your last clause, but if associating Rules with flows is 
acceptable, then all is good.


Regards,
Charlie P.

= end of new text ===



____
From: Charlie Perkins 
Sent: Monday, January 22, 2018 10:08 PM
To: Bertz, Lyle T [CTO]
Cc: dmm@ietf.org
Subject: Using traffic Descriptors to characterize flows in a Mobility Context

Hello Lyle and all,

I had an idea about characterizing the flows in a Mobility Context.

Namely, it seems that they can be characterized using the same kind of
Descriptors that are already used in the Rules.  A Rule matches traffic
against a Descriptor expression and if the traffic satisfies the
Descriptor, some action is taken.

That's just about what we want to say about a flow -- namely, that it
matches some Descriptor expression.

I am proposing to modify the Mobility Context to have some
mobile-node-specific information and a List of Descriptors, just as we
already reference under the Policy structure.  Since the Descriptors are
located in an Indexed Set, the Mobility Context only has to supply the
Descriptor-Key along with Descriptor-Values as before.

I am hoping this will provide a boost towards improving the naturalness
of the Information Model for Mobility Context.

Comments?

Regards,
Charlie P.



On 1/22/2018 1:28 PM, Bertz, Lyle T [CTO] wrote:

More inline.

-Original Message-
From: Charlie Perkins [mailto:charles.perk...@earthlink.net]
Sent: Monday, January 22, 2018 2:27 PM
To: Bertz, Lyle T [CTO] 
Cc: dmm@ietf.org
Subject: Re: [DMM] Parent versus child mobility context

Hello Lyle,

More follow-up inline.  We're getting closer.


On 1/22/2018 11:27 AM, Bertz, Lyle T [CTO] wrote:

Hello Lyle and all,

I think I agree with most of what you say below.  I'm concerned with how to 
organize the information in the model.  So, for that purpose, please verify 
whether my following understandings are correct.

- The mobility context resides on a DPN.

- The mobility context provides necessary information (e.g., QoS) for a single 
mobile node.

- The DPN uses it to manage data-plane traffic for that mobile node.


This may be too broad of a view. What about a mobile node with
multiple mobility sessions? In such a case it may be managing one or
more (but not necessarily all of) the mobile node's mobility
sessions

Yes.  This is why I did not put "all" between "manage" and "data-plane".

LB > Ok.  We should probably be more explicit though for the casual observer if 
this language is used in the specification.


In my earlier email on this subject, I was using Mobility Context as describing something 
more associated with a mobile node, than with a particular flow.  If you want it to mean 
"bearer", then we ought to call it a Bearer.

Maybe it would be easier to understand if we had something called a "Mobile-Node Context", and in 
that context we had a set of Bearer Contexts (or, just Bearers).  Each bearer would inherit from the Mobile 
Node context simply by being part 

Re: [DMM] Question about Interface Groups (formerly, DPN Groups)

[Charlie Perkins]

Hello Lyle,


I am sorry to say that I don't understand your explanation.


To start with, I didn't mean to have a direct mapping between Interface 
Groups and 3GPP features.  Instead, I would like to suggest that 
Interface Groups are defined/configured/populated to make it easier to 
support features as needed.  If multiple Interface Groups are required 
(say, because the feature is complicated, or multi-modal, or spans 
multiple DPNs) that should be O.K.  If necessary, we could create a new 
kind of entity which collects together multiple Interface Groups which 
are then configured together to support the complicated feature. 
Hierarchically, you might say.



Questions below:


On 1/23/2018 5:25 AM, Bertz, Lyle T [CTO] wrote:


​

wrt

"What if we make that to be two different access-network features, and 
enable selection of Interface Groups for each feature?"



> emergency calls when roaming are not treated the same when they are 
domestic.




Doesn't this mean that they are handled using different DPNs, and thus 
different Interface Groups?



  this is especially true when it comes from an automobile.



I reckon that for vehicular mobility we will indeed see substantial 
differences in many aspects of mobility management.



   In fact, they are often set aside as different APNs.



Somehow this seems to motivate even more strongly the design advantage 
of having the Interfaces of an Interface Group reside on a single DPN.


  I'd like to be able to support the current DDDS implementations as 
well as TS 29.303.




Agreed -- if we can't do that, something is likely to be wrong, or else 
outside the jurisdiction of IETF.



Furthermore, such scenarios are indexed given their criticality;



Here I am at a loss.  An indexed set provides entity handles for 
reference in other structures.  Do you have some additional mechanism in 
mind?  How does criticality affect the creation of the index?


requiring an index to be built from a feature scan or security 
scenarios is not placing the operator in a comfortable situation.




And so I do not understand this either.  An indexed set offers 
references to a set of ("indexed") entities that share the same 
information model definition.  Can you say more about when and how a 
feature scan might work?  How would the indexed set be populated from 
that?  How would a security scenario impact the indexing of the Indexed 
Set?  If we don't provide an Information Model that enables the desired 
security scenarios, then we didn't finish our job yet. Security could 
well influence the configuration of appropriate Interfaces into an 
Interface Group, but I don't see how it is related to the creation of an 
index into a set of such Groups.


Thanks in advance for your consideration of my questions!

Regards,
Charlie P.




------------
*From:* Charlie Perkins 
*Sent:* Monday, January 22, 2018 7:10 PM
*To:* Bertz, Lyle T [CTO]
*Cc:* dmm@ietf.org
*Subject:* Re: Question about Interface Groups (formerly, DPN Groups)
Hello Lyle,

Thanks for the detailed reply.  It clears up a lot of questions in my 
mind.  To briefly reply:


- The reason I was asking about whether or not an Interface Group 
lived on a DPN was to help me figure out how to structure the 
Interface Group definition.  It's already structured as an Indexed 
Set, and so we will have an Interface-Group-Key.  The DPN structure 
will have a list of such keys, for each Interface Group that exists 
and includes an Interface from the DPN.  I think this is O.K. for your 
scenario of different security zones.  Notably, we do not provide that 
as an attribute of an Interface, but then again I don't think we could 
reasonably be expected to delineate all possible attributes of Interfaces.


An Interface Group will also have a DPN-Key, for the DPN that hosts 
its interfaces.


Your example about having to select a DPN to handle emergency calls as 
well as "normal" call processing is very interesting.  What if we make 
that to be two different access-network features, and enable selection 
of Interface Groups for each feature?  Then we are still O.K. with 
having each Interface Group to be configured with only one DPN-Key.


Regards,
Charlie P.

On 1/22/2018 1:49 PM, Bertz, Lyle T [CTO] wrote:


Your scenarios are correct.  I think we are in agreement but I want 
to clarify a few things:


Wrt your statement “(b) it makes good sense for all the Interfaces of 
an Interface Group to be hosted on the same DPN.”


Ack.  I agree when the required interfaces within an Interface Group 
can be hosted on the same DPN to service a request.  However, we 
leave DPN selection up to the implementations as they may have 
proprietary or other perfectly good reasons not to do this.  By the 
above statement I have interpreted it as a recommendation and not a 
mandate, i.e. it is not a require

[DMM] Long message

[Charlie Perkins]

Hello again Lyle and all,

Here's what it starts to look like.  From discussion earlier today, all 
of this data structure effectively resides in the DPN, and pertains to a 
single mobile node that is current utilizing some of the resources of 
the DPN.  The DPN uses it to manage data-plane traffic to/from the 
Mobile Node.



  |
  +-[Mobility-Context]  
  |+-[Interface-Group-Key] (O)
  |+-[Flow] (O)
  ||   +-[Interface-Key]  (O)
  ||   |   +-[Direction] (O)
  ||   +-[Descriptor-Match-Type] (M)
  ||   +-[Descriptor-Key] 
  ||   |   +-[Descriptor-Value]
  |+-[Assigned-Policy-DPN-Key] 
  ||  +-[Complementary-DPN-Settings]
  ||  +-[Interface-Id-Reference]
  ||  +-[Embedded-Rule]  (O)
  ||  +-[Assigned-Policy-Key]  (O)
  |+-[Requested-Policy-Key]  (O)
  |+-[Complementary-Context-Settings]  (O)


I have been puzzling over the Policy entries for a good while and I 
still am mostly in the dark.


Here's my guess, based on the previously existing descriptions for the 
terms.


Somehow the DPN wants to know *which* policies are *available* for 
managing traffic for a flow.  From among those policies, the DPN wants 
to know which policies have actually been *requested* for a flow.


The available policies are called "Assigned", perhaps because they have 
been assigned by the FPC Client as part of the Mobility Context (which 
up until previous versions was per-flow, not per-mobile_node).  Or maybe 
the "assignment" was performed by the FPC Agent in charge of the DPN.


For each "available" Policy, the actual policy is specialized from the 
Policy definition (which is in the Indexed Set of policies) by including 
some additional settings.  In this part of the document, these settings 
are called "Complementary", because they "complement" the Type of the 
Policy.  But in other places we have used "Values" to connote the 
operation of supplying specific values for what might be thought of as 
"wild-card" variable slots in the Policy definition.  By the way, these 
wild-card slots could either be in the Descriptor or in the Action, as I 
currently understand it.


But, stepping back a little bit...  why do we need the Policies? We can 
have them, but we already have the Flow characterizations by using 
Descriptors in a natural way.


Regarding Embedded-Rule...

Since we have Rules in an indexed set, why can't the Embedded-Rule 
reference the indexed Rule?  I don't think that having a Rule in an 
Indexed Set prevents the rule from being "embedded" in a Mobility 
Context.  It would be very natural for the DPN Agent (... errr, "FPC 
Agent") to initiate processing for a new Flow by copying over the 
definition from the Indexed Set of Rules (i.e., the Rule-Set).  Or maybe 
this was really the intention behind configuring the Assigned-Policy-DPN 
when the Mobility-Context was first created (during registration).  Even 
so, it would make definitional sense to keep the *definitions* of the 
Rules in the indexed Rule-Set, while still allowing them to be copied 
over and embedded whenever necessary for efficiency.


Thanks in advance for your consideration of my many questions.

Regards,
Charlie P.



On 1/22/2018 8:08 PM, Charlie Perkins wrote:

Hello Lyle and all,

I had an idea about characterizing the flows in a Mobility Context.

Namely, it seems that they can be characterized using the same kind of 
Descriptors that are already used in the Rules.  A Rule matches 
traffic against a Descriptor expression and if the traffic satisfies 
the Descriptor, some action is taken.


That's just about what we want to say about a flow -- namely, that it 
matches some Descriptor expression.


I am proposing to modify the Mobility Context to have some 
mobile-node-specific information and a List of Descriptors, just as we 
already reference under the Policy structure.  Since the Descriptors 
are located in an Indexed Set, the Mobility Context only has to supply 
the Descriptor-Key along with Descriptor-Values as before.


I am hoping this will provide a boost towards improving the 
naturalness of the Information Model for Mobility Context.


Comments?

Regards,
Charlie P.



On 1/22/2018 1:28 PM, Bertz, Lyle T [CTO] wrote:

More inline.

-Original Message-
From: Charlie Perkins [mailto:charles.perk...@earthlink.net]
Sent: Monday, January 22, 2018 2:27 PM
To: Bertz, Lyle T [CTO] 
Cc: dmm@ietf.org
Subject: Re: [DMM] Parent versus child mobility context

Hello Lyle,

More follow-up inline.  We're getting closer.


On 1/22/2018 11:27 AM, Bertz, Lyle T [CTO

[DMM] Using traffic Descriptors to characterize flows in a Mobility Context

[Charlie Perkins]

Hello Lyle and all,

I had an idea about characterizing the flows in a Mobility Context.

Namely, it seems that they can be characterized using the same kind of 
Descriptors that are already used in the Rules.  A Rule matches traffic 
against a Descriptor expression and if the traffic satisfies the 
Descriptor, some action is taken.


That's just about what we want to say about a flow -- namely, that it 
matches some Descriptor expression.


I am proposing to modify the Mobility Context to have some 
mobile-node-specific information and a List of Descriptors, just as we 
already reference under the Policy structure.  Since the Descriptors are 
located in an Indexed Set, the Mobility Context only has to supply the 
Descriptor-Key along with Descriptor-Values as before.


I am hoping this will provide a boost towards improving the naturalness 
of the Information Model for Mobility Context.


Comments?

Regards,
Charlie P.



On 1/22/2018 1:28 PM, Bertz, Lyle T [CTO] wrote:

More inline.

-Original Message-
From: Charlie Perkins [mailto:charles.perk...@earthlink.net]
Sent: Monday, January 22, 2018 2:27 PM
To: Bertz, Lyle T [CTO] 
Cc: dmm@ietf.org
Subject: Re: [DMM] Parent versus child mobility context

Hello Lyle,

More follow-up inline.  We're getting closer.


On 1/22/2018 11:27 AM, Bertz, Lyle T [CTO] wrote:

Hello Lyle and all,

I think I agree with most of what you say below.  I'm concerned with how to 
organize the information in the model.  So, for that purpose, please verify 
whether my following understandings are correct.

- The mobility context resides on a DPN.

- The mobility context provides necessary information (e.g., QoS) for a single 
mobile node.

- The DPN uses it to manage data-plane traffic for that mobile node.


This may be too broad of a view. What about a mobile node with
multiple mobility sessions? In such a case it may be managing one or
more (but not necessarily all of) the mobile node's mobility
sessions

Yes.  This is why I did not put "all" between "manage" and "data-plane".

LB > Ok.  We should probably be more explicit though for the casual observer if 
this language is used in the specification.


In my earlier email on this subject, I was using Mobility Context as describing something 
more associated with a mobile node, than with a particular flow.  If you want it to mean 
"bearer", then we ought to call it a Bearer.

Maybe it would be easier to understand if we had something called a "Mobile-Node Context", and in 
that context we had a set of Bearer Contexts (or, just Bearers).  Each bearer would inherit from the Mobile 
Node context simply by being part of it.  The Mobile Node context (serving as "parent") would 
determine max bandwidth, IP address, etc. Back in the old days, we also defined security aspects and some 
other factors, as part of what FPC would call the "mobility context".


We have several concepts that have hierarchy, e.g. Service Level (sr-id or APN 
- apn-oi if I recall), device level, Mobility Session, bearers, flow based 
filters (effectively living within a bearer).

There isn't anything about Service Level in the first part of the document, and I did not 
find anything about Service-ID that referenced mobility context.  Mobility Context does 
not define Service Level. Similarly for APN.  The string "-oi" does not occur 
in the document.

Device level is a mystery to me.

Now, this isn't to say that your comment is irrelevant.  But, at minimum, the 
relevance is not spelled out in the current document.
LB> Ack.  They are not mentioned these in the documents; I was merely providing 
examples.


 We also have the 5G concepts as well.

We have, in fact, an infinitude of mutually contradictory 5G concepts.
I might suggest that they look at Mobile IP, which was designed exactly
to provide high-speed, low-latency, application-independent mobility
management.  But, I digress.
LB> I am in agreement here but I believe that as Release 15 is finalized in 
3GPP we will see clarity.  My question would be if other next generation standards 
/ technologies follow so that we have a tractable problem space but I too, digress.


The one thing that is obvious is that the idea of hierarchy applies whether 
it is pacers/shapers, bearers or filters that apply some charging / gating / 
marking.  A light touch of lifecycle (fate sharing) amongst the hierarchy,  
data does not need to be repeated within the hierarchy and building the data 
structure by requiring a parent id if it was a child (implying the parent must 
exist!) was the best we could do without necessarily making decisions that may 
appear to preclude a specific set of mobile network technologies.

We certainly agree on the existence of hierarchy pervading our problem
space.  And on the need to consider fate-sharing for between mobile-node
authorizations and allocated bearers.

Re: [DMM] Question about Interface Groups (formerly, DPN Groups)

[Charlie Perkins]

Hello Lyle,

Thanks for the detailed reply.  It clears up a lot of questions in my 
mind.  To briefly reply:


- The reason I was asking about whether or not an Interface Group lived 
on a DPN was to help me figure out how to structure the Interface Group 
definition.  It's already structured as an Indexed Set, and so we will 
have an Interface-Group-Key.  The DPN structure will have a list of such 
keys, for each Interface Group that exists and includes an Interface 
from the DPN.  I think this is O.K. for your scenario of different 
security zones.  Notably, we do not provide that as an attribute of an 
Interface, but then again I don't think we could reasonably be expected 
to delineate all possible attributes of Interfaces.


An Interface Group will also have a DPN-Key, for the DPN that hosts its 
interfaces.


Your example about having to select a DPN to handle emergency calls as 
well as "normal" call processing is very interesting.  What if we make 
that to be two different access-network features, and enable selection 
of Interface Groups for each feature?  Then we are still O.K. with 
having each Interface Group to be configured with only one DPN-Key.


Regards,
Charlie P.

On 1/22/2018 1:49 PM, Bertz, Lyle T [CTO] wrote:


Your scenarios are correct.  I think we are in agreement but I want to 
clarify a few things:


Wrt your statement “(b) it makes good sense for all the Interfaces of 
an Interface Group to be hosted on the same DPN.”


Ack.  I agree when the required interfaces within an Interface Group 
can be hosted on the same DPN to service a request.  However, we leave 
DPN selection up to the implementations as they may have proprietary 
or other perfectly good reasons not to do this.  By the above 
statement I have interpreted it as a recommendation and not a mandate, 
i.e. it is not a requirement in FPC to do this.   Is that correct?


Wrt the statement “I just want all of the Interfaces of an Interface 
Group to be on the same DPN”


I wish that was always the case but when the interface types are 
different or have a different purpose, e.g. normal calls vs. emergency 
calls, this is not the case in practice.


In the model then are you proposing the Interface Groups only reside 
under the DPN structure? If so, then one must load all DPNs and index 
them by Interface Groups Id to determine they are from the same 
group.  The purpose in pulling them out was to create a single Set 
that could be used to house the typing and common configuration 
information. DPN interfaces assigned to support an Interface Group are 
then assigned to it.  Thus, if a DPN had 2 interfaces which are of the 
same type but in different security zones (or have different 
routes/networks served) they may not be able to serve in the same group.


Lyle

*From:*Charlie Perkins [mailto:charles.perk...@earthlink.net]
*Sent:* Monday, January 22, 2018 3:25 PM
*To:* Bertz, Lyle T [CTO] 
*Cc:* dmm@ietf.org
*Subject:* Re: Question about Interface Groups (formerly, DPN Groups)

Hello Lyle,

I agree that:

 1. - Interface Groups are designed to be used to select DPN.
 2. - Interface Groups may contain a number of different Interface Types
 3. - There may be more than one Interface Group providing equivalent
service, at least for the purpose of selecting a DPN.

For (1) -- I imagine that the selection process would look to make 
sure that the Interface Group has the proper interfaces that are 
needed (say, by the FPC Client).  Then, the FPC Client would select 
the DPN hosting the Interface Group, set up connectivity with the 
interfaces in the Peer Interface Group(s), and all is good.


For (2) -- this is really the motivation for the concept of Interface 
Groups.


For (3) -- really a follow-on from (1): the FPC Client would then look 
at the other properties of the DPN hosting the Interface Group, to 
determine which was the least cost, or highest benefit, choice.  Or 
alternatively the FPC Client would look at the Settings on the 
Interfaces of the Group, to see which Interfaces had the best fit for 
the purposes of the FPC Client.


If I have these scenarios right, then (a) we don't need to introduce 
any further virtual DPN definitions for proper operation and (b) it 
makes good sense for all the Interfaces of an Interface Group to be 
hosted on the same DPN.




The intent of the structure is for use during DPN selection. To
maintain it as a DPN means some DPNs are used during selection but
others are not.


I agree with this completely, if I understand it.  After the selection 
occurs based on the suitability of the Interface Group, its function 
is done.  I did not in any way mean to suggest that the Interface 
Group was ever going to be a DPN or a virtual DPN.


I just want all of the Interfaces of an Interface Group to be on the 
same DPN.


Regards,
Charlie P.


On 1/22/2018 11:36 AM, Bertz, Lyle T [CTO] wrote:

k. I think that we are crossing conversations now.

   

Re: [DMM] Question about Interface Groups (formerly, DPN Groups)

[Charlie Perkins]

Hello Lyle,

I agree that:

1. - Interface Groups are designed to be used to select DPN.
2. - Interface Groups may contain a number of different Interface Types
3. - There may be more than one Interface Group providing equivalent
   service, at least for the purpose of selecting a DPN.

For (1) -- I imagine that the selection process would look to make sure 
that the Interface Group has the proper interfaces that are needed (say, 
by the FPC Client).  Then, the FPC Client would select the DPN hosting 
the Interface Group, set up connectivity with the interfaces in the Peer 
Interface Group(s), and all is good.


For (2) -- this is really the motivation for the concept of Interface 
Groups.


For (3) -- really a follow-on from (1): the FPC Client would then look 
at the other properties of the DPN hosting the Interface Group, to 
determine which was the least cost, or highest benefit, choice. Or 
alternatively the FPC Client would look at the Settings on the 
Interfaces of the Group, to see which Interfaces had the best fit for 
the purposes of the FPC Client.


If I have these scenarios right, then (a) we don't need to introduce any 
further virtual DPN definitions for proper operation and (b) it makes 
good sense for all the Interfaces of an Interface Group to be hosted on 
the same DPN.



The intent of the structure is for use during DPN selection.   To 
maintain it as a DPN means some DPNs are used during selection but 
others are not.


I agree with this completely, if I understand it.  After the selection 
occurs based on the suitability of the Interface Group, its function is 
done.  I did not in any way mean to suggest that the Interface Group was 
ever going to be a DPN or a virtual DPN.


I just want all of the Interfaces of an Interface Group to be on the 
same DPN.


Regards,
Charlie P.



On 1/22/2018 11:36 AM, Bertz, Lyle T [CTO] wrote:


k. I think that we are crossing conversations now.

“An Interface Group on a DPN would also have have attributes for Peer 
Interface Groups residing on other DPNs. ” < Did not see that.


Interface Groups (aka DPN Groups) can be used for DPN pool selection 
(multiple options) with a different interface strategy.


Interface Groups (aka DPN Groups) may also contain hetergeneous 
DPN-Type (interface types).  In this case the totality of services 
could be provided by more than one DPN.


If we say that this is ‘just a virtual DPN with a selection strategy 
of multiple underlying DPNs” I feel that we are jamming too many 
concepts into the DPN.  Overloading is okay until one is overloaded ;)


The intent of the structure is for use during DPN selection. To 
maintain it as a DPN means some DPNs are used during selection but 
others are not.


I would propose that we keep this concept separate for now, look at 
proposed changes and then revisit this issue.


*From:*Charlie Perkins [mailto:charles.perk...@earthlink.net]
*Sent:* Monday, January 22, 2018 12:07 PM
*To:* Bertz, Lyle T [CTO] 
*Cc:* dmm@ietf.org
*Subject:* Re: Question about Interface Groups (formerly, DPN Groups)

Hello Lyle,

An Interface Group on a DPN would also have have attributes for Peer 
Interface Groups residing on other DPNs.  So, the data plane 
configuration can already exhibit the ("cross-DPN") interconnection 
between Interface Groups even if the interfaces of the Group all 
reside on the same DPN.


Could you give an example of an Interface Group that perforce requires 
to reside on multiple DPNs?  Is it a case that could be handled better 
by defining a virtual DPN to host the Interface Group?  I understand 
the word "containment" but I'm not at all clear about what sort of 
Group requires the extra complication to expedite the stated purpose, 
which is DPN selection.  If there are other purposes, I would be 
inclined to define other structures for them that do not have the 
effect of complicating the Interface Group definition.


Regards,
Charlie P.

On 1/22/2018 5:11 AM, Bertz, Lyle T [CTO] wrote:



No, I don’t think they should reside under a DPN.   Groups like
these also span multiple DPNs which would make containment graphs
    far too confusing.

*From:*Charlie Perkins [mailto:charles.perk...@earthlink.net]
*Sent:* Sunday, January 21, 2018 10:51 PM
*To:* Bertz, Lyle T [CTO] 
<mailto:lyle.t.be...@sprint.com>
*Cc:* Marco Liebsch 
<mailto:marco.lieb...@neclab.eu>; Satoru Matsushima

<mailto:satoru.matsush...@gmail.com>; Sri Gundavelli (sgundave)
 <mailto:sgund...@cisco.com>; Moses, Danny
 <mailto:danny.mo...@intel.com>; Weaver,
Farni [CTO] 
<mailto:farni.wea...@sprint.com>; Matsushima Satoru

<mailto:satoru.matsush...@g.softbank.co.jp>
*Subject:* Question about Interface Groups

Hello folks,

Can we have it so that all the Interfaces of an "Interface Group"
(formerly, "DPN Group") reside on the same DP

Re: [DMM] Parent versus child mobility context

[Charlie Perkins]

void sending redundant data (does one need
to send the mobile's IP address for any sort of sub-session work if it
is tied to a parent that already has it?)

-Original Message-
From: Marco Liebsch [mailto:marco.lieb...@neclab.eu]
Sent: Monday, January 22, 2018 5:49 AM
To: Charlie Perkins ; Bertz, Lyle T
[CTO] 
Cc: Satoru Matsushima ; Sri Gundavelli
(sgundave) ; Moses, Danny ;
Weaver, Farni [CTO] ; Matsushima Satoru

Subject: RE: Parent versus child mobility context

That has been introduced to reflect e.g. dedicated bearers which come on top of 
default bearers hence have some level of dependency. If context associated with 
a default bearer gets closed, dependent context will follow. To me it makes 
sense. Others?

marco

-Original Message-
From: Charlie Perkins [mailto:charles.perk...@earthlink.net]
Sent: Montag, 22. Januar 2018 06:29
To: Bertz, Lyle T [CTO]
Cc: Marco Liebsch; Satoru Matsushima; Sri Gundavelli (sgundave);
Moses, Danny; Weaver, Farni [CTO]; Matsushima Satoru
Subject: Parent versus child mobility context


Hello folks,

I have looked at this several times, and I would like to propose simplifying it 
to simply be a mobility context.  I don't see that the extra complication is 
worth it, especially right now.  If, in the future, we need it for something, 
we could put it back in.

Thanks for your consideration of this request.

Regards,
Charlie P.



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 recipient, please contact the sender and delete all copies of the 
message.

___
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] Question about Interface Groups (formerly, DPN Groups)

[Charlie Perkins]

Hello Lyle,

An Interface Group on a DPN would also have have attributes for Peer 
Interface Groups residing on other DPNs.  So, the data plane 
configuration can already exhibit the ("cross-DPN") interconnection 
between Interface Groups even if the interfaces of the Group all reside 
on the same DPN.


Could you give an example of an Interface Group that perforce requires 
to reside on multiple DPNs?  Is it a case that could be handled better 
by defining a virtual DPN to host the Interface Group?  I understand the 
word "containment" but I'm not at all clear about what sort of Group 
requires the extra complication to expedite the stated purpose, which is 
DPN selection.  If there are other purposes, I would be inclined to 
define other structures for them that do not have the effect of 
complicating the Interface Group definition.


Regards,
Charlie P.


On 1/22/2018 5:11 AM, Bertz, Lyle T [CTO] wrote:




No, I don’t think they should reside under a DPN.   Groups like these 
also span multiple DPNs which would make containment graphs far too 
confusing.


*From:*Charlie Perkins [mailto:charles.perk...@earthlink.net]
*Sent:* Sunday, January 21, 2018 10:51 PM
*To:* Bertz, Lyle T [CTO] 
*Cc:* Marco Liebsch ; Satoru Matsushima 
; Sri Gundavelli (sgundave) 
; Moses, Danny ; Weaver, 
Farni [CTO] ; Matsushima Satoru 


*Subject:* Question about Interface Groups

Hello folks,

Can we have it so that all the Interfaces of an "Interface Group" 
(formerly, "DPN Group") reside on the same DPN?


If so, I can make good sense out of the text in the document, but 
otherwise I think there are big problems.


I have some other questions, but this is the main thing right now.  If 
the answer to my question is "Yes" I think I will have a sensible 
revision tomorrow.


I have some more questions, not quite as important, which I will put 
in separate emails.


Regards,
Charlie P.

On 1/18/2018 5:26 AM, Bertz, Lyle T [CTO] wrote:

Charlie,

Glad to hear things are going well.  I’m looking forward to your
document update.

Lyle




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 recipient, please contact the sender and 
delete all copies of the message.


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

Re: [DMM] Parent versus child mobility context

[Charlie Perkins]

Hello Lyle and all,

I think I agree with most of what you say below.  I'm concerned with how 
to organize the information in the model.  So, for that purpose, please 
verify whether my following understandings are correct.


- The mobility context resides on a DPN.

- The mobility context provides necessary information (e.g., QoS) for a 
single mobile node.


- The DPN uses it to manage data-plane traffic for that mobile node.

- Your description seems to imply that there are separate mobility 
contexts for each mobility session (i.e., for each bearer, or flow) that 
terminates (or originates) on the mobile node.


In my earlier email on this subject, I was using Mobility Context as 
describing something more associated with a mobile node, than with a 
particular flow.  If you want it to mean "bearer", then we ought to call 
it a Bearer.


Maybe it would be easier to understand if we had something called a 
"Mobile-Node Context", and in that context we had a set of Bearer 
Contexts (or, just Bearers).  Each bearer would inherit from the Mobile 
Node context simply by being part of it.  The Mobile Node context 
(serving as "parent") would determine max bandwidth, IP address, etc.  
Back in the old days, we also defined security aspects and some other 
factors, as part of what FPC would call the "mobility context".


If you really want to maintain Parent Context and Child Context as 
independent structure elements, then we need to make a new indexed set 
for them.


Regards,
Charlie P.


On 1/22/2018 5:30 AM, Bertz, Lyle T [CTO] wrote:

++ mailing list

I agree with you Marco.

Keeping the parent/child relation is crucial.   Although we often cite 
dedicated vs. default bearers (LTE) we need to also ack that we use 
hierarchical concepts throughout mobility and forwarding management protocols, 
e.g. meters, session and sub-session (includes accounting), etc.

Lifecycle association here (fate sharing of the children with the parent) is an 
important concept.  Many of the mobility systems assume gateways (LMAs and 
MAGs) have knowledge of the relationships between sessions and sub-session and 
will often kill the session in order to reduce signaling overhead.  They also 
assume when installing a session / sub-session that any violation of hierarchy 
rules, e.g. setting a child's max bit rate above a parent's, would be properly 
enforced, i.e. it is an error or the child's value is ignored.

For FPC we also use it to avoid sending redundant data (does one need to send 
the mobile's IP address for any sort of sub-session work if it is tied to a 
parent that already has it?)

-Original Message-
From: Marco Liebsch [mailto:marco.lieb...@neclab.eu]
Sent: Monday, January 22, 2018 5:49 AM
To: Charlie Perkins ; Bertz, Lyle T [CTO] 

Cc: Satoru Matsushima ; Sri Gundavelli (sgundave) 
; Moses, Danny ; Weaver, Farni [CTO] 
; Matsushima Satoru 
Subject: RE: Parent versus child mobility context

That has been introduced to reflect e.g. dedicated bearers which come on top of 
default bearers hence have some level of dependency. If context associated with 
a default bearer gets closed, dependent context will follow. To me it makes 
sense. Others?

marco

-Original Message-
From: Charlie Perkins [mailto:charles.perk...@earthlink.net]
Sent: Montag, 22. Januar 2018 06:29
To: Bertz, Lyle T [CTO]
Cc: Marco Liebsch; Satoru Matsushima; Sri Gundavelli (sgundave); Moses, Danny; 
Weaver, Farni [CTO]; Matsushima Satoru
Subject: Parent versus child mobility context


Hello folks,

I have looked at this several times, and I would like to propose simplifying it 
to simply be a mobility context.  I don't see that the extra complication is 
worth it, especially right now.  If, in the future, we need it for something, 
we could put it back in.

Thanks for your consideration of this request.

Regards,
Charlie P.



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 recipient, please contact the sender and delete all copies of the 
message.


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

Re: [DMM] Some review comments on draft-matsushima-spring-dmm-srv6-mobile-uplane-03

[Charlie Perkins]

Hello Satoru,

Follow-up on a couple of details below...


On 11/29/2017 11:43 PM, Satoru Matsushima wrote:

Thank you Charlie, for your comments.


You're more than welcome!




As a general comment, I found it confusing about whether "legacy" means IPv4, or 
"non-SRv6" IPv6.  For instance, I am not sure about whether "D::1" is IPv4 or IPv6 in the 
first paragraph of section 6.3.1.  As a related matter, I think that relying solely on terminology like S::1, 
D::1, A2::1, A2::B2, and so on soon becomes confusing.  More diagrams would be nice.

Those represent 128bits of IPv6 source address, destination address and segment 
IDs. I suppose that the reader in the IETF can understand that. If not, yes 
need to improve it that introduce diagrams looks a good idea.


The addresses do indeed look like IPv6 example addresses.  But somewhere 
in the nearby text, there is reference to an IPv4 address as well.  So I 
was not really sure.






It should also be allowed that rate limiting is not done when there has not 
been any such rate-limit Locator provided.

Correct. But it seems too obvious for me.


It's obvious to me also.  But to 2,000 readers, it won't be obvious to 
every one of them.





The document states:


 ..   the mobile control-plane may
assume that one user-plane entity has one IPv6 address ...

I'm pretty sure this isn't true for IPv6 nodes.

I think it is true. I haven’t seen any document of which _mobile_ control-plane 
has the notion of node of user-plane in addition to just endpoint address of 
tunnel in its protocol.


All IPv6 nodes have link-local and multicast addresses in addition to 
their "normal" addresses.  Plus, in general, it has to be allowed for 
mobile nodes to have multiple addresses.  I also strongly suspect that 
the active forwarding nodes will often require multiple addresses, 
especially if SDN is involved.  Or network overlays, or NFV.



Regards,
Charlie P.

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

[DMM] Some review comments on draft-matsushima-spring-dmm-srv6-mobile-uplane-03

[Charlie Perkins]

Hello folks,

Here are some comments from my reading of the draft 
"matsushima-spring-dmm-srv6-mobile-uplane".


There are a lot of minor editorial revisions required, which I have 
already provided under separate email.


As I mentioned in previous email to this mailing list, I think it is 
important to describe previous efforts to provide a source-routing 
solution for mobility management, and to suggest reasons why the SRv6 
approach will find success despite the difficulties encountered by 
earlier efforts.


Much of the flexibility and power of the mechanism derives from the 
assumed existence of SRv6-capable routing nodes in the packet core, or 
at minimum at the edges of the core.  This is a reasonable assumption, 
but it diverges a bit from previous architectural guidelines by which we 
had attempted to minimize the mobility design impact on existing 
networks.  I hope that we can get some ideas about why such a new design 
philosophy is more appropriate now than in previous years.


This document naturally relies on existing SRv6 documents for 
terminology and understanding of the SRv6 operations.  In particular, 
reference is made to [I-D.filsfils-spring-srv6-network-programming], 
which is a nontrivial document to read.  I think it would be very nice 
if most of the terminology were explained in at least some detail within 
the mobile-uplane document in order to enable better progress within the 
[dmm] group.  Perhaps a lot of people in this group have not read the 
SRv6 documents in any great detail, at least not up to this point in time.


As a general comment, I found it confusing about whether "legacy" means 
IPv4, or "non-SRv6" IPv6.  For instance, I am not sure about whether 
"D::1" is IPv4 or IPv6 in the first paragraph of section 6.3.1.  As a 
related matter, I think that relying solely on terminology like S::1, 
D::1, A2::1, A2::B2, and so on soon becomes confusing.  More diagrams 
would be nice.


The document states:


   Existing mobile user-plane with IPv6 underlay is expected to be
   widely deployed.  Since IPv6 network should be interoperable with SRv6
   endpoints accommodated on it, interworking with existing IPv6
   network is out of scope of this document.


If I understand this correctly, it would be better to say that further 
specification is not needed for interworking with existing IPv6 
networks.  That's different than saying the interworking mechanism is 
out of scope.  And yet perhaps there is anyway something to say about 
whether firewalls would pass dataplane traffic carrying SRH (or why that 
doesn't matter).



The following claim needs a citation, I think:


Mobile user-plane requires a rate-limit feature.


Previous work in [dmm] and earlier mobility management working groups in 
the IETF have not placed this constraint in general for dataplane 
traffic.  Even for control plane traffic, mechanisms for rate limitation 
have not been designed very often.


Regarding the mechanism in the draft for rate limiting:


   In case of j bit length is zero in SID, the node should not do rate
   limiting unless static configuration or control-plane sets the limit
   rate associated to the SID.


It should also be allowed that rate limiting is not done when there has 
not been any such rate-limit Locator provided.


The mobile-uplane document goes into some depth to explain how 
interworking and anchoring work.  To do this, there are various examples 
with specific (example) addresses and named nodes. However, it is very 
important that the mobile node is registered somehow with the 
SRv6-capable nodes in the network.  The knowledge about where the mobile 
node is reachable in the access network has to be provided (in a secure 
way).  Maybe the specific registration control flow is reasonably kept 
separate from the user-plane operations, but at minimum the document has 
to describe exactly what is the assumed state of the network after the 
registration is complete.


The document states:


   A mobile network may be required to create a network slice that
   represents a set of network resources and isolates those resources from
   other slices.



The first clause seems to mean that the mobile network creates the 
slice.  Wouldn't the slice need to   be created before the mobile 
network exists?



Later in the same section:


   While network slicing has been discussed in the IETF and other
   standardization bodies, what functionalities are required for network
   slicing in mobile user-plane is further study item and to be
   discussed.



To me, this says that slicing is out of scope.  Maybe the discussion 
should be deleted.  Anyway, I think that slicing won't affect the design 
decisions for SRv6 mobility operations, regardless of how important 
slicing is in real life.


The document states:


    ..   the mobile control-plane may
   assume that one user-plane entity has one IPv6 address ...


I'm pretty sure this isn't true for IPv6 nodes.

Some of the t

Re: [DMM] Call for adoption of draft-matsushima-spring-dmm-srv6-mobile-uplane-03 as DMM WG document

[Charlie Perkins]

Hello folks,

The draft represents interesting work and I support adoption as a WG 
work item.


However, I also agree with Sri's assessment below.

I was co-author of source-routing proposals for both Mobile IPv4 and 
Mobile IPv6 that had many nice properties -- including minimal impact on 
the existing routing infrastructure.  There were similar proposals from 
several other authors.


All of them were soundly rejected.  So, it would be a good idea to find 
out what has changed during the last 15 years to make source routing 
"better" than it used to be.


Regards,
Charlie P.


On 11/14/2017 4:20 PM, Sri Gundavelli (sgundave) wrote:
Please also note that the document is just a starting point and 
requires significant amount of community efforts  and participation 
before it can become a standard. The document does not address most of 
the issues, but the proposal is promising enough and so would like to 
take it up right away. Please comment.


Dapping & Sri


From: dmm mailto:dmm-boun...@ietf.org>> on 
behalf of Sri Gundavelli mailto:sgund...@cisco.com>>

Date: Tuesday, November 14, 2017 at 4:02 PM
To: "dmm@ietf.org " >
Subject: [DMM] Call for adoption of 
draft-matsushima-spring-dmm-srv6-mobile-uplane-03 as DMM WG document


Folks:

The following message commences a two week call for opinions on the 
adoption of draft-matsushima-spring-dmm-srv6-mobile-uplane-03 as a DMM 
Working document.


---
The DMM working group is considering adopting the draft, 
"draft-matsushima-spring-dmm-srv6-mobile-uplane-03” as a working group 
document. The chairs have polled the room for opinions during IETF100, 
and it was determined that there is good support for taking up this 
work. The chairs would like to confirm the same in the mailing list. 
 Please provide your feedback.


Document Link:
https://www.ietf.org/id/draft-matsushima-spring-dmm-srv6-mobile-uplane-03.txt

Slides:
https://datatracker.ietf.org/meeting/100/materials/slides-100-dmm-srv6-for-mobile-user-plane/

Background:
https://datatracker.ietf.org/meeting/100/materials/slides-100-dmm-mobile-data-plane-evolution-motivation-goals/
---

Regards
Dapping & Sri



___
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

[DMM] Fwd: Re: Editorial revisions to FPC draft

[Charlie Perkins]

Hello folks,

Here are some comments that I had sent to the co-authors.  It was 
suggested that these discussions should really be carried out in a 
larger context.  Any comments will be appreciated.  I am in the process 
of receiving the editorial pen for the document and part of my purpose 
will be to reformulate some of the definitions.


Regards,
Charlie P.



 Forwarded Message 
Subject:Re: Editorial revisions to FPC draft
Date:   Tue, 14 Nov 2017 17:03:47 -0800
From:   Charlie Perkins 
To: 	Marco Liebsch , Satoru Matsushima 
, Sri Gundavelli (sgundave) 
, Moses, Danny , Bertz, Lyle 
T [CTO] 




Hello again folks,

Regarding some of the definitions...

I'd like to suggest the following:

- "-ID" should be *defined* to be an identifier.  Not a reference.

- "-Reference" should be *defined* to be a reference.  I understand
a reference to mean a way of locating an instance.  An identifier could
be a reference, if the identifier is also an index into an array of
instances, or a key into a database (or a pointer in C  [just kidding...]).

- for the purposes of this draft, we could restrict "name" to mean a
string of ASCII characters associated to an identifier. Not associated
to a reference.  If the string IS the identifier, then I am not sure if
the identifier has to have a "name" attribute.

- this, unfortunately, conflicts with the use of the word "namespace",
which undoubtedly does NOT mean a space of strings of ASCII characters.
Maybe "namespace" should be renamed to be "id-space".


As a bit of background for these remarks, I would like to suggest that
the document is quite abstract, by intention and design.  And I think
that is quite appropriate.  But, abstraction has its costs.  For one
thing, the abstract concepts have to be defined *extremely carefully*.
Otherwise the abstraction is more difficult to grasp.  Another cost is
that the abstraction has to be well motivated.  This can be done by
offering many examples. Or, you might say, many opportunities to connect
the dots between the stratosphere and what's visible on the ground.

...

Regards,
Charlie P.
...


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

Re: [DMM] Call for adoption of draft-matsushima-spring-dmm-srv6-mobile-uplane-03 as DMM WG document

[Charlie Perkins]

Hello Sri,

Could you summarize Suresh's comments regarding the acceptance of 
segment routing within [6man] WG?  I think it is relevant to this 
discussion.


Regards,
Charlie P.


On 11/14/2017 4:02 PM, Sri Gundavelli (sgundave) wrote:

Folks:

The following message commences a two week call for opinions on the 
adoption of draft-matsushima-spring-dmm-srv6-mobile-uplane-03 as a DMM 
Working document.


---
The DMM working group is considering adopting the draft, 
"draft-matsushima-spring-dmm-srv6-mobile-uplane-03” as a working group 
document. The chairs have polled the room for opinions during IETF100, 
and it was determined that there is good support for taking up this 
work. The chairs would like to confirm the same in the mailing list. 
 Please provide your feedback.


Document Link:
https://www.ietf.org/id/draft-matsushima-spring-dmm-srv6-mobile-uplane-03.txt

Slides:
https://datatracker.ietf.org/meeting/100/materials/slides-100-dmm-srv6-for-mobile-user-plane/

Background:
https://datatracker.ietf.org/meeting/100/materials/slides-100-dmm-mobile-data-plane-evolution-motivation-goals/
---

Regards
Dapping & Sri



___
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] Stephen Farrell's Discuss on draft-ietf-dmm-4283mnids-04: (with DISCUSS and COMMENT)

[Charlie Perkins]

Hello folks,

It has been suggested that the dmm WG members should to provide more 
support for the inclusion of the MNIDs that are listed in 
draft-ietf-dmm-4283mnids-04.


In order to resolve this issue, please send discussion to the [dmm] 
mailing list with thoughts about which of the types proposed in the 
draft are likely to require considerations about privacy when used in 
the Mobile Node Identifier option.  Also, for the proposed types, it has 
been requested to make some discussion about how their inclusion will 
help to improve the Internet.


Thanks in advance,
Charlie P.

On 2/15/2017 5:27 PM, Stephen Farrell wrote:

Stephen Farrell has entered the following ballot position for
draft-ietf-dmm-4283mnids-04: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer tohttps://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-dmm-4283mnids/



--
DISCUSS:
--


I don't consider that merely mentioning that there are some
privacy issues (maybe) is nearly sufficient here.  Instead I
would argue that any of these identifier types that could have
privacy implications need to be specifically justified or else
dropped. By specifically justified, I mean that there ought be
an argument (and a fairly holistic one) that the Internet is
better, and not worse, if we define a codepoint that allows
MIPv6 (and later, other protocols) to use that identifier.  I
do accept that my position is perhaps innovative, in terms of
IETF processes, so I'll split the discuss into two parts, one
process oriented and mostly for the IESG, and the second
relating to the content of the draft.

(1) For the IESG: is it ok that we introduce (codepoints for)
a slew of new long-term stable privacy-sensitive identifiers
just because they might someday be needed, or do we need to
have specific justification for defining such things? I would
argue the latter, but that may need us to validate that there
is IETF consensus for that somehow, and perhaps in the
meantime hold on to this draft. Part of my reasoning is that
once we define such codepoints (e.g. for IMSIs) then that
inevitably means that other protocols, and not just MIPv6,
will do the same eventually, so accepting this draft basically
means accepting that we end up commonly and perhaps
carelessly, passing such highly-sensitive information about on
the Internet in many protocols and in many contexts.  My
argument here I think does adhere to various of our BCPs that
do argue for security and privacy, but I do also accept that
this may be novel and to some extent goes against another of
our generally accepted ideas which is that we benefit from
folks documenting things even if those things are sub-optimal
in various ways. So I'd argue this is a real case for an IESG
discussion - I know what I think, but what do the rest of you
think?

(2) For the authors: to the extent you are willing to, and
want to get ahead of the discussion on point (1) above, can
you in fact provide an argument, for each of the identifiers
here that have privacy-sensitivity, that the Internet is better
overall if we define these codepoints knowing that if we do
define a way to represent e.g. an IMSI in MIPv6 that is likely
to be copied elsewhere? Note for the authors: I think it's
entirely fine for you to do nothing pending the discussion of
point (1) above, if that's your preference.


--
COMMENT:
--


While I'm entirely sympathetic to Mirja's discuss point, I
don't think that a statement here can really constrain how
these identifiers, once they are defined, are used in other
protocols. While there is a chance that some IESG sometime
might say "hold on, RFC (this doc) says you SHOULD encrypt
if  identifier is used" the chances that a future IESG
notice this isn't that high, but it's also even more likely
that the designers of future protocols will successfully argue
that since not all identifiers are privacy sensitive, their
specific protocol need not adhere to the SHOULD. In the end, I
think that should or SHOULD will be ineffective.


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

[Charlie Perkins]

Hello Dale,

O.K.  I will take a crack at making this reorganization.  If you have 
text of course that will be appreciated.  Right now I don't see why 
anyone in the WG would object, but I hope at least some people will take 
a look.


I can have the revised draft ready in a few days.  I think this resolves 
the last point of discussion that has been raised about the draft.


Regards,
Charlie P.


On 2/14/2017 5:04 PM, Dale R. Worley wrote:

Charlie Perkins  writes:

I am hesitant to replace so many MNID types by a single URN type with
substructure.  What would you think about replacing the existing
RFID-*-URI types with a single URN type, but leaving the existing binary
types?  This gets the benefit you suggest for future extensibility, but
retains the shorter forms that may often be advantageous.

Suddenly today I realized something I should have realized in the
review, which would have saved us much time in discussion.  Viz.,
consider this proposal:

- one MNID type for *all* the EPC binary schemes

- one MNID type for *all* URNs, *including* the EPC URI forms

This would work, since (1) (not surprisingly) the EPC binary schemes are
all differentiated by their first 8 bits.  (see table on page 19 of the
tag-data standard,
http://www.gs1.org/gsmp/kc/epcglobal/tds/tds_1_1_rev_1_27-standard-20050510.pdf)
and (2) all URNs are differentiated by their namespace part.

(This parallels using one MNID number for all DUID types, since DUIDs
have an internal indicator for the four types.)

This approach has all the desirable properties anyone has mentioned so
far:

- includes all EPC binary and URI forms
- automatically includes all existing and future EPC binary forms
- automatically includes all existing and future URN forms *including*
   all existing and future EPC URI forms
- doesn't have a proliferation of MNID type numbers which duplicate
   information that can be fairly easily extracted from the
   identifier itself
- includes all the short EPC forms, allowing brevity when that is
   desirable

This seems to be practical, simple, and almost as elegant as possible.
What do you think?


I changed the text as follows:


 Some MNIDs contain sensitive identifiers which, as used in protocols
 specified by other SDOs, are only used for signaling during initial
 network entry.  In such protocols, subsequent exchanges then rely on
 a temporary identifier allocated during the initial network entry.
 Managing the association between long-lived and temporary identifiers
 is outside the scope of this document.

I can't remember exactly why this text was added - it was a long time
ago.  But anyway the main point is to simply mention that there may be
associations between some of the MNID types that might be important from
a security standpoint, without meaning to go into examples.

Certainly the new text is clear enough.

Dale



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

Re: [DMM] Mirja Kühlewind's Discuss on draft-ietf-dmm-4283mnids-04: (with DISCUSS)

[Charlie Perkins]

Hello Mirja,

My previous answer was intended to mean that I would change to MUST.

Would you be willing to suggest some text about the non-leakage? I 
thought that the point of strengthening to MUST was to ensure that 
sensitive identifier information was not leaked.  If there is something 
more to be said, I'll be happy to say it.


Regards,
Charlie P.



On 2/15/2017 4:46 AM, Mirja Kühlewind wrote:

Hi Charlie,

can you please also answer the question below on SHOULD vs. MUST? Thanks!

Also, does it maybe make sense to then add something in the security 
section that information should/must not be leaked to other networks?


Thanks!
Mirja


On 13.02.2017 22:06, Charlie Perkins wrote:

Hello Mirja and Suresh,

I am happy to make the proposed changes as agreed below.

Regards,
Charlie P.


On 2/11/2017 1:00 AM, Mirja Kuehlewind (IETF) wrote:

Hi Suresh,

sounds all good! I’m happy to quickly resolve my discuss if the 
authors agree!


Mirja


Am 11.02.2017 um 05:05 schrieb Suresh Krishnan 
:


HI Mirja,

On Feb 10, 2017, at 12:08 PM, Mirja Kuehlewind 
 wrote:


Mirja Kühlewind has entered the following ballot position for
draft-ietf-dmm-4283mnids-04: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut 
this

introductory paragraph, however.)


Please refer to 
https://www.ietf.org/iesg/statement/discuss-criteria.html

for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-dmm-4283mnids/



-- 


DISCUSS:
-- 



I would realy like to see the following changes in the security
considerations section:
OLD
"If used in the MNID extension as defined in this
  document, the packet including the MNID extension should be
encrypted
  so that personal information or trackable identifiers would not be
  inadvertently disclosed to passive observers."
NEW
"If used in the MNID extension as defined in this
  document, the packet including the MNID extension SHOULD be
encrypted
  so that personal information or trackable identifiers would not be
  inadvertently disclosed to passive observers.”
Is this just for changing the "should" to upper case? I think that 
makes sense.



Or even better make it a MUST? Is there a reason for only having a
SHOULD?

Authors, any specific reason for this to be a SHOULD?


as well as the following change:
OLD
"Moreover, MNIDs containing sensitive identifiers might only be used
  for signaling during initial network entry. "
NEW
"Moreover, MNIDs containing sensitive identifiers MUST only be used
  for signaling during initial network entry and MUST NOT be 
leaked to

  other networks.”
The statement in OLD: is just a statement of fact that in some 
networks use temporary identifiers for reattachment and they use 
long term (and hence sensitive) identifiers only at initial attach. 
I don’t think it makes sense to change this to 2119 language.


Thanks
Suresh









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

Re: [DMM] Review of draft-ietf-dmm-4283mnids-04

[Charlie Perkins]

Hello Dale,

Follow-up below...

On 2/12/2017 7:13 PM, Dale R. Worley wrote:



There is a sort of "hidden" disadvantage to long names, especially for
tiny devices using constrained link layers.  Namely, a longer name makes
it more likely to require lower-layer fragmentation.  I'm not sure that
it should be the job of a layer-3 mobility entity to parse URNs and
determine if two different flavors are supposed to be equivalent.

Other than that, I don't have any real objection to reorganizing the
namespace, but I'd like some additional confirmation that it's a good idea.

There are a couple of reasons I like this idea.

One is that EPC seems to have a policy of providing a URN form for all
of the identifier classes it defines.  Making a single URN MNID type
means that you've incorporated all future classes of identifier that EPC
defines.

A single URN MNID type would incorporate any of the defined URN
namespaces that turn out to be useful for anybody.  This isn't so
interesting for really large deployments, since they could ask for a new
MNID type, but experimental or small-scale deployments may want to
define their own identifiers, and URNs provide several convenient ways
to do that.

It removes a certain amount of redundancy, in that each RFID class now
has three representations, for a total of 20 MNID types, whereas they
could all be collapsed into one MNID type.

The negatives I see are:

Some URN schemes do not have a unique representation as a character
string.  In practice, this is combated by either (1) Code that handles
URNs of arbitrary namespace copies and compares them as character
strings.  Users of such systems know to write URNs that have multiple
representations in a canonical form.  Or, (2) Code that handles one or a
small fixed set of URN namespaces knows the canonicalization/comparison
rules for those namespaces.  Generally, using these processes doesn't
cause problems in practice.  I expect that whatever receives the MNID
and looks it up in appropriate databases would not be a constrained
device, so it could process URNs carefully.

If the link layer is constrained, longer identifiers may require
fragmentation.  Changing a 96-bit binary representation into a URN seems
to add something like 40 octets, given the examples I've found online.
OTOH, it seems that the MNID is only transmitted when attaching to a
network, and so having that one packet require extra work doesn't seem
to be much of a penalty.

The all-URN ides envisions embedding IMSI and possibly MSISDN into the
gsma URN namespace.  (IMEI is already embedded as urn:gsma:imei:...)
That would take additional specification, although I don't see that
being controversial.  (Andrew Allen  would be a
good contact for doing this.)


I am hesitant to replace so many MNID types by a single URN type with 
substructure.  What would you think about replacing the existing 
RFID-*-URI types with a single URN type, but leaving the existing binary 
types?  This gets the benefit you suggest for future extensibility, but 
retains the shorter forms that may often be advantageous.





5.  Security Considerations

The base MNID specification, RFC 4283, gives these security
considerations (sec 4), which ought to be referenced and probably
summarized in this section:

 Moreover, MNIDs containing sensitive identifiers might only be used
 for signaling during initial network entry.  Subsequent binding
 update exchanges might then rely on a temporary identifier allocated
 during the initial network entry, perhaps using mechanisms not
 standardized within the IETF.  Managing the association between long-
 lived and temporary identifiers is outside the scope of this
 document.

What is the meaning of the word "might" in paragraph 3?  I suspect
that the purpose is to qualify this paragraph with "One way to
address
these vulnerabilities is to only use MNIDs containing ...".  But if
that is the meaning, that expanded wording should be used.  Otherwise
the text reads as if it is hypothetical.

This text was meant to be generally descriptive, so that people wanting
to include the Mobile Node Identifier Option with the relevant MNIDs
could understand how the identifiers are actually used in various
circumstances.  I could replace constructions using "might" with "in
some specifications" or "in some situations" if needed.  Is it also
necessary to include citations to the relevant documents of the external
SDO?

I'd definitely prefer some other term than "might".  I'm not sure why,
but I think that it's because "might" isn't used much in specifications




I changed the text as follows:


Some MNIDs contain sensitive identifiers which, as used in protocols
specified by other SDOs, are only used for signaling during initial
network entry.  In such protocols, subsequent exchanges then rely on
a temporary identifier allocated during the initial network entry.
Managing the association between long-lived and temporary 

Re: [DMM] Mirja Kühlewind's Discuss on draft-ietf-dmm-4283mnids-04: (with DISCUSS)

[Charlie Perkins]

Hello Mirja and Suresh,

I am happy to make the proposed changes as agreed below.

Regards,
Charlie P.


On 2/11/2017 1:00 AM, Mirja Kuehlewind (IETF) wrote:

Hi Suresh,

sounds all good! I’m happy to quickly resolve my discuss if the authors agree!

Mirja



Am 11.02.2017 um 05:05 schrieb Suresh Krishnan :

HI Mirja,


On Feb 10, 2017, at 12:08 PM, Mirja Kuehlewind  wrote:

Mirja Kühlewind has entered the following ballot position for
draft-ietf-dmm-4283mnids-04: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-dmm-4283mnids/



--
DISCUSS:
--

I would realy like to see the following changes in the security
considerations section:
OLD
"If used in the MNID extension as defined in this
  document, the packet including the MNID extension should be
encrypted
  so that personal information or trackable identifiers would not be
  inadvertently disclosed to passive observers."
NEW
"If used in the MNID extension as defined in this
  document, the packet including the MNID extension SHOULD be
encrypted
  so that personal information or trackable identifiers would not be
  inadvertently disclosed to passive observers.”

Is this just for changing the "should" to upper case? I think that makes sense.


Or even better make it a MUST? Is there a reason for only having a
SHOULD?

Authors, any specific reason for this to be a SHOULD?


as well as the following change:
OLD
"Moreover, MNIDs containing sensitive identifiers might only be used
  for signaling during initial network entry. "
NEW
"Moreover, MNIDs containing sensitive identifiers MUST only be used
  for signaling during initial network entry and MUST NOT be leaked to
  other networks.”

The statement in OLD: is just a statement of fact that in some networks use 
temporary identifiers for reattachment and they use long term (and hence 
sensitive) identifiers only at initial attach. I don’t think it makes sense to 
change this to 2119 language.

Thanks
Suresh





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

Re: [DMM] Review of draft-ietf-dmm-4283mnids-04

[Charlie Perkins]

Hello Dale,

Thanks for the thorough review.  My follow-up comments are inline below.


On 1/31/2017 11:34 AM, Dale Worley wrote:

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


I will add some text according to your suggestion.  My criterion for 
whether the identifier type was included in the document was whether or 
not anyone had asked for it to be included.




- 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


It is not the jurisdiction of the MNIDs document to specify these 
identifiers, but citations for the specifications are located elsewhere 
in the document.  I will also include those citations here.




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.


I don't know why this happened, but I am happy to include an identifier 
type for IMEI as well as a citation for it.  Thanks for catching this 
and looking through the archives!




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.


Actually, I am O.K. either way on this matter.  However, at this point 
in time it does not seem that we are likely to see any other link 
hardware address types to be used as MNIDs.




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 representati

Re: [DMM] Review of draft-ietf-dmm-4283mnids-04

[Charlie Perkins]

Hello folks,

The last two days have been crammed full with other urgent work 
requirements.  I will respond to these comments today.


Suresh, do you mean to ask if I can submit a revised document before Monday?

Regards,
Charlie P.


On 2/10/2017 6:17 AM, Suresh Krishnan wrote:

Hi Charlie,
   I have not yet seen a response to this review. Do you think you will be able 
to get to this in the next day or two? The document is on the February 16 2017 
telechat and I would like to see resolution to these issues in time for the 
other ADs to ballot.

Thanks
Suresh

On 2/2/17, 1:10 AM, "Charlie Perkins"  wrote:

 Hello Sri,
 
 The review was indeed super.  I'll respond sometime in the next few days.
 
 Regards,

 Charlie P.
 
 
 On 2/1/2017 9:09 PM, Sri Gundavelli (sgundave) wrote:

 > Thank you Dale for a great review.
 >
 >
 > Charlie/Authors - Can you please respond to Dale and address these
 > comments.
 >
 >
 > Regards
 > Sri
 >
 >
 > On 1/31/17, 11:34 AM, "dmm on behalf of Dale Worley" 
 on behalf of wor...@ariadne.com> wrote:
 >
 >> 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
 >> <http://wiki.tools.ietf.org/area/gen/trac/wiki/GenArtfaq>.
 >>
 >> 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.

Re: [DMM] Review of draft-ietf-dmm-4283mnids-04

[Charlie Perkins]

Hello Sri,

The review was indeed super.  I'll respond sometime in the next few days.

Regards,
Charlie P.


On 2/1/2017 9:09 PM, Sri Gundavelli (sgundave) wrote:

Thank you Dale for a great review.


Charlie/Authors - Can you please respond to Dale and address these
comments.


Regards
Sri


On 1/31/17, 11:34 AM, "dmm on behalf of Dale Worley"  wrote:


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 fu

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

[Charlie Perkins]

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] [Int-dir] Review of draft-ietf-dmm-4283mnids-03

[Charlie Perkins]

Hello again Tatuya,

Here is an updated description of the IPv6 address type when used as a MNID:


4.1.  Description of the IPv6 address type

The IPv6 address [RFC4291] is encoded as a 16 octet string containing
the full IPv6 address.  The IPv6 address MUST be a unicast routable
IPv6 address.  Multicast addresses, link-local addresses, and the
unspecified IPv6 address MUST NOT be used.  IPv6 Unique Local
Addresses (ULAs) MAY be used, as long as any security operations
making use of the ULA also take into account the domain in which the
ULA is guaranteed to be unique.


Please let me know if this resolves your concern.

Regards,
Charlie P.


On 1/15/2017 9:08 PM, Charlie Perkins wrote:

Hello Tatuya,

Thank you for the careful review.  Follow-up below:


On 1/6/2017 11:08 AM, Tatuya Jinmei wrote:

- Section 4.1: I guess the MNID is generally supposed to be unique
(at
   least in the realm the ID is used), but not all IPv6 addresses are
   guaranteed to be unique (a link-local or unspecified address is an
   obvious example, an ULA may also be inappropriate depending on the
   usage context).  It may be better to note the fact, and you may
also
   want to impose some restrictions on the type of address that can be
   used as an MNID.


This is correct.  I will fashion some language as suggested.  I think 
it is appropriate to allow ULAs, but multicast and unspecified 
addresses seem clearly inappropriate, and I am i favor of disallowing 
link-local addresses.

.

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

Re: [DMM] Review of draft-ietf-dmm-4283mnids-03

[Charlie Perkins]

Hello Tatuya,

Thank you for the careful review.  Follow-up below:


On 1/6/2017 11:08 AM, Tatuya Jinmei wrote:

- Section 4.1: I guess the MNID is generally supposed to be unique
(at
   least in the realm the ID is used), but not all IPv6 addresses are
   guaranteed to be unique (a link-local or unspecified address is an
   obvious example, an ULA may also be inappropriate depending on the
   usage context).  It may be better to note the fact, and you may
also
   want to impose some restrictions on the type of address that can be
   used as an MNID.


This is correct.  I will fashion some language as suggested.  I think it 
is appropriate to allow ULAs, but multicast and unspecified addresses 
seem clearly inappropriate, and I am i favor of disallowing link-local 
addresses.


- Section 4.5

2000, modulo 2^32.  Since the link-layer address can be of
variable
length [RFC2464], the DUID-LLT is of variable length.

   I don't understand why RFC2464 is referenced in this context.  This
   RFC is about IPv6 over Ethernet, and assumes a fixed (6 bytes)
   length of hardware address.


I don't quite know what to do about this.  I actually just copied this 
language from RFC 3315.  I think that the citation is also wrong in RFC 
3315, for the same reason as given here.  I could simply delete the 
reference to RFC 2464.





- Section 4.9: s/is (GRAI)/(GRAI)/

The Global Returnable Asset Identifier is (GRAI) is defined by the




Fixed.  I also checked for other similar instances and did not find any.

Regards,
Charlie P.

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

Re: [DMM] I-D Action: draft-ietf-dmm-fpc-cpdp-05.txt

[Charlie Perkins]

Hello folks,

I am in the process of reviewing the FPC document.  It is an important 
document and will be foundational for subsequent work in [dmm].  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.


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


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.


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.


Regards,
Charlie P.


On 10/31/2016 9:54 AM, internet-dra...@ietf.org wrote:

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Distributed Mobility Management of the IETF.

 Title   : Protocol for Forwarding Policy Configuration (FPC) 
in DMM
 Authors : Satoru Matsushima
   Lyle Bertz
   Marco Liebsch
   Sri Gundavelli
   Danny Moses
Filename: draft-ietf-dmm-fpc-cpdp-05.txt
Pages   : 153
Date: 2016-10-31

Abstract:
This document describes the solution of data-plane separation from
control-plane which enables a flexible mobility management system
using agent and client functions.  To configure data-plane nodes and
functions, the data-plane is abstracted by an agent interface to the
client.  The data-plane abstraction model is extensible in order to
support many different type of mobility management systems and data-
plane functions.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-dmm-fpc-cpdp/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-dmm-fpc-cpdp-05

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-dmm-fpc-cpdp-05


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

___
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] notes taker for DMM meeting

[Charlie Perkins]

Hello folks,

If no one else has volunteered, I will do it.

Regards,
Charlie P.


On 11/12/2016 9:21 AM, jouni.nospam wrote:

Folks,

If you feel like volunteering for taking notes during the meeting send an email 
to the chairs.

- Jouni & Dapeng
___
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] IPR call for draft-ietf-dmm-4283mnids-02

[Charlie Perkins]

Hello folks,

I am not aware of any IPR related to this document.

Regards,
Charlie P.


On 9/2/2016 8:39 AM, Dapeng Liu wrote:
All authors:  please reply to this mail whether you are aware any IPR 
related to this document: draft-ietf-dmm-4283mnids-02



Thanks,
Dapeng & Jouni


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

Re: [DMM] I-D Action: draft-ietf-dmm-4283mnids-01.txt

[Charlie Perkins]

Hello Hakima,

I am O.K. with including more MNID types.  The short addresses in Zigbee 
are purely local; that might be a consideration that affects inclusion 
within a Mobile-IP / dmm oriented draft.  I could see arguments either way.


Regarding the other identifiers for IoT -- are they proprietary?

If there is support for the identifiers listed below I will include them 
in the next revision.


It has been suggested to include short sections that describe each MNID 
type.  Would you be willing to contribute some sample section text for 
one or more of the RFID types?  I don't think it should be very long, 
and should not be misconstrued as specifying any of the behavior for 
RFID, only as a description.


Regards,
Charlie P.


On 10/19/2015 10:51 PM, Hakima Chaouchi wrote:

Hi Charles, all,

The draft is not mentioning the short addresses in Zigbee (16bits), 
lot of sensors use that.


What about the new long range technologies in IoT (Sig Fox, LORA)


Do you think we should consider in this draft a possibility of having 
logical identifiers as the Internet of Things main architectures today 
are pushing to have an abstraction layer between the application 
servers processing the data of the objects (that might be mobile)


Cheers,

Hakima

2015-10-19 22:39 GMT+02:00 Charlie Perkins 
mailto:charles.perk...@earthlink.net>>:


Hello folks,

The updated MNIDs draft has been posted.

I've incorporated potential resolutions for the recent comments,
especially from Sri.  I did not make subsections for each type of
MNID, because I am hoping that won't be considered necessary.  I
hope to get some more discussion about it from folks on this
mailing list.  Or, if I get a sample text for one of the MNIDs, I
can attempt to create similar text for the other MNIDs.  Notably,
doing so would make the short draft about 5 times longer.

Regards,
Charlie P.



On 10/19/2015 1:21 PM, internet-dra...@ietf.org
<mailto:internet-dra...@ietf.org> wrote:

A New Internet-Draft is available from the on-line
Internet-Drafts directories.
  This draft is a work item of the Distributed Mobility
Management Working Group of the IETF.

 Title   : MN Identifier Types for RFC 4283
Mobile Node Identifier Option
 Authors : Charles E. Perkins
   Vijay Devarapalli
Filename: draft-ietf-dmm-4283mnids-01.txt
Pages   : 8
Date: 2015-10-19

Abstract:
Additional Identifier Types are proposed for use with the
Mobile Node
Identifier Option for MIPv6 (RFC 4283).


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-dmm-4283mnids/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-dmm-4283mnids-01

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-dmm-4283mnids-01


Please note that it may take a couple of minutes from the time
of submission
until the htmlized version and diff are available at
tools.ietf.org <http://tools.ietf.org>.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

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


___
dmm mailing list
dmm@ietf.org <mailto: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] I-D Action: draft-ietf-dmm-4283mnids-01.txt

[Charlie Perkins]

Hello folks,

The updated MNIDs draft has been posted.

I've incorporated potential resolutions for the recent comments, 
especially from Sri.  I did not make subsections for each type of MNID, 
because I am hoping that won't be considered necessary.  I hope to get 
some more discussion about it from folks on this mailing list.  Or, if I 
get a sample text for one of the MNIDs, I can attempt to create similar 
text for the other MNIDs.  Notably, doing so would make the short draft 
about 5 times longer.


Regards,
Charlie P.


On 10/19/2015 1:21 PM, internet-dra...@ietf.org wrote:

A New Internet-Draft is available from the on-line Internet-Drafts directories.
  This draft is a work item of the Distributed Mobility Management Working 
Group of the IETF.

 Title   : MN Identifier Types for RFC 4283 Mobile Node 
Identifier Option
 Authors : Charles E. Perkins
   Vijay Devarapalli
Filename: draft-ietf-dmm-4283mnids-01.txt
Pages   : 8
Date: 2015-10-19

Abstract:
Additional Identifier Types are proposed for use with the Mobile Node
Identifier Option for MIPv6 (RFC 4283).


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-dmm-4283mnids/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-dmm-4283mnids-01

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-dmm-4283mnids-01


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

___
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] Review comments on draft-ietf-dmm-4283mnids-00.txt

[Charlie Perkins]

Hello Sri,

Thanks for that terrific review.  Please see my follow-up below and 
request for

additional discussion.

On 10/11/2015 6:16 PM, Sri Gundavelli (sgundave) wrote:

1.  Introduction

The Mobile Node Identifier Option for MIPv6 [RFC4283] has proved to
be a popular design tool for providing identifiers for mobile nodes
during authentication procedures with AAA protocols such as Diameter
[RFC3588].  To date, only a single type of identifier has been
specified, namely the MN NAI.  Other types of identifiers are in
common use, and even referenced in RFC 4283.
*[Sri] Some text on the motivation for defining new Types may be 
helpful. Document is not just standardizing the currently 
in-use/popular identifier types, its also introducing new types are 
not in use. The reasons/interest for defining identifiers that are 
tied to the physical elements of the device (RFID, MAC address ..etc) 
and how it helps in deployment of the technology may be useful. Few 
lines of text will really help.*


Here is the paragraph with some new text:

  In this document, we
   propose adding some basic types that are commonly in use in various
   telecommunications standards, including the IMSI, P-TMSI, IMEI, GUTI,
   and IEEE MAC-layer addresses.  In addition, we include the IPv6
   address itself as a legitimate mobile node identifier.
   Defining identifiers that are tied to the physical elements of the
   device (RFID, MAC address etc.) help in deployment of Mobile IP
   because in many cases such identifiers are the most natural means
   for uniquely identifying the device, and will avoid additional
   look-up steps that might be needed if other identifiers were used.


  including the IMSI, P-TMSI, IMEI, GUTI,
and IEEE MAC-layer addresses.  In addition, we include the IPv6
address itself as a legitimate mobile node identifier.
*[Sri] References for IMSI, P-TMSI, IMEI, GUTI; May be 3GPP TS 23.003.*


Will do.


2.  New Mobile Node Identifier Types

The following types of identifiers are commonly used to identify
mobile nodes.  For each type, references are provided with full
details on the format of the type of identifer.

EPC supports several encoding systems or schemes including
*[Sri] EPC? EPC Tag Standards I assume, not the Evolved Packet Core. 
Reference to [EPC-Tag-Data] will help *


Will do.




o  RFID-GID (Global Identifier),
o  RFID-SGTIN (Serialized Global Trade Item Number),

 .. /many lines deleted/ ..

o  RFID-DOD-URI [RFID-DoD-96]
o  RFID-GIAI-URI [EPC-Tag-Data]
o  39-255 reserved

*[Sri] This is a major issue. > I was hoping to see a sub-section for 
each of the types. We cannot > standardize a identifier type without 
providing any explanation on the > identifier type or the references 
to the base definitions. This can > be painful, but I'd have a small 
section for each of the types. It can > be 3 line text on the a.) 
Definition b.) Format c.) Example format d.) > Reference to the base 
spec that defines those identifiers.*


This might be dangerous, because it would be a partial respecification for
for identifiers outside the general expertise of this group.  But I will
try to think of something.  Contributed text will be very much appreciated.


3.  Security Considerations

This document does not introduce any security mechanisms, and does
not have any impact on existing security mechanisms.  Insofar as the
selection of a security association may be dependent on the exact
form of a mobile node identifier, additional specification may be
necessary when the new identifier types are employed with the general
AAA mechanisms for mobile node authorizations.

Some identifiers (e.g., IMSI) are considered to be private
information.  If used in the MNID extension as defined in this
document, the packet including the MNID extension should be encrypted

*[Sri] Besides the use of IMSI, the document also defines the use of 
other sensitive identifiers such as IPv6..*


Do you think that IPv6 addresses are more sensitive than IPv4 addresses?

*Mention of the available tools for privacy protection may be helpful. 
Some thing along these lines, or better text:*
*"This information is considered to be very sensitive, so care must be 
taken to secure the Mobile IPv6/Proxy Mobile IPv6 signaling messages 
when carrying this sub-option. The base Proxy Mobile IPv6 
specification [RFC5213] specifies the use of IPsec for securing the 
signaling messages, and those mechanisms can be enabled for protecting 
this information. Operators can potentially apply IPsec Encapsulating 
Security Payload (ESP) with confidentiality and integrity protection 
for protecting the location information."*

**

I am O.K. with that text.  However, the same considerations apply to
RFC 4283, so that the initial paragraph is still sort-

Re: [DMM] WG Last Call for draft-ietf-dmm-4283mnids-00

[Charlie Perkins]

Hello Jouni,

I think the document is pretty straightforward, and offers a useful 
facility.  New MN ID types can be added in the future.


Disclaimer - I am a co-author of the document.

Regards,
Charlie P.


On 8/18/2015 11:43 AM, Jouni Korhonen wrote:

A friendly reminder.

- Jouni & Dapeng

8/12/2015, 11:35 AM, Jouni Korhonen kirjoitti:

Folks,

This mail starts a two week WGLC #1 for the I-D
draft-ietf-dmm-4283mnids-01. The WGLC ends 26th August 2015 EOB Pacific
time.

Please, review the document and indicate your support or concerns on the
mailing list. If you have concerns or comments that you want to be
reflected in the draft text issue a ticket into the issue tracker as
well. We urge you to utilize the issue tracker for comments that you
want to be resolved.

- Dapeng and Jouni


___
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] RFC4283bis progress..

[Charlie Perkins]

Hello folks,

The last discussion about the document was related to whether or not 
Vehicle ID should be included in the draft.  No resolution was reached 
for that discussion.


However, the draft may still be considered ready for publication. Other 
ID formats can certainly be added in the future.


Regards,
Charlie P.


On 7/9/2015 6:30 PM, Sri Gundavelli (sgundave) wrote:
 I can review and provide comments. I think its ready for publication, 
may be after a minor edit.




From: dmm mailto:dmm-boun...@ietf.org>> on 
behalf of jouni korhonen <mailto:jouni.nos...@gmail.com>>

Date: Thursday, July 9, 2015 at 1:49 PM
To: "dmm@ietf.org <mailto:dmm@ietf.org>" <mailto:dmm@ietf.org>>, Charlie Perkins <mailto:charlie.perk...@huawei.com>>

Subject: [DMM] RFC4283bis progress..

Charlie, WG,

In last IETF and slightly after that there was discussion about 
missing MN-IDs in the current -00 version. Have these been or rather 
will these be addressed? I'd like to move this trivial document forward.


- Jouni & Dapeng


___
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] Call for adoption: draft-perkins-dmm-4283mnids-01

[Charlie Perkins]

Hello Behcet,

On 4/23/2015 10:11 AM, Behcet Sarikaya wrote:

The model of Internet access to the cars for cars currently on market in
Europe is the same - the LTE technology is used, using the IMSI as an
identifier.  However, that does not use MN-ID, is only IPv4, is not WiFi and
does not resist to cellular generation upgrades to 5G and beyond.

I don't understand the handover scenario. I think you are mixing the
car and the passengers in the car.
LTE is available on a large geography, why should you handover the
upstream traffic to Wi-Fi?




I think the IETF should be enabling solutions that do not presume the
availability of LTE.  There are likely to be applications for which reduced
(or zero) cost is important.

Regards,
Charlie P.

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

Re: [DMM] Call for adoption: draft-perkins-dmm-4283mnids-01

[Charlie Perkins]

Hello folks,

The ...-00 document draft-dmm-4283mnids-00.txt has been submitted.

I'll make a new draft with VIN as a type of MNID as soon as Alex's 
questions have

proposed answers.

Regards,
Charlie P.


On 4/21/2015 12:55 PM, Alexandru Petrescu wrote:

Le 16/04/2015 06:58, Jouni Korhonen a écrit :

Folks,

The adoption call for this I-D has ended. There is a clear concensus to
adopt the I-D as a working group item.


I support its adoption.

We have been working with an identifier specific to automobiles to use 
to realize access control.  Identifying an entire set of IP nodes 
deployed in a vehicle is different than identifying an end-user like 
address@realm.


We looked for such an identifier and believe the VIN (Vehicle 
Identification Number) be a good candidate.


One would consider using one type, like type 40, to encode the VIN or 
parts of it, into an MN-ID.


The questions to the group are the following:
- is VIN considered private information? (in deployments it is private
  to a certain extent, but publicly avaliable to cameras or in public
  databases to another extent).
- is the MN-ID type 40 ok for it.
- is one type sufficient or should there be subtypes.

Yours,

Alex



- Jouni & Dapeng

4/1/2015, 8:02 AM, Jouni Korhonen kirjoitti:

Folks,

This emails starts a two week call for the I-D
   draft-perkins-dmm-4283mnids-01
to confirm the aadoption s a DMM WG document. The call ends April 15th
EOB PST.

Express your support or opposition to the mailing list. During the
IETF92 meeting we got 7 voices for the adoption so at least the same
amount supporting emails should be expected.

- Jouni & Dapeng


___
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



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

[DMM] Fwd: Re: Maintenance of Mobile IPv6

[Charlie Perkins]

This email to the list bounced earlier today...!

 Original Message 
Subject:Re: [DMM] Maintenance of Mobile IPv6
Date:   Wed, 29 Oct 2014 11:19:37 -0700
From:   Charlie Perkins 
To: Alexandru Petrescu 
CC: dmm@ietf.org 



Hello Alex and all,

Interesting discussion.  Here's my take.

On 10/29/2014 10:03 AM, Alexandru Petrescu wrote:



-

- help with automated portal authentication in WLAN.  Hopping on and
  off from a WiFi hotspot to another, even without moving physically,
  is often obstructed by web portal authentication requiring user
  to type to fill forms; this is not only inconvenient, but in some
  cases it is impossible, like with vehicular networks where the
  driver is forbidden by law to type while behind the wheel.


I would love to work on this.  If you have ideas, please describe.




- bugs in an otherwise reliable Mobile IPv6 implementation of
  a particular equipment manufacturer (HA never deletes a tunnel,
  lifetime: remaining never): should the bugs be corrected or shoudl
  the spec modified to reflect what the implementation actually
  does?  Should protocol workarounds be designed to deal with this
  problem?


My answers: (1) no, and (2) not within [dmm].



- future of the maintenance of the linux open source Mobile IPv6
  implementation: just for my clarification - is it still ok?  Is there
  some project behind it?  Or is it dying?  Currently the email list
  seems silent, and the latest software releases date back to more than
  one year.


If [dmm] shows itself to be a credible force, the open source problems
will naturally get the proper attention.  But it shouldn't be on the
[dmm] charter.



- elimination, or reducing the effect, of the necessity of the 'focal
  point' Home Agent: route optimization for the masses and for moving
  networks as deployed in vehicles.


Isn't this already on the radar for [dmm]?



- Mobile IPv6 and IPv6 NAT Traversal;

- IPv6 NAT in a moving network;

- bypassing Mobile IPv6 implementation (and use IPv6 NATting) in cases
  of particular applications, based on destination IPv6 address and
  IPv6-only-when-reversed FQDN name.

- the use of ULAs combined with Global addresses, with Mobile IPv6
  (e.g. ULA HoA but GUA CoA, or reverse).


For these four items, it will depend on whether there is a constituency
for action.


And, one more thing:

On 10/29/2014 10:46 AM, Alexandru Petrescu wrote:

Le 29/10/2014 18:40, Brian Haberman a écrit :



On 10/29/14 1:33 PM, Alexandru Petrescu wrote:


I agree yes.  Are there enhancements that can be made to the Mobile
IPv6
specs in particular RFC6275, RFC3963, RFC4877, RFC6276.


I personally do not know.  But as Jouni suggested, write a draft on the
enhancements you want to see and get feedback.


Brian - thank you for the invitation.  Maybe I will do.

Now that the deadline passed it's for the next year.  I will keep a
mark on these emails.


You don't have to wait!  In fact you can submit a draft even on the
first day of the IETF.

For the four topics above, that would be very appropriate, I think.

Regards,
Charlie P.



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

Re: [DMM] Maintenance of Mobile IPv6

[Charlie Perkins]

Hello Alex and all,

Interesting discussion.  Here's my take.

On 10/29/2014 10:03 AM, Alexandru Petrescu wrote:



- 


- help with automated portal authentication in WLAN.  Hopping on and
  off from a WiFi hotspot to another, even without moving physically,
  is often obstructed by web portal authentication requiring user
  to type to fill forms; this is not only inconvenient, but in some
  cases it is impossible, like with vehicular networks where the
  driver is forbidden by law to type while behind the wheel.


I would love to work on this.  If you have ideas, please describe.




- bugs in an otherwise reliable Mobile IPv6 implementation of
  a particular equipment manufacturer (HA never deletes a tunnel,
  lifetime: remaining never): should the bugs be corrected or shoudl
  the spec modified to reflect what the implementation actually
  does?  Should protocol workarounds be designed to deal with this
  problem?


My answers: (1) no, and (2) not within [dmm].



- future of the maintenance of the linux open source Mobile IPv6
  implementation: just for my clarification - is it still ok?  Is there
  some project behind it?  Or is it dying?  Currently the email list
  seems silent, and the latest software releases date back to more than
  one year.


If [dmm] shows itself to be a credible force, the open source problems
will naturally get the proper attention.  But it shouldn't be on the
[dmm] charter.



- elimination, or reducing the effect, of the necessity of the 'focal
  point' Home Agent: route optimization for the masses and for moving
  networks as deployed in vehicles.


Isn't this already on the radar for [dmm]?



- Mobile IPv6 and IPv6 NAT Traversal;

- IPv6 NAT in a moving network;

- bypassing Mobile IPv6 implementation (and use IPv6 NATting) in cases
  of particular applications, based on destination IPv6 address and
  IPv6-only-when-reversed FQDN name.

- the use of ULAs combined with Global addresses, with Mobile IPv6
  (e.g. ULA HoA but GUA CoA, or reverse).


For these four items, it will depend on whether there is a constituency
for action.


And, one more thing:

On 10/29/2014 10:46 AM, Alexandru Petrescu wrote:

Le 29/10/2014 18:40, Brian Haberman a écrit :



On 10/29/14 1:33 PM, Alexandru Petrescu wrote:


I agree yes.  Are there enhancements that can be made to the Mobile 
IPv6

specs in particular RFC6275, RFC3963, RFC4877, RFC6276.


I personally do not know.  But as Jouni suggested, write a draft on the
enhancements you want to see and get feedback.


Brian - thank you for the invitation.  Maybe I will do.

Now that the deadline passed it's for the next year.  I will keep a 
mark on these emails.


You don't have to wait!  In fact you can submit a draft even on the
first day of the IETF.

For the four topics above, that would be very appropriate, I think.

Regards,
Charlie P.

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

[DMM] Fwd: New Version Notification for draft-perkins-dmm-privacy-00.txt

[Charlie Perkins]

Hello folks,

We have put together a draft about privacy considerations for DMM.

Privacy is a very timely subject, and I think that it should be a kept in
mind during all design phases for the DMM teams.

This is a simple and short draft to invite discussion.  No doubt there
is a lot of room for expansion of the discussion, and we will be happy
to incorporate other guidelines or references to other relevant IETF
publications that may be suggested.

I have requested a time slot at the upcoming IETF for a discussion
about privacy as it is related to DMM protocol development.

Regards,
Charlie P.


 Original Message 
Subject:New Version Notification for draft-perkins-dmm-privacy-00.txt
Date:   Mon, 27 Oct 2014 14:59:33 -0700
From:   
To: 	Charles E. Perkins , Sri Gundavelli 
, Charles E. Perkins , Sri 
Gundavelli 




A new version of I-D, draft-perkins-dmm-privacy-00.txt
has been successfully submitted by Charles E. Perkins and posted to the
IETF repository.

Name:   draft-perkins-dmm-privacy
Revision:   00
Title:  Privacy considerations for DMM
Document date:  2014-10-26
Group:  Individual Submission
Pages:  6
URL:
http://www.ietf.org/internet-drafts/draft-perkins-dmm-privacy-00.txt
Status: https://datatracker.ietf.org/doc/draft-perkins-dmm-privacy/
Htmlized:   http://tools.ietf.org/html/draft-perkins-dmm-privacy-00


Abstract:
   Recent events have emphasized the importance of privacy in protocol
   design.  This document describes ways in which DMM protocol designs
   and DMM networks can reduce certain threats to privacy.

  



Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat




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

[DMM] Fwd: New Version Notification for draft-perkins-dmm-4283mnids-01.txt

[Charlie Perkins]

Hello folks,

The MNIDs draft has been updated.  Comments are welcome, and the
draft will be discussed at the Hawaii meeting if there is time.

Regards,
Charlie P.



 Original Message 
Subject:New Version Notification for draft-perkins-dmm-4283mnids-01.txt
Date:   Mon, 27 Oct 2014 15:10:50 -0700
From:   
To: 	Charles E. Perkins , Charles E. Perkins 





A new version of I-D, draft-perkins-dmm-4283mnids-01.txt
has been successfully submitted by Charles E. Perkins and posted to the
IETF repository.

Name:   draft-perkins-dmm-4283mnids
Revision:   01
Title:  MN Identifier Types for RFC 4283 Mobile Node Identifier Option
Document date:  2014-10-27
Group:  Individual Submission
Pages:  7
URL:
http://www.ietf.org/internet-drafts/draft-perkins-dmm-4283mnids-01.txt
Status: https://datatracker.ietf.org/doc/draft-perkins-dmm-4283mnids/
Htmlized:   http://tools.ietf.org/html/draft-perkins-dmm-4283mnids-01
Diff:   http://www.ietf.org/rfcdiff?url2=draft-perkins-dmm-4283mnids-01

Abstract:
   Additional Identifier Types are proposed for use with the Mobile Node
   Identifier Option for MIPv6 (RFC 4283).

  



Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat




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

Re: [DMM] AERO and Mobile IP comparison

[Charlie Perkins]

Hello Fred,

A few little follow-up questions...

On 10/7/2014 11:39 AM, Templin, Fred L wrote:

From: Charlie Perkins [mailto:charles.perk...@earthlink.net]

...
This implies local-only mobility, right?

Not just local, but global also. Take for example an AERO mobile router that is 
connecting
over an access link provided by some ISP other than its home network. In that 
case, the
node typically remains connected to its home link by setting up a VPN 
connection via a
security gateway connected to its home network. In that case, the AERO link is 
said to
be extended *through* the security gateway. So, the AERO mobile router remains
tethered to its home link via the VPN, but  it can set up route optimization 
with Internet
correspondents in a manner similar to MIPv6. In that case, communications with 
the
Internet correspondent can bypass the home network.


- Is the VPN setup part of AERO?
- How does the mobile router know whether or not to do this?
- Why would the external AERO servers admit traffic from the AERO client?
Or, is AERO completely out of the picture for external networks?
- Is the route optimization simply a matter of VPN to the correspondent 
node?

Or, did you mean to suggest use of the MIPv6 mechanisms?

Regards,
Charlie P.


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

Re: [DMM] AERO and Mobile IP comparison

[Charlie Perkins]

Hello Fred,

One comment:

On 10/7/2014 11:08 AM, Templin, Fred L wrote:

- the mobility archetype for AERO is that of a mobile router that stays 
connected to its
   home link even if it changes between access link technologies


This implies local-only mobility, right?

If so, then I guess from your other description that "local" is
engineered to be huge.  But more to the point it puts AERO
pretty much in direct competition with PMIP -- or, perhaps
PMIP with LMAs stitched together by way of BGP.

Regards,
Charlie P.

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

Re: [DMM] Fwd: New Version Notification for draft-perkins-dmm-4283mnids-00.txt

[Charlie Perkins]

Hello again folks,

Here is a proposed text for a new paragraph in the Security Considerations:



   Some identifiers (e.g., IMSI) are considered to be private
   information.  If used in the MNID extension as defined in this
   document, the packet including the MNID extension should be encrypted
   so that personal information or trackable identifiers would not be
   inadvertently disclosed to passive observers.  Moreover, MNIDs
   containing sensitive identifiers might only be used for signaling
   during initial network entry.  Subsequent binding update exchanges
   would then rely on a temporary identifier allocated during the
   initial network entry.


Comments will be appreciated.

Regards,
Charlie P.



On 9/25/2014 12:02 PM, Charles E. Perkins wrote:


Hello folks,

I think the best solution for this would be a section in the Security
Considerations explaining the need.   I will fashion some text for the
upcoming revision -01.txt

Regards,
Charlie P.


On 9/24/2014 10:48 AM, Sri Gundavelli (sgundave) wrote:

Hi Pierrick,

The NAI that is used in S2a/S5 procedures is a IMSI-NAI, based on 
3GPP TS 23.003. It is sent in PBU/PBA messages. Not sure, if IMSI 
information is seen as a confidential IE. But, I agree on the need to 
include some text on how the signaling message can be protected with 
privacy / confidentiality service set, when the identifier is based 
on some confidential data.



Regards
Sri

From: "pierrick.se...@orange.com " 
mailto:pierrick.se...@orange.com>>

Date: Wednesday, September 24, 2014 8:56 AM
To: "Charles E. Perkins" >, "dmm@ietf.org " 
mailto:dmm@ietf.org>>
Subject: Re: [DMM] Fwd: New Version Notification for 
draft-perkins-dmm-4283mnids-00.txt


Hi Charlie,

Thanks for the list... it looks good. I'm just wondering about 
security considerations... Actually, from 3GPP standpoint, security 
constrains on IMSI and GPRSS/LTE temporary identifiers (P-TMSI, 
GUTI). AFAIK, IMSI is very rarely sent on the air (maybe only one 
time at the beginning of the 3GPP authentication process) for 
security reasons. So, I'm wondering if adding IMSI to the list of 
IDs, without any warnings, is somehow introducing security weakness 
to the 3GPP security process.   Consequently, I'm not sure about the 
following statement "This document does not introduce any security 
mechanisms, and does not have any impact on existing security 
mechanisms." It's maybe not so true from the 3GPP point of view...


Maybe we should state that the ID option MUST be used in a way that 
it does not harm existing security mechanisms (i.e. use the option 
with caution J). For example, to address the issue above (maybe there 
are other examples... I don't know...), we could state that the IMSI 
should be transmitted only during first binding update, and not 
transmitted anymore as long as the association IMSI/HoA/HNP is 
done Or... simpler way to address the issue:  if nobody has 
use-case for transmitting the IMSI, we can simply remove the IMSI 
from the list J


BR,

Pierrick

*De :*dmm [mailto:dmm-boun...@ietf.org] *De la part de* Charles E. 
Perkins

*Envoyé :* mardi 23 septembre 2014 21:10
*À :* dmm@ietf.org 
*Objet :* [DMM] Fwd: New Version Notification for 
draft-perkins-dmm-4283mnids-00.txt


Hello folks,

We have published a ...-00 version of the MNIDs draft.  This is 
mainly for

reference purposes.  A new version should be out within a week or so,
incorporating the suggestions and comments from people who responded
to the earlier suggestion to revisit this work.

Regards,
Charlie P.



 Original Message 

*Subject: *



New Version Notification for draft-perkins-dmm-4283mnids-00.txt

*Date: *



Tue, 23 Sep 2014 10:43:12 -0700

*From: *



 

*To: *



Charles E. Perkins  
, Vijay Devarapalli 
 
, Charles 
E.Perkins  


A new version of I-D, draft-perkins-dmm-4283mnids-00.txt
has been successfully submitted by Charles E. Perkins and posted to the
IETF repository.
  
Name: draft-perkins-dmm-4283mnids

Revision: 00
Title:MN Identifier Types for RFC 4283 Mobile Node Identifier Option
Document date: 2014-09-23
Group:Individual Submission
Pages:4
URL:http://www.ietf.org/internet-drafts/draft-perkins-dmm-4283mnids-00.txt
Status:https://datatracker.ietf.org/doc/draft-perkins-dmm-4283mnids/
Htmlized:http://tools.ietf.org/html/draft-perkins-dmm-4283mnids-00
  
  
Abstract:

Additional Identifier Types are proposed for use with the Mobile Node
Identifier Option for MIPv6 (RFC 4283).
  
   
  
  
Please note that it may take a couple of minutes from the time of submission

until the html

Re: [DMM] MNID Types

[Charlie Perkins]

Hello Hakima,

I'm putting in the RFID as a selection in the draft.  I have two
questions:

- Do we need to include various types of RFIDs?
- Can you send good citations for the Normative References?

I have 
http://www.acq.osd.mil/log/sci/ait/DoD_Suppliers_Passive_RFID_Info_Guide_v15update.pdf 
but I am not sure if that's the correct normative reference.


Regards,
Charlie P.

On 9/21/2014 8:11 AM, Hakima Chaouchi wrote:

Hello Folks,

Do you think that considering specific but needed technologies for 
moving objects in  Internet of Things  such as RFID (Radio Frequency 
Identifier) with 96 bits identifiers will be also relevent to 
Charlie's current draft and the efforts related to MNID?


Regards,

Hakima



*De: *"Sri Gundavelli (sgundave)" 
*À: *"Charlie Perkins" , "Marco 
Liebsch" , dmm@ietf.org, "Vijay Devarapalli" 


*Envoyé: *Jeudi 11 Septembre 2014 23:57:11
*Objet: *Re: [DMM] MNID Types

Hi Charlie,

Few more reviews/discussions and capturing the consensus in the base 
version will help. But, I'm ok either way …



Regards
Sri

From: Charlie Perkins <mailto:charles.perk...@earthlink.net>>

Date: Thursday, September 11, 2014 2:46 PM
To: Sri Gundavelli mailto:sgund...@cisco.com>>, 
Marco Liebsch <mailto:marco.lieb...@neclab.eu>>, "dmm@ietf.org 
<mailto:dmm@ietf.org>" mailto:dmm@ietf.org>>, Vijay 
Devarapalli mailto:dvi...@rocketmail.com>>

Subject: Re: [DMM] MNID Types


Hello folks,

I propose to submit the -00.txt document as it is to the Internet
Drafts directory, and then to go about making updates according to
the discussion on this list.  Do you think this is reasonable?

Regards,
Charlie P.


On 9/11/2014 7:21 AM, Sri Gundavelli (sgundave) wrote:




Marco,


Thinking further on the complementary identifier option.

- There is already the link-layer identifier option that can be used for
carrying the Mac address
- IMEI and MSISDN are already defined in 29.275 as a 3GPP VSE's

In some sense, the complementary identifiers are already present.

Sri





On 9/11/14 6:58 AM, "Sri Gundavelli (sgundave)"  wrote:

I do not see a reason why multiple MN-Id instances need to be present 
in a
single message ? In my experience, this is strictly a deployment
consideration, when to use what type of identifiers.

Assuming the backend system can tie all the MN-Id's to a single
subscription, any presented identifier can be sufficient for the gateway
to do the BCE lookup.

If multiple instances can be present, then we need to deal with more 
error
cases. Is that really needed ?


I am wondering if it would not be more appropriate to go for a 
different
container option to carry such information. Something like a
complementary identifier option.

Sounds interesting. Are you suggesting we leave the current MN-ID as it
is, but use a new complementary option ? But, if the requirement is for 
a
Mac based identifiers, what will be there in the current MN-Id option ? 
We
still need to have identifier there ?




Sri





On 9/11/14 2:03 AM, "Marco Liebsch"  wrote:

No issue with logical vs. physical ID. But I am wondering about two
things:

Operation is clear to me in case a single MNID is present in a 
message
and I see the value in being
flexible to choose from different sub-types. If multiple MNIDs with
different sub-types are present in
a single message, which one should e.g. the LMA take for the BC 
lookup..
No big problem to solve, but
to be considered in implementations.

If the reason for multiple present MNIDs with different sub-types 
is to
do other things than identifying
the node or using the ID as key for a lookup, I am wondering if it 
would
not be more appropriate
to go for a different container option to carry such information.
Something like a complementary
identifier option.

marco

-Original Message-
    From: Sri Gundavelli (sgundave) [mailto:sgund...@cisco.com]
Sent: Donnerstag, 11. September 2014 00:42
To: Charlie Perkins; Marco Liebsch;dmm@ietf.org
Cc: Vijay Devarapalli
Subject: Re: [DMM] regarding the re-chartering..

Hello Charlie,

Agree with that. MN-Id as its defined today is a logical 
identifier. It
does not
require the identifier to be bound to a physical device or a 
interface
identity.
But, we h

Re: [DMM] MNID Types

[Charlie Perkins]

Hello folks,

I propose to submit the -00.txt document as it is to the Internet
Drafts directory, and then to go about making updates according to
the discussion on this list. Do you think this is reasonable?

Regards,
Charlie P.


On 9/11/2014 7:21 AM, Sri Gundavelli (sgundave) wrote:
>
> 
>
>
> Marco,
>
>
> Thinking further on the complementary identifier option.
>
> - There is already the link-layer identifier option that can be used for
> carrying the Mac address
> - IMEI and MSISDN are already defined in 29.275 as a 3GPP VSE's
>
> In some sense, the complementary identifiers are already present.
>
> Sri
>
>
>
>
>
> On 9/11/14 6:58 AM, "Sri Gundavelli (sgundave)"  wrote:
>
>> I do not see a reason why multiple MN-Id instances need to be present in a
>> single message ? In my experience, this is strictly a deployment
>> consideration, when to use what type of identifiers.
>>
>> Assuming the backend system can tie all the MN-Id's to a single
>> subscription, any presented identifier can be sufficient for the gateway
>> to do the BCE lookup.
>>
>> If multiple instances can be present, then we need to deal with more error
>> cases. Is that really needed ?
>>
>>
>>> I am wondering if it would not be more appropriate to go for a different
>>> container option to carry such information. Something like a
>>> complementary identifier option.
>> Sounds interesting. Are you suggesting we leave the current MN-ID as it
>> is, but use a new complementary option ? But, if the requirement is for a
>> Mac based identifiers, what will be there in the current MN-Id option ? We
>> still need to have identifier there ?
>>
>>
>>
>>
>> Sri
>>
>>
>>
>>
>>
>> On 9/11/14 2:03 AM, "Marco Liebsch"  wrote:
>>
>>> No issue with logical vs. physical ID. But I am wondering about two
>>> things:
>>>
>>> Operation is clear to me in case a single MNID is present in a message
>>> and I see the value in being
>>> flexible to choose from different sub-types. If multiple MNIDs with
>>> different sub-types are present in
>>> a single message, which one should e.g. the LMA take for the BC lookup..
>>> No big problem to solve, but
>>> to be considered in implementations.
>>>
>>> If the reason for multiple present MNIDs with different sub-types is to
>>> do other things than identifying
>>> the node or using the ID as key for a lookup, I am wondering if it would
>>> not be more appropriate
>>> to go for a different container option to carry such information.
>>> Something like a complementary
>>> identifier option.
>>>
>>> marco
>>>
>>>> -Original Message-
>>>> From: Sri Gundavelli (sgundave) [mailto:sgund...@cisco.com]
>>>> Sent: Donnerstag, 11. September 2014 00:42
>>>> To: Charlie Perkins; Marco Liebsch; dmm@ietf.org
>>>> Cc: Vijay Devarapalli
>>>> Subject: Re: [DMM] regarding the re-chartering..
>>>>
>>>> Hello Charlie,
>>>>
>>>> Agree with that. MN-Id as its defined today is a logical identifier. It
>>>> does not
>>>> require the identifier to be bound to a physical device or a interface
>>>> identity.
>>>> But, we have clearly seen requirements where the need is for generating
>>>> identifiers based on some physical identifiers. Those physical
>>>> identifiers include
>>>> IMSI, MSISDN, IMEI, MAC ..etc. If we can define a type for each of the
>>>> source
>>>> and the rules for generating MN-ID based using those sources, the sender
>>>> and
>>>> receiver will have clear guidance on how to use the spec. Some pointers,
>>>> explanation and examples for each of those identifiers will greatly help
>>>> avoid
>>>> inter-op issues.
>>>>
>>>>
>>>> Regards
>>>> Sri
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> On 9/10/14 3:21 PM, "Charlie Perkins" 
>>>> wrote:
>>>>
>>>>> Hello folks,
>>>>>
>>>>> I think it's best to consider the MNID as simply living in a space of
>>>>> identifiers, and not worry too much about whether it's a logical
>>>>> identifier or a physical identifier.  If the former, then somewhere
>>>>>

Re: [DMM] regarding the re-chartering..

[Charlie Perkins]

Hello folks,

I think it's best to consider the MNID as simply living in a space of
identifiers, and not worry too much about whether it's a logical identifier
or a physical identifier.  If the former, then somewhere (perhaps below
the network layer) the logical identifier has been bound to something
in the physical interface, but that's not our problem.

The number space for types of MNIDs is likely to stay pretty empty,
so I'd say we could add as many types as would be convenient for the
software designers.  So, we could conceivably have several MNIDs
defined that all "looked like" NAIs (which, themselves, "look like"
FQDNs).

Regards,
Charlie P.



On 9/10/2014 8:11 AM, Sri Gundavelli (sgundave) wrote:

Yes. Currently, the MNID is if the nai format and is overloaded. The MNID
in 3GPP specs is the IMSI-NAI (IMSI@REALM), its based on the IMSI. Ex:
"@epc.mnc.mcc.3gppnetwork.org²

We also have MAC48@REALM;

We also have approaches to transform MAC to Pseudo IMSI, and then carry
IMSI-NAI as the MN-ID.


So, we need unique sub-types for each of the types/sources.

MN-Id based on IMSI, MSISDN, IMEI, MAC ..

Also, do we need to distinguish between IMSI and IMSI-NAI ?

Sri



On 9/10/14 6:29 AM, "Marco Liebsch"  wrote:


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.

marco


-Original Message-
From: dmm [mailto:dmm-boun...@ietf.org] On Behalf Of Sri Gundavelli
(sgundave)
Sent: Dienstag, 9. September 2014 23:30
To: Sri Gundavelli (sgundave); Charlie Perkins; dmm@ietf.org
Cc: Vijay Devarapalli
Subject: Re: [DMM] regarding the re-chartering..

Two more comments.



4.) I'd also use sub-type value of (2) for IMSI. Just to align with the
sub-types
defined for MN Id defined for ICMP. I suspect there are some
implementations
already using sub-type (2). Please see the other thread.


5.) For each of the sub-types, we need text including examples and some
explanation on how they are used.


Sri



On 9/9/14 2:20 PM, "Sri Gundavelli (sgundave)" 
wrote:


Hi Charlie,

This is good. Thanks.


1.) If EUI-48 and EUI-64 addresses are derived of a 48-bit IEEE 802.2
address, why do we need to two sub-types ? Why not have just one
sub-type for mac based identifiers ?

2.) Sub type value (1) is currently used. Its currently overloaded for
IMSI-NAI (3GPP specs) and generic NAI based identifiers. Given the
definition of new sub-types, we need some text explaining the
motivation

3.) Proposed Sub-type value of (2) for IPv6 address. What exactly is
this ? Are these CGA-based IPv6 addresses ?




 New Mobile Node Identifier Types

   +-++
   | Identifier Type | Identifier Type Number |
   +-++
   | IPv6 Address| 2  |
   | ||
   | IMSI| 3  |
   | ||
   | P-TMSI  | 4  |
   | ||
   | EUI-48 address  | 5  |
   | ||
   | EUI-64 address  | 6  |
   | ||
   | GUTI| 7  |
   +-++







Regards
Sri
PS: Good to see Vijay back


On 9/9/14 1:28 PM, "Charlie Perkins" 
wrote:


Hello folks,

Here's the last Internet Draft that we did, long ago expired:
http://www.ietf.org/archive/id/draft-perkins-mext-4283mnids-01.txt

I'll resubmit it with a few updates as a personal draft to dmm.

Regards,
Charlie P.

___
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




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

Re: [DMM] regarding the re-chartering..

[Charlie Perkins]

Hello folks,

Here's the last Internet Draft that we did, long ago expired:
http://www.ietf.org/archive/id/draft-perkins-mext-4283mnids-01.txt

I'll resubmit it with a few updates as a personal draft to dmm.

Regards,
Charlie P.


On 9/9/2014 2:04 AM, pierrick.se...@orange.com wrote:

Hi,

I second Charlie on this proposal, especially on the need for additional MNID 
and tunnel types. Another example for the latter is: using GRE with MIP/NEMO.

BR,
Pierrick


-Message d'origine-
De : dmm [mailto:dmm-boun...@ietf.org] De la part de Charlie Perkins
Envoyé : lundi 8 septembre 2014 19:50
À : MONGAZON-CAZAVET, BRUNO (BRUNO); dmm@ietf.org
Objet : Re: [DMM] regarding the re-chartering..


Hello folks,

I'll go look for the link(s).  But in the meantime, as part of the ongoing
maintenance work, I'd be happy to see the following:

- Additional tunnel types (including GTP)
- Additional mobile node identifier types (including IMSI, MAC, ...)
- Additional security mechanisms

If there is a sliver of a chance that we could go down any one or more of these
paths, I will resurrect the old Internet drafts as well. If people are 
interested, I
will re-submit them for the November meeting.

There are two or three other things that Mobile IP needs also, that take more
words to express, but not necessarily directly related to distributed mobility
management.  Much of my development had to do with trying to provide an
easier / incremental path for the deployment of Mobile IP by SDO partners in
3GPP, which would necessitate inclusion in their standards, which (for
instance) seems to necessitate GTP as a tunneling protocol, etc.

Regards,
Charlie P.



On 9/7/2014 11:57 PM, MONGAZON-CAZAVET, BRUNO (BRUNO) wrote:

On 05/09/2014 19:10, Charlie Perkins wrote:

Hello folks,

I have made various presentations at IETF, some from many years ago,
proposing that Mobile IP enable use of GTP as a tunneling option.  I
still think that would be a good idea.  Should I re-re-revive a draft
stating this in more detail?

I would be interested to look at this draft.
Thanks.
Bruno



Regards,
Charlie P.


On 9/5/2014 1:48 AM, Alper Yegin wrote:

Alex,

DMM is not meant to be only about a bunch of MIP-based solutions.
There are various components in DMM solution space that'd also work
with GTP-based architectures.
For example, identifying the mobility needs of flows.
Or, conveying the mobility characteristic of a prefix to the UE.

Alper




On Sep 4, 2014, at 1:14 PM, Alexandru Petrescu wrote:


Le 03/09/2014 20:53, Brian Haberman a écrit :

Behcet,

On 9/3/14 2:33 PM, Behcet Sarikaya wrote:

You don't seem to understand my points.

That is quite possible.  Your comment on the list was "I am
against any deployment work before we decide on a solution..."

I read that as an objection to having the deployment models work
item on the agenda.  Please do tell me what I am missing.

Regards,
Brian

Hi,

I am following the discussion and me too I do not quite understand
what is the complain.

I am happy to learn that a if a WG is to be formed then it would be
around a solution rather than just requirements or architecture.

That said, I would like to express a worry along similar lines.

In DMM, precedents and the keen NETEXT, there seems to be a
hard-rooted disconnect between the product developped - (P)Mobile
IP - and the deployments.  We know for a fact that 3GPP deployments
(2G/3G/4G) do not use (P)Mobile IP.  We also know that 3GPP specs
do mention Mobile IP. To such a point that I wonder whether 3GPP
has not the same disconnect as here.

On another hand, we do have indications of where (P)Mobile IP is
used - the trials, the projects, the kernel code, and not least the
slideware attracting real customers.

The worry: develop DMM protocol while continuing the disconnect.

Alex







___
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

___
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



___
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

_

Ce message et ses pieces jointes peuvent contenir des informations 
confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce 
message par erreur, veuillez le signaler
a l'expediteur et le d

Re: [DMM] regarding the re-chartering..

[Charlie Perkins]

Hello folks,

I'll go look for the link(s).  But in the meantime, as part of the ongoing
maintenance work, I'd be happy to see the following:

- Additional tunnel types (including GTP)
- Additional mobile node identifier types (including IMSI, MAC, ...)
- Additional security mechanisms

If there is a sliver of a chance that we could go down any one or more
of these paths, I will resurrect the old Internet drafts as well. If people
are interested, I will re-submit them for the November meeting.

There are two or three other things that Mobile IP needs also,
that take more words to express, but not necessarily directly
related to distributed mobility management.  Much of my development
had to do with trying to provide an easier / incremental path for the
deployment of Mobile IP by SDO partners in 3GPP, which would
necessitate inclusion in their standards, which (for instance) seems
to necessitate GTP as a tunneling protocol, etc.

Regards,
Charlie P.



On 9/7/2014 11:57 PM, MONGAZON-CAZAVET, BRUNO (BRUNO) wrote:

On 05/09/2014 19:10, Charlie Perkins wrote:


Hello folks,

I have made various presentations at IETF, some from many years
ago, proposing that Mobile IP enable use of GTP as a tunneling
option.  I still think that would be a good idea.  Should I re-re-revive
a draft stating this in more detail?


I would be interested to look at this draft.
Thanks.
Bruno




Regards,
Charlie P.


On 9/5/2014 1:48 AM, Alper Yegin wrote:

Alex,

DMM is not meant to be only about a bunch of MIP-based solutions.
There are various components in DMM solution space that'd also work 
with GTP-based architectures.

For example, identifying the mobility needs of flows.
Or, conveying the mobility characteristic of a prefix to the UE.

Alper




On Sep 4, 2014, at 1:14 PM, Alexandru Petrescu wrote:


Le 03/09/2014 20:53, Brian Haberman a écrit :

Behcet,

On 9/3/14 2:33 PM, Behcet Sarikaya wrote:

You don't seem to understand my points.
That is quite possible.  Your comment on the list was "I am 
against any

deployment work before we decide on a solution..."

I read that as an objection to having the deployment models work 
item on

the agenda.  Please do tell me what I am missing.

Regards,
Brian

Hi,

I am following the discussion and me too I do not quite understand 
what is the complain.


I am happy to learn that a if a WG is to be formed then it would be 
around a solution rather than just requirements or architecture.


That said, I would like to express a worry along similar lines.

In DMM, precedents and the keen NETEXT, there seems to be a 
hard-rooted disconnect between the product developped - (P)Mobile 
IP - and the deployments.  We know for a fact that 3GPP deployments 
(2G/3G/4G) do not use (P)Mobile IP.  We also know that 3GPP specs 
do mention Mobile IP. To such a point that I wonder whether 3GPP 
has not the same disconnect as here.


On another hand, we do have indications of where (P)Mobile IP is 
used - the trials, the projects, the kernel code, and not least the 
slideware attracting real customers.


The worry: develop DMM protocol while continuing the disconnect.

Alex








___
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

___
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




___
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] regarding the re-chartering..

[Charlie Perkins]

Hello folks,

I have made various presentations at IETF, some from many years
ago, proposing that Mobile IP enable use of GTP as a tunneling
option.  I still think that would be a good idea.  Should I re-re-revive
a draft stating this in more detail?

Regards,
Charlie P.


On 9/5/2014 1:48 AM, Alper Yegin wrote:

Alex,

DMM is not meant to be only about a bunch of MIP-based solutions.
There are various components in DMM solution space that'd also work with 
GTP-based architectures.
For example, identifying the mobility needs of flows.
Or, conveying the mobility characteristic of a prefix to the UE.

Alper




On Sep 4, 2014, at 1:14 PM, Alexandru Petrescu wrote:


Le 03/09/2014 20:53, Brian Haberman a écrit :

Behcet,

On 9/3/14 2:33 PM, Behcet Sarikaya wrote:

You don't seem to understand my points.

That is quite possible.  Your comment on the list was "I am against any
deployment work before we decide on a solution..."

I read that as an objection to having the deployment models work item on
the agenda.  Please do tell me what I am missing.

Regards,
Brian

Hi,

I am following the discussion and me too I do not quite understand what is the 
complain.

I am happy to learn that a if a WG is to be formed then it would be around a 
solution rather than just requirements or architecture.

That said, I would like to express a worry along similar lines.

In DMM, precedents and the keen NETEXT, there seems to be a hard-rooted 
disconnect between the product developped - (P)Mobile IP - and the deployments. 
 We know for a fact that 3GPP deployments (2G/3G/4G) do not use (P)Mobile IP.  
We also know that 3GPP specs do mention Mobile IP. To such a point that I 
wonder whether 3GPP has not the same disconnect as here.

On another hand, we do have indications of where (P)Mobile IP is used - the 
trials, the projects, the kernel code, and not least the slideware attracting 
real customers.

The worry: develop DMM protocol while continuing the disconnect.

Alex








___
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

___
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] WGLC #2 for draft-ietf-dmm-best-practices-gap-analysis-04

[Charlie Perkins]

Hello Jouni,

I communicated three issues:

- The gap does not explain the gaps between the requirements and
FMIP / [seamoby] documents / [hokey]
- The document does not explain the relevance of the SIPTO example
in fulfilling the requirements.  In fact, SIPTO has "limited mobility
support".
- The document uses terminology "LMs" and "LMc" that could be
improved.  Almost every existing IETF approach refers to some sort
of "binding management", and it would be better to stay aligned
with that.  This is especially true lately, since "location management"
is relevant to advertisements and even surveillance.

Regards,
Charlie P.


On 6/2/2014 9:25 PM, Jouni Korhonen wrote:

Folks,

The WGLC has ended for this I-D. There was one comment on the list:
http://www.ietf.org/mail-archive/web/dmm/current/msg01152.html

I also sent few editorial/typo correction comments offline to the 
authors while doing my review for the proto write-up.


We take the I-D passed the WGLC #2 but a new quick revision to
include the two comments is needed before we ship the I-D out of the WG.

- Jouni (as a DMM co-chair)


5/26/2014 6:39 AM, Jouni Korhonen kirjoitti:

Folks,

This email starts a one week WGLC #2 for
draft-ietf-dmm-best-practices-gap-analysis-04. Issue you comments to the
mailing list and place possible tickets to the issue tracker. There are
quite a few changed mainly to tackle Charlie's comments.

The WGLC ends 2ns June 2014 EOB (EEST). Silence is accounted as an
acceptance for the content.

- Jouni (as a DMM co-chair)


___
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