Sri Gundavelli (sgundave | 21 Sep 18:59 2014
Picon

Re: MNID Types

Hi Hakima,

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


Regards
Sri


From: Hakima Chaouchi <hakima.chaouchi <at> telecom-sudparis.eu>
Date: Sunday, September 21, 2014 8:11 AM
To: Sri Gundavelli <sgundave <at> cisco.com>
Cc: Charlie Perkins <charles.perkins <at> earthlink.net>, Marco Liebsch <Marco.Liebsch <at> neclab.eu>, "dmm <at> ietf.org" <dmm <at> ietf.org>, Vijay Devarapalli <dvijay <at> 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)" <sgundave <at> cisco.com>
À: "Charlie Perkins" <charles.perkins <at> earthlink.net>, "Marco Liebsch" <Marco.Liebsch <at> neclab.eu>, dmm <at> ietf.org, "Vijay Devarapalli" <dvijay <at> 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 <charles.perkins <at> earthlink.net>
Date: Thursday, September 11, 2014 2:46 PM
To: Sri Gundavelli <sgundave <at> cisco.com>, Marco Liebsch <Marco.Liebsch <at> neclab.eu>, "dmm <at> ietf.org" <dmm <at> ietf.org>, Vijay Devarapalli <dvijay <at> 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:
<Changing the subject line to reflect the MNId discussion> 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)" <sgundave <at> 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 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" <Marco.Liebsch <at> neclab.eu> 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:sgundave <at> cisco.com] Sent: Donnerstag, 11. September 2014 00:42 To: Charlie Perkins; Marco Liebsch; dmm <at> 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" <charles.perkins <at> earthlink.net> 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 (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 <at> REALM), its based on the IMSI. Ex: "<IMSI> <at> epc.mnc<MNC>.mcc<MCC>.3gppnetwork.org² We also have MAC48 <at> 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" <Marco.Liebsch <at> neclab.eu> 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-bounces <at> ietf.org] On Behalf Of Sri Gundavelli (sgundave) Sent: Dienstag, 9. September 2014 23:30 To: Sri Gundavelli (sgundave); Charlie Perkins; dmm <at> 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)" <sgundave <at> cisco.com> 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" <charles.perkins <at> earthlink.net> 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 <at> ietf.orghttps://www.ietf.org/mailman/listinfo/dmm
_______________________________________________ dmm mailing list dmm <at> ietf.orghttps://www.ietf.org/mailman/listinfo/dmm
_______________________________________________ dmm mailing list dmm <at> ietf.orghttps://www.ietf.org/mailman/listinfo/dmm
_______________________________________________ dmm mailing list dmm <at> ietf.orghttps://www.ietf.org/mailman/listinfo/dmm


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



--
---------------------------------
Hakima Chaouchi
Professor
Telecom Sud Paris
Institut Mines Telecom
9 rue Charles Fourier
91011 Evry
0160764443

_______________________________________________
dmm mailing list
dmm@...
https://www.ietf.org/mailman/listinfo/dmm
Alper Yegin | 19 Sep 17:53 2014

Coordination of mobility solutions

As promised, let me enumerate the "protocol" worked involved for solutions aimed at "discovery,
selection, and coordinated execution of mobility protocols at multiple layers". 

- Discovering network's mobility capabilities:

Whether it supports PMIP, LISP,  etc.
Possible approach is to define new DHCP options to deliver this "network info" to the terminal.

- Discovering corresponding node's mobility capabilities:

Whether it supports MPTCP, MIP route optimization, etc.
Possible approach is to use DNS-based discovery.

Discovering the MN's own mobility capabilities does not involve any protocol work. It may be based on
platform-specific methods, API, application profiling, etc.

How the terminal selects the mobility protocol(s) to apply to a given flow, and how it coordinates
execution of them are materials for an "informational" document that'd also refer to the aforementioned
discovery elements.

Like Danny was suggesting, we can tackle this in the working team that deals with the source address
selection, as there's an interaction  between the two. Whether a flow needs a fixed or sustained or nomadic
IP address is influenced by whether the application traffic would need IP-layer mobility or not.

