Re: [DMM] MNID Types

[Charles E. Perkins]

Hello folks,

Now we have two kinds of identifiers that could reasonably be
grouped as a type plus subtypes.  I could specify this by writing
another section of the new draft that lays out another subtype
field after the MNID subtype field from 4283.  I guess it would
be a "subsubtype" field if we are following the nomenclature for
the fields as shown in RFC 4283.

Or, alternatively, I could specify that for some types (e.g., DUID
and RFID), the first eight bits of the identifier is the a field that
we might call the "identifier subtype".  Maybe that is cleaner.

A third option would be to update RFC 4283, but that seems to
be a bit heavy-handed.

Comments?  Or other options?

Regards,
Charlie P.


On 9/25/2014 9:31 PM, Hakima Chaouchi wrote:

Hi,

For RFID we refer to the EPC standards.

"The /Electronic Product Code/ (EPC) is an identification scheme for 
universally identifying physical objects by using Radio Frequency 
Identification (RFID) tags.
The standardized EPC tag encoding consists of an EPC Identifier that 
uniquely identifies an individual object, and may also include a 
filter value if the filter is needed to enable effective and efficient 
reading of the EPC tags. The EPC Identifier is a meta-coding scheme 
designed to support the needs of various industries by accommodating 
existing coding schemes where possible and by defining new schemes 
where necessary."


"EPC supports several encoding systems or schemes including GID 
(Global Identifier), SGTIN (Serialized Global Trade Item Number), SSCC 
(Serial Shipping Container), GLN (Global Location Number), GRAI 
(Global Returnable Asset Identifier), DOD (Department of Defense) and 
GIAI (Global Individual Asset Identifier).


For each scheme except GID, there are two variations—a 64-bit scheme 
(for example, GLN-64) and a 96-bit scheme (GLN-96). GID has only a 
96-bit scheme.


Within each scheme, an EPC identifier can be represented in a binary 
form or other forms such as URI ..etc".


May be we need some subtyping.

Cheers,

Hakima



*De: *"Sri Gundavelli (sgundave)" 
*À: *"Charles E. Perkins" 
*Cc: *"Vijay Devarapalli" , dmm@ietf.org
*Envoyé: *Vendredi 26 Septembre 2014 03:36:01
*Objet: *Re: [DMM] MNID Types

Hi Charlie,

> Is the DoD-96 identifier for a special kind of RFID, or is it valid 
for all the RFID devices that would be of interest?


I do not know the answer for this question. I assumed DOD-96 is a 
mandated standard for RFID encoding, but looks like there are other 
formats like GID-96 ..etc. May be this may end up needing subtypes. We 
can defer this question to Hakima and learn some details on this, she 
seems to have written many books on RFID.



Regards
Sri



From: "Charles E. Perkins" <mailto:charl...@computer.org>>

Organization: Blue Skies
Date: Thursday, September 25, 2014 1:42 PM
To: Sri Gundavelli mailto:sgund...@cisco.com>>
Cc: "dmm@ietf.org <mailto:dmm@ietf.org>" <mailto:dmm@ietf.org>>, Vijay Devarapalli <mailto:dvi...@rocketmail.com>>

Subject: Re: [DMM] MNID Types


Hello Sri,

Is the DoD-96 identifier for a special kind of RFID, or is it
valid for all the RFID devices that would be of interest?

Regards,
Charlie P.


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

Hi Hakima,

That is a good idea. We should register a type for the Dod-96
identifier as well.


Regards
Sri


From: Hakima Chaouchi mailto:hakima.chaou...@telecom-sudparis.eu>>
Date: Sunday, September 21, 2014 8:11 AM
To: Sri Gundavelli mailto:sgund...@cisco.com>>
Cc: Charlie Perkins mailto:charles.perk...@earthlink.net>>, 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,

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)" mailto:sgund...@cisco.com>>
*À: *"Charlie Perkins" mailto:charles.perk...@earthlink.net>>, "Marco Liebsch"
mailto:marco.lieb...@neclab.eu>>,
dmm@ietf.org <mailto:dmm@ietf.org>, "Vijay Devarapalli"
mailto:dvi...@rocketmail.com>>
*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. B

Re: [DMM] MNID Types

[Charles E. Perkins]

Hello Fred,

I can include DUID-UUID as an identifier type, and cite RFC 4122. Is this
sufficient, or do I need to also do something related to DHCPv6 DUID?

I did not see any specific connection between this type of identifier and
the RFID discussion.  Is there something that relates the two types?

Regards,
Charlie P.



On 9/25/2014 2:00 PM, Templin, Fred L wrote:


Hi Charlie,

I am interested in node IDs that can be represented in a DHCPv6 DUID. 
There is


RFC6355 which encodes a node ID based on DUID-UUID (Universally Unique

IDentifier). AFAICT, the UUID is a 128-bit container formatted per RFC4122

specifications that includes a time portion and a node ID portion. Any 
chance


this would satisfy what you are looking for?

Thanks - Fred

