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

["Sri Gundavelli (sgundave)" <[e-mail]>]

This is bit strange. Some thing changed in the IANA Mobile Node Identifier pages.  I assumed the MN Id was defined in RFC4283. How come I see a definition in 5271 as well.


Confused. Jouni / Brian – Any ideas ? Unless, I've been smoking …



http://tools.ietf.org/html/rfc4283#page-3

http://tools.ietf.org/html/rfc5271#page-16


I remember this in the IANA pages. Unless, I edited this when I copied this into a mail in Feb 2013.

Value [http://www.iana.org/assignments/_support/sort_none.gif]  Description [http://www.iana.org/assignments/_support/sort_none.gif]    Reference [http://www.iana.org/assignments/_support/sort_none.gif]
1       NAI     [RFC4283<http://www.iana.org/go/rfc4283>]
               2            USER-NAI (user@realm, should not be used for IMSI-NAI)
               3            MAC-48




Now I see the following:

Option-Code for Mobile Node Identifier Option (Type 30)

Registration Procedure(s)

Standards Action or IESG Approval

Reference
[RFC5271<http://www.iana.org/go/rfc5271>]
Available Formats
[http://www.iana.org/_img/icons/text-csv.png]
CSV<http://www.iana.org/assignments/icmpv6-parameters/icmpv6-parameters-9.csv>
Value [http://www.iana.org/assignments/_support/sort_none.gif]  Description [http://www.iana.org/assignments/_support/sort_none.gif]    Reference [http://www.iana.org/assignments/_support/sort_none.gif]
0       Reserved        [RFC5271<http://www.iana.org/go/rfc5271>]
1       NAI     [RFC5271<http://www.iana.org/go/rfc5271>]
2       IMSI    [RFC5271<http://www.iana.org/go/rfc5271>]
3-255   Unassigned



From: Sri Gundavelli <[e-mail]<mailto:[e-mail]>>
Date: Tuesday, September 9, 2014 7:06 AM
To: "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>, Charlie Perkins <[e-mail]<mailto:[e-mail]>>, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>>
Subject: Re: [DMM] regarding the re-chartering..

I support the extension to MN Id type. I talked to few people (Yokota-san, Jouni ..)  on this in the past and below is the explanation. Currently, the NAI that is carried in the PBU does not distinguish a IMSI based NAI, generic-NAI and a MAc-based NAI. Email below.

Regarding supporting GTP-U as a tunnel type, I'm not to keen on that. If the tunnel type is GTP-U, there is no reason for the SDO to use a different signaling protocol, it can be GTP-C. That battle is over, I'd rather focus on pushing SDN approaches than trying to supporting GTP-U types in IETF mobility protocols. But, if some one wants to do this, I'll not argue against this.


Sri



From: Sri Gundavelli <[e-mail]<mailto:[e-mail]>>
Date: Thursday, February 28, 2013 11:57 AM
To: Hidetoshi Yokota <[e-mail]<mailto:[e-mail]>>
Subject: NAI Support over Gx

Hi Yokota-san:


We need a new sub-type to differentiate between NAI (user@realm) vs., IMSI-NAI. Can we define new sub-types to Mobile Node Identifier option ?


Value [http://www.iana.org/assignments/_support/sort_none.gif]  Description [http://www.iana.org/assignments/_support/sort_none.gif]    Reference [http://www.iana.org/assignments/_support/sort_none.gif]
1       NAI     [RFC4283<http://www.iana.org/go/rfc4283>]
               2            USER-NAI (user@realm, should not be used for IMSI-NAI)
               3            MAC-48


Goal is to address the issue below.

Any comments ?



---

1. If MAG sends a PBU which includes IMSI:

MN NAI Mobility Option Follows:
                Type: 0x08
              Length: 0x36
            Sub Type: 0x01
                 NAI: [e-mail]<mailto:[e-mail]>

The LMA will trigger the PCRF using the following AVP in the Gx CCR-I:

        [M] Subscription-Id:
          [M] Subscription-Id-Type: END_USER_IMSI (1)
          [M] Subscription-Id-Data: 724052800014033





2. If MAG sends a PBU which includes MSISDN:

Vendor Specific Mobility Option Follows:
                Type: 0x13
              Length: 0x0C
           Vendor ID: 0x000028AF
            Sub Type: 0x0C (MSISDN)
   Fragment (M) Flag: 0x00
              MSISDN: <552176297602>

Then, the LMA will trigger the PCRF using the following AVP in the Gx CCR-I:

        [M] Subscription-Id:
          [M] Subscription-Id-Type: END_USER_E164 (0)
          [M] Subscription-Id-Data: 552176297602




3. If the MAG sends a PBU with Username:

MN NAI Mobility Option Follows:
                Type: 0x08
              Length: 0x2C
            Sub Type: 0x01
                 NAI: [e-mail]<mailto:[e-mail]>

Then, How can LMA trigger the PCRF with this following AVP ?:

        [M] Subscription-Id:
          [M] Subscription-Id-Type: END_USER_NAI (3)
          [M] Subscription-Id-Data: [e-mail]<mailto:[e-mail]>



On 9/9/14 2:04 AM, "[e-mail]<mailto:[e-mail]>" <[e-mail]<mailto:[e-mail]>> 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:[e-mail]] De la part de Charlie Perkins
Envoyé : lundi 8 septembre 2014 19:50
À : MONGAZON-CAZAVET, BRUNO (BRUNO); [e-mail]<mailto:[e-mail]>
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
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/dmm


_______________________________________________
dmm mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/dmm
_______________________________________________
dmm mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/dmm


_______________________________________________
dmm mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/dmm



_______________________________________________
dmm mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/dmm


_______________________________________________
dmm mailing list
[e-mail]<mailto:[e-mail]>
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 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 its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

_______________________________________________
dmm mailing list
[e-mail]<mailto:[e-mail]>
https://www.ietf.org/mailman/listinfo/dmm