Alper
Sri Gundavelli (sgundave | 18 Sep 22:03 2014
Picon

Signaling Message Fragmentation

[Discussion under the maintenance scope] 

With the standardization of all the new mobility options (ANI, QoS, IFOM, MNP..etc)   and specially with the NAI/Domain type fields in some of those options, we are almost close to hitting the PBU/BU fragmentation limit. 

Any thoughts on how to deal with this ? How is it solved in other message based protocols ? I've seen some work on IPSecme WG on IKEv2 message fragmentation for the same issue. 

Should we do some thing here ? Or, if any one has invested time on this and has a proposal ? Comments ?



Regards
Sri
_______________________________________________
dmm mailing list
dmm@...
https://www.ietf.org/mailman/listinfo/dmm
IESG Secretary | 18 Sep 19:15 2014
Picon

DMM WG Virtual Interim Meeting, October 7, 2014

The DMM WG will hold its third interim conference calls during October:
7th October, 5PM Helsinki time (EEST) / 1400 UTC.

The conference call lasts max 2 hours. The detailed agenda will be
available later but it is around progressing the new work we are
pursuing.

--------------------------------------------
Webex details
--------------------------------------------

Join WebEx meeting
https://ietf.webex.com/ietf/j.php?MTID=mf5c5e188b03e86378ddf2d9a19a160d4

Meeting number: 317 354 563
Meeting password: dmm1911

Join by phone
1-877-668-4493 Call-in toll free number (US/Canada)
1-650-479-3208 Call-in toll number (US/Canada)
Access code: 317 354 563
Toll-free calling restrictions
http://www.webex.com/pdf/tollfree_restrictions.pdf

Can't join the meeting? Contact support.
https://ietf.webex.com/ietf/mc

IMPORTANT NOTICE: Please note that this WebEx service allows audio and
other information sent during the session to be recorded, which may be
discoverable in a legal matter. By joining this session, you
automatically consent to such recordings. If you do not consent to being
recorded, discuss your concerns with the host or do not join the session
Jouni Korhonen | 17 Sep 17:29 2014
Picon

DMM interim conference call #3

The DMM WG will hold its third interim conference calls during October:
	7th October, 5PM (Helsinki time, EEST)

The conference call lasts max 2 hours. The detailed agenda will be
available later but it is around progressing the new work we are
pursuing.

--------------------------------------------
Webex details
--------------------------------------------

Join WebEx meeting
https://ietf.webex.com/ietf/j.php?MTID=mf5c5e188b03e86378ddf2d9a19a160d4

Meeting number: 	317 354 563
Meeting password: 	dmm1911

Join by phone
1-877-668-4493 Call-in toll free number (US/Canada)
1-650-479-3208 Call-in toll number (US/Canada)
Access code: 317 354 563
Toll-free calling restrictions
http://www.webex.com/pdf/tollfree_restrictions.pdf

Can't join the meeting? Contact support.
https://ietf.webex.com/ietf/mc

IMPORTANT NOTICE: Please note that this WebEx service allows audio and 
other information sent during the session to be recorded, which may be 
discoverable in a legal matter. By joining this session, you 
automatically consent to such recordings. If you do not consent to being 
recorded, discuss your concerns with the host or do not join the session
Attachment (WebEx_Meeting.ics): text/calendar, 4136 bytes
_______________________________________________
dmm mailing list
dmm@...
https://www.ietf.org/mailman/listinfo/dmm
Jouni Korhonen | 17 Sep 01:44 2014
Picon

DMM Interim call #3

Folks,

The winner for the next interim call is:
	Tuesday, October 7, 2014 5:00 PM (Helsinki time)

- JOuni & Dapeng
Max | 15 Sep 17:18 2014
Picon

DMM interim 2

Folks,

Bellow is the webex information for interim 2.

-------------------------------------------------------

Meeting information

-------------------------------------------------------

Topic: DMM Interim

Date: Tuesday 16 September 2014

Time: 8:00, Northern Europe Summer Time (Helsinki, GMT+03:00) Meeting Number: 646 119 560 Meeting Password: dmm1911


-------------------------------------------------------

To start or join the online meeting

-------------------------------------------------------

Go to

https://ietf.webex.com/ietf/j.php?MTID=mcde205ac1a64e90782a666e44e312d6a


-------------------------------------------------------

Audio conference information

-------------------------------------------------------

Call-in toll number (US/Canada): 1-650-479-3208


Access code:646 119 560


-------------------------------------------------------

For assistance

-------------------------------------------------------

1. Go to https://ietf.webex.com/ietf/mc

2. On the left navigation bar, click "Support".

To add this meeting to your calendar program (for example Microsoft Outlook), click this link:

https://ietf.webex.com/ietf/j.php?MTID=mb0a21914ed70392b9917c7ce3352d954


To check whether you have the appropriate players installed for UCF (Universal Communications Format) rich media files, go to https://ietf.webex.com/ietf/systemdiagnosis.php.


http://www.webex.com


CCM:+16504793208x646119560#


IMPORTANT NOTICE: This WebEx service includes a feature that allows audio and any documents and other materials exchanged or viewed during the session to be recorded. You should inform all meeting attendees prior to recording if you intend to record the meeting. Please note that any such recordings may be subject to discovery in the event of litigation.



-- 
Dapeng Liu&Jouni
_______________________________________________
dmm mailing list
dmm@...
https://www.ietf.org/mailman/listinfo/dmm
Jouni Korhonen | 13 Sep 23:44 2014
Picon

IETF#91 meeting getting closer


November is soon here. We are also supposed to have two interims before 
the IETF#91 meeting. For the face-to-face in November the current plan 
is to ask for one 2.5h meeting slot. That should be enough.

- Jouni & Dapeng
Jouni Korhonen (via Doodle | 13 Sep 14:39 2014

DMM interim 3

Jouni Korhonen invites you to participate in the Doodle poll "DMM interim 3."
Hi there,
 
Jouni Korhonen (jounikor-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org) invites you to participate in the Doodle poll "DMM interim 3".
Jouni Korhonen says:
DMM Interim call #3. Give your preferences by Tuesday 30th Sep.
Participate now
What is Doodle? Doodle is a web service that helps Jouni Korhonen to find a suitable date for meeting with a group of people. Learn more about how Doodle works.
You have received this e-mail because "Jouni Korhonen" has invited you to participate in the Doodle poll "DMM interim 3."
Doodle AG, Werdstrasse 21, 8021 Zürich

_______________________________________________
dmm mailing list
dmm@...
https://www.ietf.org/mailman/listinfo/dmm
The IESG | 11 Sep 16:30 2014
Picon

Last Call: <draft-ietf-dmm-best-practices-gap-analysis-07.txt> (Distributed Mobility Management: Current practices and gap analysis) to Informational RFC


The IESG has received a request from the Distributed Mobility Management
WG (dmm) to consider the following document:
- 'Distributed Mobility Management: Current practices and gap analysis'
  <draft-ietf-dmm-best-practices-gap-analysis-07.txt> as Informational
RFC

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@... mailing lists by 2014-09-25. Exceptionally, comments may be
sent to iesg@... instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract

   This document analyzes deployment practices of existing IP mobility
   protocols in a distributed mobility management environment.  It then
   identifies existing limitations when compared to the requirements
   defined for a distributed mobility management solution.

The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-dmm-best-practices-gap-analysis/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-dmm-best-practices-gap-analysis/ballot/

No IPR declarations have been submitted directly on this I-D.
The IESG | 11 Sep 16:30 2014
Picon

Last Call: <draft-ietf-dmm-best-practices-gap-analysis-07.txt> (Distributed Mobility Management: Current practices and gap analysis) to Informational RFC


The IESG has received a request from the Distributed Mobility Management
WG (dmm) to consider the following document:
- 'Distributed Mobility Management: Current practices and gap analysis'
  <draft-ietf-dmm-best-practices-gap-analysis-07.txt> as Informational
RFC

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf <at> ietf.org mailing lists by 2014-09-25. Exceptionally, comments may be
sent to iesg <at> ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract

   This document analyzes deployment practices of existing IP mobility
   protocols in a distributed mobility management environment.  It then
   identifies existing limitations when compared to the requirements
   defined for a distributed mobility management solution.

The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-dmm-best-practices-gap-analysis/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-dmm-best-practices-gap-analysis/ballot/

No IPR declarations have been submitted directly on this I-D.


Gmane