<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)" <[email protected]> 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" <[email protected]> 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:[email protected]] >>>Sent: Donnerstag, 11. September 2014 00:42 >>>To: Charlie Perkins; Marco Liebsch; [email protected] >>>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" <[email protected]> >>>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" <[email protected]> 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:[email protected]] On Behalf Of Sri Gundavelli >>>>>>> (sgundave) >>>>>>> Sent: Dienstag, 9. September 2014 23:30 >>>>>>> To: Sri Gundavelli (sgundave); Charlie Perkins; [email protected] >>>>>>> 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)" <[email protected]> >>>>>>> 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" >>>>>>>><[email protected]> >>>>>>>> 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 >>>>>>>> [email protected] >>>>>>>> https://www.ietf.org/mailman/listinfo/dmm >>>>>>> _______________________________________________ >>>>>>> dmm mailing list >>>>>>> [email protected] >>>>>>> https://www.ietf.org/mailman/listinfo/dmm >>>>> >>>> >> > >_______________________________________________ >dmm mailing list >[email protected] >https://www.ietf.org/mailman/listinfo/dmm _______________________________________________ dmm mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmm
