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

[Marco Liebsch <[e-mail]>]

Hi Sri, please see inline.

>-----Original Message-----
>From: Sri Gundavelli (sgundave) [mailto:[e-mail]]
>Sent: Donnerstag, 11. September 2014 15:58
>To: Marco Liebsch; Charlie Perkins; [e-mail]
>Cc: Vijay Devarapalli
>Subject: Re: [DMM] regarding the re-chartering..
>
>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.

Then there is no issue and it's the cleanest approach. Multiple IDs possible,
deployment determines which type to use, single MNID present. Done.

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

Not necessarily for the lookup. 
Only if multiple IDs should be conveyed to do more than a lookup..
Example: Use the TAC of an IMEI to tailor QoS on the LMA for a certain device type ;-)
Probably that goes beyond what has been proposed in this thread.

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

I proposed this only for IDs, which are conveyed to complement the one in the
MNID and are being used for other things than a BC lookup.

marco

>
>
>
>
>Sri
>
>
>
>
>
>On 9/11/14 2:03 AM, "Marco Liebsch" <[e-mail]> 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:[e-mail]]
>>>Sent: Donnerstag, 11. September 2014 00:42
>>>To: Charlie Perkins; Marco Liebsch; [e-mail]
>>>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" <[e-mail]>
>>>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@REALM), its based on
>>>>>the IMSI. Ex:
>>>>> "<IMSI>@epc.mnc<MNC>.mcc<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" <[e-mail]> 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:[e-mail]] On Behalf Of Sri
>>>>>>> Gundavelli
>>>>>>> (sgundave)
>>>>>>> Sent: Dienstag, 9. September 2014 23:30
>>>>>>> To: Sri Gundavelli (sgundave); Charlie Perkins; [e-mail]
>>>>>>> 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)"
>>>>>>> <[e-mail]>
>>>>>>> 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"
>>>>>>>><[e-mail]>
>>>>>>>> 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
>>>>>>>> [e-mail]
>>>>>>>> https://www.ietf.org/mailman/listinfo/dmm
>>>>>>> _______________________________________________
>>>>>>> dmm mailing list
>>>>>>> [e-mail]
>>>>>>> https://www.ietf.org/mailman/listinfo/dmm
>>>>>
>>>>
>>