*From:*dmm [mailto:dmm-boun...@ietf.org] *On Behalf Of *Charles E. Perkins
*Sent:* Thursday, September 25, 2014 1:43 PM
*To:* Sri Gundavelli (sgundave)
*Cc:* Vijay Devarapalli; dmm@ietf.org
*Subject:* Re: [DMM] MNID Types


Hello Sri,

Is the DoD-96 identifier for a special kind of RFID, or is it
valid for all the RFID devices that would be of interest?

Regards,
Charlie P.

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

Hi Hakima,

That is a good idea. We should register a type for the Dod-96
identifier as well.

Regards

Sri

*From: *Hakima Chaouchi mailto:hakima.chaou...@telecom-sudparis.eu>>
*Date: *Sunday, September 21, 2014 8:11 AM
*To: *Sri Gundavelli mailto:sgund...@cisco.com>>
*Cc: *Charlie Perkins mailto:charles.perk...@earthlink.net>>, 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,

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)" mailto:sgund...@cisco.com>>
*À: *"Charlie Perkins" mailto:charles.perk...@earthlink.net>>, "Marco Liebsch"
mailto:marco.lieb...@neclab.eu>>,
dmm@ietf.org <mailto:dmm@ietf.org>, "Vijay Devarapalli"
mailto:dvi...@rocketmail.com>>
*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)"  
<mailto:sgund...@cisco.com>  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

Re: [DMM] MNID Types

[Charles E. Perkins]

Hello Sri,

Is the DoD-96 identifier for a special kind of RFID, or is it
valid for all the RFID devices that would be of interest?

Regards,
Charlie P.


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

Hi Hakima,

That is a good idea. We should register a type for the Dod-96 
identifier as well.



Regards
Sri


From: Hakima Chaouchi >

Date: Sunday, September 21, 2014 8:11 AM
To: Sri Gundavelli mailto:sgund...@cisco.com>>
Cc: Charlie Perkins >, Marco Liebsch 
mailto:marco.lieb...@neclab.eu>>, 
"dmm@ietf.org " >, Vijay Devarapalli >

Subject: Re: [DMM] MNID Types

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" 
mailto:marco.lieb...@neclab.eu>>, 
dmm@ietf.org , "Vijay Devarapalli" 
mailto:dvi...@rocketmail.com>>

*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 >

Date: Thursday, September 11, 2014 2:46 PM
To: Sri Gundavelli mailto:sgund...@cisco.com>>, 
Marco Liebsch >, "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] r

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

[Charles E. Perkins]

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>" 
mailto:pierrick.se...@orange.com>>

Date: Wednesday, September 24, 2014 8:56 AM
To: "Charles E. Perkins" <mailto:charl...@computer.org>>, "dmm@ietf.org <mailto: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 <mailto: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: *

        

 <mailto:internet-dra...@ietf.org>

*To: *



Charles E. Perkins  
<mailto:charl...@computer.org>, Vijay Devarapalli 
 
<mailto:unknown-email-vijay-devarapa...@ietfa.amsl.com>, Charles 
E.Perkins  <mailto:charl...@computer.org>


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 htmlized version and diff are available at tools.ietf.org.
  
The IETF Secretariat
  
  


_

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 detruire ainsi que les pieces jointes. Les messages 
electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou 
falsifie. Merci.

This message and

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

[Charles E. Perkins]

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 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] regarding the re-chartering..

[Charles E. Perkins]

Hello folks,

I have asked this same question many times, in different words...

Namely, if we design a solution that fits the requirements, and bridges
the gaps as analyzed in the gap analysis document, have we succeeded?

Or, is there a requirement for the work to be adopted by 3GPP?

What if we design for IEEE 802 Wireless, which is currently carrying the
preponderance of the world's wireless data, and will almost assuredly
continue to carry a greater proportion?

Regards
Charlie P.



On 9/4/2014 3:14 AM, Alexandru Petrescu wrote:


Hi,



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




--
Regards,
Charlie P.

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

Re: [DMM] Teleconference

[Charles E. Perkins]

Hello folks,

Likewise here.

I am not available on Wednesday or Friday early morning
Pacific Time, or on Tuesday around lunchtime, or Monday
or Friday evening, or Thursday afternoon.  For most of the
week, except for the indicated times, I will be able to attend.

Regards,
Charlie P.


On 5/31/2014 3:05 AM, karag...@cs.utwente.nl wrote:


Hi Danny, Hi all,

Yes, I am getting the same indication and I cannot vote!

Best regards,

Georgios


*Van:* dmm [dmm-boun...@ietf.org] namens Moses, Danny 
[danny.mo...@intel.com]

*Verzonden:* vrijdag 30 mei 2014 19:41
*Aan:* Dapeng Liu; dmm
*Onderwerp:* Re: [DMM] Teleconference

Hi. For some reason I cannot vote. When entering Doodle I receive an 
indication that I have already voted even though I did not.


Am I the only one?

Thanks,

/Danny

*From:*dmm [mailto:dmm-boun...@ietf.org] *On Behalf Of *Dapeng Liu
*Sent:* Friday, May 30, 2014 07:40
*To:* dmm
*Subject:* [DMM] Teleconference

Hello,

The WG decide to have a teleconference next week. Please select your 
prefer time in doodle.


Doodle:

_https://doodle.com/d7fsc2gsdsgd2e52n438gimr/private?tmail=poll_invitecontact_participant_invitation&tlink=pollbtn_

Thanks,

--

Dapeng&Jouni

-
A member of the Intel Corporation group of companies

This e-mail and any attachments may contain confidential material for
the sole use of the intended recipient(s). Any review or distribution
by others is strictly prohibited. If you are not the intended
recipient, please contact the sender and delete all copies.



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



--
Regards,
Charlie P.

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

[DMM] [dmm] issue #46: rfcdiff output showing suggested editorial changes for draft-ietf-dmm-best-practices-gap-analysis-03.txt

[Charles E. Perkins]

Hello folks,

I made an editorial pass through 
draft-ietf-dmm-best-practices-gap-analysis-03
and used 'rfcdiff' to highlight the changes.  The 'rfcdiff' output is 
attached to
the ticket for issue #46.  It also includes an abbreviated list of the 
other issues

that I have already inserted onto the issue tracker.

I also uploaded the rfcdiff output to the IETF wiki page for [dmm].   
Here is the URL:


http://trac.tools.ietf.org/wg/dmm/trac/attachment/wiki/WikiStart/Diff%20%20draft-ietf-dmm-best-practices-gap-analysis-03.txt%20-%20draft-ietf-dmm-best-practices-gap-analysis-03cep-v2.txt.htm

When you see that web page, it probably looks like a raw .html file.  I 
don't

know how to fix that, but if you download the file and browse it, you should
see the rfcdiff output as it's supposed to look.

--
Regards,
Charlie P.

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

Re: [DMM] Next-Gen Mobility Protocols and Architectures Webex call #2

[Charles E. Perkins]

Hello Alper,

I guess it's hard to please everyone.

Last week's choices were all impossible for me.

This week's choices are all at 4:00am.

I hope we can get the presentation materials beforehand and make comments.

Regards,
Charlie P.


On 3/27/2014 2:57 PM, Alper Yegin wrote:

Folks,

The second call is for Pete to present 
http://tools.ietf.org/html/draft-mccann-dmm-flatarch-00.

There are three candidate dates from next week. Please use the following doodle 
to mark the dates that work for you.

http://doodle.com/um7cwnrk3ekid4pa

Doodle deadline is the end of next Monday (March 31).

Alper


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




--
Regards,
Charlie P.

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

Re: [DMM] WGLC #2 starts for draft-ietf-dmm-requirements-03

[Charles E. Perkins]

Hello Anthony,

I think the new text is worthwhile, but "increase" should
be "increases".

Regards,
Charlie P.


On 5/17/2013 2:07 PM, h chan wrote:

The original comment was on "resources" in the following problem statement:

PS3:  Low scalability of centralized tunnel management and mobility
  context maintenance

  Setting up tunnels through a central anchor and maintaining
  mobility context for each MN therein requires more resources in
  a centralized design, thus reducing scalability.  Distributing
  the tunnel maintenance function and the mobility context
  maintenance function among different network entities can
  increase scalability.

How about revising PS3 to the following and comparing resources:

PS3:  Low scalability of centralized tunnel management and mobility
  context maintenance

  Setting up tunnels through a central anchor and maintaining
  mobility context for each MN in a centralized design increase
  the processing at the anchor as the number of MNs increases.
  Distributing the tunnel maintenance function and the mobility
  context maintenance function among different network entities
  with proper signaling protocol design can increase scalability.

H Anthony Chan

-Original Message-
From: dmm-boun...@ietf.org [mailto:dmm-boun...@ietf.org] On Behalf Of KIM, 
BYOUNG-JO J (BYOUNG-JO)
Sent: Friday, May 17, 2013 9:24 AM
To: Peter McCann
Cc: dmm@ietf.org
Subject: Re: [DMM] WGLC #2 starts for draft-ietf-dmm-requirements-03

Very much agreed.

Also, distributed solutions can be concentrated as deployment needs dictate 
using layer 2 means, as is done often in many present networks.

can't do the opposite with centralized solutions without a whole lot of 
acrobatics.

"J" Kim
AT&T Labs - Research
http://sites.google.com/site/macsbug/

On May 17, 2013, at 9:04 AM, Peter McCann wrote:


We shouldn't require all the traffic to pay the price of
centralization just because some small subset of the flow need it.  LI
should be a very small proportion of the traffic, and those flows can
be directed to a collection point as needed.  If you really need
per-flow, per-application charging, you can send meta-information
about the flows to a charging collection box.  No need to send the flows 
themselves.

-Pete


Sri Gundavelli (sgundave) wrote:

Distributed solution: Take IP traffic directly from access router to
the Internet.




Counter argument.


It implies, LI, Charging, DPI Šetc on each of the distributed nodes.
Implies more "CAPEX and OPEX" ?


I'm not against distributed models and 6909 is the proof point. But,
IMO, it will hard to draw relation to cost models, based on traffic
exit points. You may need mobility hierarchy in the network for "n"
number of reasons and a centralized models for "m" number of reasons.
It more about deployment choice, dependent on many parameters.




Sri






On 4/29/13 5:29 AM, "Alper Yegin"  wrote:


Hi Charlie,

No, it should be less.

Distributed solution: Take IP traffic directly from access router to
the Internet.
Centralized solution: Take IP traffic from access router to a core
router to the Internet.

The latter suggests more CAPEX and OPEX.

Alper



On Apr 27, 2013, at 3:44 AM, Charles E. Perkins wrote:


Hello Alper,

I agree with your point, but it means that the total cost of the
distributed solution is even more expensive right?

Regards,
Charlie P.

On 4/26/2013 12:56 AM, Alper Yegin wrote:

Hi Charlie,


- It is claimed that a centralized architecture requires more
resources than a distributed architecture.  This is usually
false.  For instance, if a centralized node requires 100 units,
and 100 distributed nodes each require 1.03 units, the
distributed architecture requires 3 more units overall.

This would be true for tasks that can be performed either on the
distributed node or on the central node.
But the essential task for DMM systems, IP forwarding, is not of
that nature.
In centralized architecture, that task needs to be performed
*both* at the edge node and also at the central node (and in fact
even in
between) before the packets hit the Internet/mobile device.



Even so, the additional expense of the distributed architecture
would often be a bargain for reasons of redundancy, resiliency,

etc.

Alper





___
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/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/mailma

Re: [DMM] WGLC #2 starts for draft-ietf-dmm-requirements-03

[Charles E. Perkins]

Hello Alper,

I agree with your point, but it means that the total cost of
the distributed solution is even more expensive right?

Regards,
Charlie P.

On 4/26/2013 12:56 AM, Alper Yegin wrote:

Hi Charlie,


- It is claimed that a centralized architecture requires more resources
  than a distributed architecture.  This is usually false.  For instance,
  if a centralized node requires 100 units, and 100 distributed nodes each
  require 1.03 units, the distributed architecture requires 3 more units
  overall.

This would be true for tasks that can be performed either on the distributed 
node or on the central node.
But the essential task for DMM systems, IP forwarding, is not of that nature.
In centralized architecture, that task needs to be performed *both* at the edge 
node and also at the central node (and in fact even in between) before the 
packets hit the Internet/mobile device.



Even so, the additional expense of the distributed architecture
  would often be a bargain for reasons of redundancy, resiliency, etc.


Alper





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




--
Regards,
Charlie P.

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

[DMM] Editorial suggestions for draft-ietf-dmm-requirements-03

[Charles E. Perkins]

Hello folks,

Here are some editorial suggestions for the document.

Check for missing articles.  For instance:
"Gateway selection mechanism"  -->  "A gateway selection mechanism"

"is also taking the"  -->  "also takes"

Delete "However" before "assigning".

Delete "Issues such as"

Delete "When demand exceeds capacity,"  or else explain why
the benefits are unavailable otherwise.

"In particular, there is an increase in direct communications among
   peers in the same geographical area."
  --> there has always been such locality... in fact maybe less
now than previously.  Otherwise, please provide a citation.

Delete "While deploying"

"today's mobile networks, service providers face"  -->
   "Today's mobile networks present service providers with"

Delete "more often than not,"

Delete "Therefore it is not uncommon to observe that"

"ever-increasing" -->  "unnecessary"

"provided"  -->  "managed"

"non-optimal"  -->  "unnecessary"

Delete "Given this motivational background in this section,"

"address these problems":  at this point in the document, the
problems have not been identified.  As suggested earlier,
there should be a section devoted to listing the problems,
and then a cross reference to that section could go here.

"changing IP address"  -->  "locator IP address"

Insert "The" before "Gateway GPRS Support Node"

"respectively, act"  -->  "all act"

"SAE"  -->  "EPC"

"closeby"  -->  "nearby"

Center figure 2.  (and might as well center figure 1 too)

"future flat IP-based"  -->  "flat IP-based"
(unwise to predict the future)

"states the requirements as follows" -->
   "identifies the 
following requirements"


"Distributed deployment"  -->  "Distributed processing"
... also in "REQ1"

"of IP sessions"  -->  "of some flows"

"an optimal manner"  -->  "to avoid known bottlenecks"

"This requirement addresses problems PS1, PS2, PS3, and PS4 in the
   following."
...  the following ?what?

"each MN therein"  the MNs are not "in" the tunnel, and they are
not "in" the mobility 
anchor.


"Centralized anchoring"  -->  "Centralized anchoring designs"

"Distributing
 the tunnel maintenance function and the mobility context
 maintenance function among different network entities can
 increase scalability."
-->  only when the signaling protocol is properly designed.

"is to be inline"  -->  "conforms"

"may need to interoperate with a network or mobile hosts/
  routers that do not support DMM protocols."
... this is technically infeasible.
Suggested replacement:
"may need to co-exist with a network or mobile hosts/
  routers that do not support DMM protocols."

Delete "The motivations of this requirement are"

--
Regards,
Charlie P.

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

Re: [DMM] WGLC #2 starts for draft-ietf-dmm-requirements-03

[Charles E. Perkins]

Hello Seil,

You suggest that if a feature is not listed as a requirement, it cannot be
considered during the evaluation of solution proposals.  This is not true.
Given the choice of two proposals, the one that meets the requirements
and offers the best other features will invariably be chosen.

The real danger is in disqualifying good proposals because they fail to
offer some feature that should not have been made into a requirement.
There is no harm in listing desirable features (like multicast) that would
enhance the value of a solution that meets the requirements.

Regards,
Charlie P.



On 4/26/2013 6:18 AM, Seil Jeon wrote:

Hi Charles,

Actually, in realizing DMM-based mobility management, as you know, they may
exist various ways or more requirements for DMM protocol deign tackling the
issues raised from CMM. Given the requirements defined in the document is
confining, in their ways, explicitly or implicitly the protocol design for
further steps.
It means that proposed solutions should satisfy or consider the
requirements, or they will not be DMM solution in DMM WG at least.

If you see the mail posted by Sergio a few days ago, the multicast part
title was changed with 'Multicast Considerations' for right meaning. With
the meaning, I think it would go together with the other requirements. Have
a look, please.


Regards,
Seil


-Original Message-
From: dmm-boun...@ietf.org [mailto:dmm-boun...@ietf.org] On Behalf Of
Charles E. Perkins
Sent: Thursday, April 25, 2013 1:24 AM
To: dmm@ietf.org
Subject: Re: [DMM] WGLC #2 starts for draft-ietf-dmm-requirements-03

Hello again folks,

I can't type in all the editorial suggestions right now, but at least I
wanted to provide some overall comments that cause the document to seem
quite inaccurate in many of its claims.
Here are my general comments.

- The requirements need to be distinguished from the desirable features.
For instance, section 4.7 describes a desirable feature, not a
requirement.
Moreover, the desirable feature may be unattainable.  This is important,
because if feature is *required*, a solution not providing the *required*
feature "must" be considered incomplete and rejected.


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




--
Regards,
Charlie P.

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

Re: [DMM] WGLC #2 starts for draft-ietf-dmm-requirements-03

[Charles E. Perkins]

Hello again folks,

I can't type in all the editorial suggestions right now, but at least
I wanted to provide some overall comments that cause the
document to seem quite inaccurate in many of its claims.
Here are my general comments.

- The requirements need to be distinguished from the desirable features.
  For instance, section 4.7 describes a desirable feature, not a 
requirement.

  Moreover, the desirable feature may be unattainable.  This is important,
  because if feature is *required*, a solution not providing the *required*
  feature "must" be considered incomplete and rejected.

- The problem statement clauses should be located in an initial section.
  Each problem statement should have a motivation.

- There is no problem statement supporting sections 4.4 or 4.6

- There is no motivation for section 4.4

- There is nothing specific to DMM in sections 4.4 or 4.6

- Section 5 should cross-reference section 4.6, and they should both
  be rewritten to eliminate redundant extra verbiage of which there is
  too much.

- PS7 claims that deployment (of "something":  existing IETF solutions?)
  is too complicated.  Compared to what???  3GPP solutions?? Dozens
  of incompatible clunky slow portal authentication design botches?
  This point strikes me as basically wrong, but it can be rescued if a
  target level of deployment complexity is described.

- REQ3 claims that we should target IPv6 because of tools available for IPv6
  that are not available for IPv4.  Please identify at least one.

- Section 1 claims that user traffic patterns have shifted to become
  more localized.  This is probably false, but I can imagine several
  ways to change it so that it becomes true.  It is important for this
  purpose to clarify what is intended by "peer communications".

- What is an "IP session"?  Wasn't IP supposed to be connectionless?
  I strongly suggest not trying to define such a thing.  Perhaps it
  was intended to indicate a "flow" instead.

- It is claimed that a centralized architecture requires more resources
  than a distributed architecture.  This is usually false.  For instance,
  if a centralized node requires 100 units, and 100 distributed nodes each
  require 1.03 units, the distributed architecture requires 3 more units
  overall.  Even so, the additional expense of the distributed architecture
  would often be a bargain for reasons of redundancy, resiliency, etc.

I will do the editorial suggestions tomorrow.  Also I can volunteer to
rewrite various parts if extra effort is needed.

Regards,
Charlie P.


On 4/24/2013 2:14 PM, Charles E. Perkins wrote:

Hello folks,

I have many editorial comments which I will submit later today.

However, I think the draft has a major organizational problem. Namely,
the "problem statements", instead of being properly collected together
in an initial section, are sprinkled in along with various statements of
requirements.

I remember there was previously a problem statement draft that
enumerated the PSs in the current requirements draft.  I think it is
O.K. (perhaps not optimal, but O.K.) for the problem statements to
be in the requirements draft, but not as currently situated.

This, along with the various other editorial clarifications that are
needed, lead me to believe that the draft is not yet ready, but I do
not think that there are major problems, and that the next draft
probably could be ready for advancement.

Regards,
Charlie P.
___
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm




--
Regards,
Charlie P.

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

Re: [DMM] WGLC #2 starts for draft-ietf-dmm-requirements-03

[Charles E. Perkins]

Hello folks,

I have many editorial comments which I will submit later today.

However, I think the draft has a major organizational problem. Namely,
the "problem statements", instead of being properly collected together
in an initial section, are sprinkled in along with various statements of
requirements.

I remember there was previously a problem statement draft that
enumerated the PSs in the current requirements draft.  I think it is
O.K. (perhaps not optimal, but O.K.) for the problem statements to
be in the requirements draft, but not as currently situated.

This, along with the various other editorial clarifications that are
needed, lead me to believe that the draft is not yet ready, but I do
not think that there are major problems, and that the next draft
probably could be ready for advancement.

Regards,
Charlie P.
___
dmm mailing list
dmm@ietf.org
https://www.ietf.org/mailman/listinfo/dmm

Re: [DMM] Comments on DMM Gap Analysis.

[Charles E. Perkins]

Hello Behcet,

I'm very curious:

On 9/26/2012 1:08 PM, Behcet Sarikaya wrote:

With the cloud, two mobility entities may now become IPv6 neighbors in 
the cloud. Trying to define signaling between such entities maybe no 
longer a big issue. With cloud, DMM's premise somewhat disappears. We 
need to find a new premise.


How is it that the mobility entities are "more neighborly" than they 
would be

in physical IPv6 networks?

How would there be information about whether the mobility entities
are in the same cloud or different clouds?

I do think that clouds are interesting, but it's not immediately obvious
to me how they change the fundamental nature of the DMM problem.

--
Regards,
Charlie P.

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

Re: [DMM] I-D Action: draft-ietf-dmm-requirements-00.txt

[Charles E. Perkins]

Hello folks,

I'm not sure that SDN considerations are a requirement for DMM,
but I am sure that we should at least allow the discussion.

One possibility would be that SDNC would collect information
from DMM, and influence the distribution of mobility anchors.
That's got to be relevant.

Regards,
Charlie P.


On 7/16/2012 7:50 AM, jouni korhonen wrote:

On Jul 13, 2012, at 8:11 AM, Keshav.A.K. wrote:


Hi,

I have one basic question about thinking process going on this these days
...
There is a global Trend to 'Centralized the Controlling Function' by 'SDNC
concept' which can be used to program network/Nodes ...
Conversely there is thinking process going on to distribute the existing
'Centralized Functionality'.

I there is strong requirement to converge these thinking process.

While SDNs, SNDPs etc are interesting and partially may overlap conceptually
I think there is no requirement or even a need trying to mate these two
together in a DMM solution requirement level. SDN technologies can well be
applied in the implementation space, though.

- Jouni




keshava



-Original Message-
From: dmm-boun...@ietf.org [mailto:dmm-boun...@ietf.org] On Behalf Of
internet-dra...@ietf.org
Sent: Monday, July 09, 2012 6:47 PM
To: i-d-annou...@ietf.org
Cc: dmm@ietf.org
Subject: [DMM] I-D Action: draft-ietf-dmm-requirements-00.txt


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   : Requirements of distributed mobility management
Author(s)   : H Anthony Chan
Filename: draft-ietf-dmm-requirements-00.txt
Pages   : 16
Date: 2012-07-06

Abstract:
   The traditional hierarchical structure of cellular networks has led
   to deployment models which are heavily centralized.  Mobility
   management with centralized mobility anchoring in existing
   hierarchical mobile networks is quite prone to suboptimal routing and
   issues related to scalability.  Centralized functions present a
   single point of failure, and inevitably introduce longer delays and
   higher signaling loads for network operations related to mobility
   management.  This document defines the requirements for distributed
   mobility management for IPv6 deployment.  The objectives are to match
   the mobility deployment with the current trend in network evolution,
   to improve scalability, to avoid single point of failure, to enable
   transparency to upper layers only when needed, etc.  The distributed
   mobility management also needs to be compatible with existing network
   deployments and end hosts, and be secured.


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

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-dmm-requirements-00


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

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




--
Regards,
Charlie P.

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

Re: [DMM] draft requirement discussions

[Charles E. Perkins]

Hello Pete,

Yes, I am fine with that revision and the new proposed text.

I was more worried about the seeming suggestion that the DMM
requirement was to interwork with any arbitrary security
mechanism. But, as I mentioned, I think we are pretty close.

Regards,
Charlie P.


On 6/7/2012 1:53 PM, Peter McCann wrote:
> I thought the new text from Anthony was an attempt to answer your
> comment, Charles.  For instance, he removed the text that said,
> "should not be considered the default."  Are you ok with his new
> proposed text?  If not, can you propose text that you would like?
>
> -Pete
>
> Charles E. Perkins wrote:
>> Hello folks,
>>
>> It seems to me that we may be perhaps arriving at a good point for a 
>> new draft.
>> However, there are still some points of discussion that are perhaps 
>> worthy to be resolved (for example, in my email earlier this week).
>>
>> Maybe we should fire up the issue tracker...?
>>
>> Regards,
>> Charlie P.
>>
>>
>> On 6/7/2012 12:04 PM, Behcet Sarikaya wrote:
>>
>>  Hi Jouni,
>>
>>  What are the plans on DMM requirements? I see lots of mails and never 
>> ending discussions.
>>
>>  Isn't it the time to get the draft out, thank Anthony for his hard 
>> work and move on?
>>
>>  Regards,
>>
>>  Behcet
>>
>>
>>  On Wed, Jun 6, 2012 at 11:32 AM, h chan 
>> wrote:
>>
>>
>>  Yes, the second and third sentences are not additional 
>> requirements, 
>> but rather explanations of the requirement in the first sentence. Does 
>> the rewrite sound better now:
>>
>>
>>
>>  REQ-2: Transparency to Upper Layers
>>
>>  The DMM solutions SHALL provide transparency above the IP layer 
>> when 
>> needed. Such transparency is needed, when the mobile hosts or entire 
>> mobile networks change their point of attachment to the Internet, for 
>> the application flows that cannot cope with a change of IP address.
>> Otherwise the support to maintain a stable home IP address or prefix 
>> during handover may be declined.
>>
>>
>>
>>  H Anthony Chan
>>
>>
>>
>>  From: luo@zte.com.cn [mailto:luo@zte.com.cn]
>>  Sent: Wednesday, June 06, 2012 12:56 AM
>>  To: h chan
>>  Cc: dmm@ietf.org; dmm-boun...@ietf.org; jouni korhonen; Peter 
>> McCann
>>  Subject: 答复: Re: [DMM] draft requirement REQ-2:
>> Transparency to Upper Layers
>>
>>
>>
>>
>>  Hi Anthony:
>>
>>  The last part of the sentence (i.e. but the need to maintain a 
>> stable home IP address or prefix SHOULD NOT be taken as
>> default.) seems a littel strange to me.  REQ-2 just describes under 
>> what circumstances the transparency is needed (i.e. when the mobile 
>> hosts or entire mobile networks change their point of attachment to 
>> the Internet, for the application flows that cannot cope with a change 
>> of IP address), that means automatically, otherwise the transparency 
>> is not needed. So why bother to write the last part of the sentence？
>>
>>  Besides, when mobile node attaches to its home network, it will 
>> obviously get a home IP address/prefix from its home network. The IP 
>> address/prefix can be considered as stable IP, as long as the mobile 
>> does not change its point of attachment. The last part of the sentence 
>> will just exclude this scenario.
>>
>>  If I make any mistake, please correct me.
>>
>>  Thanks
>>  Luowen
>>
>>
>>
>>
>>
>> h chan 
>> 发 件人:  dmm-boun...@ietf.org
>>
>> 2012/06/06 01:12
>>
>> 收件人
>>
>> "dmm@ietf.org" , Peter McCann , 
>> jouni korhonen 
>>
>> 抄送
>>
>>
>>
>> 主题
>>
>> Re: [DMM] draft requirement REQ-2: Transparency to Upper Layers
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>  Revise as follows:
>>
>>  REQ-2: Transparency to Upper Layers
>>  The DMM solutions SHALL provide transparency above the IP layer 
>> when 
>> needed. Such transparency is needed, when the mobile hosts or entire 
>> mobile networks change their point of attachment to the Internet, for 
>> the application flows that cannot cope with a change of IP address, 
>> but 

Re: [DMM] draft requirement discussions

[Charles E. Perkins]

Hello folks,

It seems to me that we may be perhaps arriving at a good point for a new 
draft.
However, there are still some points of discussion that are perhaps 
worthy to

be resolved (for example, in my email earlier this week).

Maybe we should fire up the issue tracker...?

Regards,
Charlie P.


On 6/7/2012 12:04 PM, Behcet Sarikaya wrote:

Hi Jouni,

What are the plans on DMM requirements? I see lots of mails and never 
ending discussions.


Isn't it the time to get the draft out, thank Anthony for his hard 
work and move on?


Regards,

Behcet

On Wed, Jun 6, 2012 at 11:32 AM, h chan > wrote:


Yes, the second and third sentences are not additional
requirements, but rather explanations of the requirement in the
first sentence. Does the rewrite sound better now:

REQ-2: Transparency to Upper Layers
The DMM solutions SHALL provide transparency above the IP layer
when needed. Such transparency is needed, when the mobile hosts or
entire mobile networks change their point of attachment to the
Internet, for the application flows that cannot cope with a change
of IP address. Otherwise the support to maintain a stable home IP
address or prefix during handover may be declined.

H Anthony Chan

*From:*luo@zte.com.cn 
[mailto:luo@zte.com.cn ]
*Sent:* Wednesday, June 06, 2012 12:56 AM
*To:* h chan
*Cc:* dmm@ietf.org ; dmm-boun...@ietf.org
; jouni korhonen; Peter McCann
*Subject:* ??: Re: [DMM] draft requirement REQ-2: Transparency to
Upper Layers


Hi Anthony:

The last part of the sentence (i.e. /but the need to maintain a
stable home IP address or prefix SHOULD NOT be taken as default/.)
seems a littel strange to me.  REQ-2 just describes under what
circumstances the transparency is needed (i.e. /when the mobile
hosts or entire mobile networks change their point of attachment
to the Internet, for the application flows that cannot cope with a
change of IP address/), that means automatically, otherwise the
transparency is not needed. So why bother to write the last part
of thesentence?

Besides, when mobile node attaches to its home network, it will
obviously get a home IP address/prefix from its home network. The
IP address/prefix can be considered as stable IP, as long as the
mobile does not change its point of attachment. The last part of
the sentence will just exclude this scenario.

If I make any mistake, please correct me.

Thanks
Luowen



*h chan mailto:h.anthony.c...@huawei.com>>*
? ??: dmm-boun...@ietf.org 

2012/06/06 01:12



???



"dmm@ietf.org " mailto:dmm@ietf.org>>, Peter McCann mailto:peter.mcc...@huawei.com>>, jouni korhonen
mailto:jouni.nos...@gmail.com>>

??



??



Re: [DMM] draft requirement REQ-2: Transparency to Upper Layers







Revise as follows:

REQ-2: Transparency to Upper Layers
The DMM solutions SHALL provide transparency above the IP layer
when needed. Such transparency is needed, when the mobile hosts or
entire mobile networks change their point of attachment to the
Internet, for the application flows that cannot cope with a change
of IP address, but the need to maintain a stable home IP address
or prefix SHOULD NOT be taken as default.
REQ-2M (Motivation for REQ-2)
The goal of this requirement is to enable more efficient use of
network resources and more efficient routing by not maintaining a
stable IP home IP address when there is no such need.

H Anthony Chan


-Original Message-
From: dmm-boun...@ietf.org 
[mailto:dmm-boun...@ietf.org ] On
Behalf Of h chan
Sent: Wednesday, May 23, 2012 7:51 PM
To: Peter McCann; jouni korhonen
Cc: dmm@ietf.org 
Subject: Re: [DMM] draft requirement REQ-2: Transparency to Upper
Layers

An attempt to clean up the text so far:

REQ-2: Transparency to Upper Layers
The DMM solutions SHALL provide transparency above the IP layer
when needed. Such transparency is needed, when the mobile hosts or
entire mobile networks change their point of attachment to the
Internet, for the application flows that cannot cope with a change
of IP address, but SHOULD NOT be taken as the default behavior.

REQ-2M (Motivation for REQ-2)
The goal of this requirement is to enable more efficient use of
network resources and more efficient routing when mobility support
is implemented by not invoking it for the application flows and
nodes that do not need it.

RELEVANT problem:
PS5: Wasting resources to support mobile nodes not nee

Re: [DMM] draft requirement REQ-4: compatibility

[Charles E. Perkins]

Hello folks,

On 6/5/2012 10:26 AM, h chan wrote:

Replacing REQ-4 with the following:

REQ-4: compatibility
The DMM solution MUST NOT break when being deployed between trusted 
administrative domains and SHOULD allow inter-working with the security 
measures deployed between these domains. Existing network deployment and end 
hosts also SHOULD NOT break.


I understand the intent, but specifying that something "SHOULD NOT break"
seems almost like berating the children.

How about:

"The DMM solution is required to work between trusted administrative domains
  and SHOULD allow inter-working with the security measures deployed 
between

  these domains. Furthermore, the DMM solution must preserve backwards
  compatibility with existing network deployment and end hosts."

I have two more issues:

- You cannot guarantee inter-working with completely arbitrary security 
measures.
- I am confident that the DMM solution will require security.  Thus, the 
"SHOULD"

  in the above text is somehow incorrect.

I'm not sure exactly how best to resolve these latter two issues, but 
before I
try to make a resolution, I thought it would be good to raise the issue 
on this

list for possible further discussion.

--
Regards,
Charlie P.

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

Re: [DMM] draft requirement REQ-2: Transparency to Upper Layers

[Charles E. Perkins]

On 6/5/2012 10:12 AM, h chan wrote:

Revise as follows:

REQ-2: Transparency to Upper Layers
The DMM solutions SHALL provide transparency above the IP layer when needed. 
Such transparency is needed, when the mobile hosts or entire mobile networks 
change their point of attachment to the Internet, for the application flows 
that cannot cope with a change of IP address, but the need to maintain a stable 
home IP address or prefix SHOULD NOT be taken as default.
REQ-2M (Motivation for REQ-2)
The goal of this requirement is to enable more efficient use of network 
resources and more efficient routing by not maintaining a stable IP home IP 
address when there is no such need.

H Anthony Chan


I think it should be possible for the user of a device to set which behavior
is to be considered the default behavior for all applications on that 
device.


This would leave open the possibility that, unless the user specifies 
otherwise,

the device would be configured to have "unstable" addressing as default.

--
Regards,
Charlie P.

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