Hi Sri, please see inline. >-----Original Message----- >From: Sri Gundavelli (sgundave) [mailto:sgund...@cisco.com] >Sent: Donnerstag, 11. September 2014 15:58 >To: Marco Liebsch; Charlie Perkins; dmm@ietf.org >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" <marco.lieb...@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:sgund...@cisco.com] >>>Sent: Donnerstag, 11. September 2014 00:42 >>>To: Charlie Perkins; Marco Liebsch; dmm@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.perk...@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@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" <marco.lieb...@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-boun...@ietf.org] On Behalf Of Sri >>>>>>> Gundavelli >>>>>>> (sgundave) >>>>>>> Sent: Dienstag, 9. September 2014 23:30 >>>>>>> To: Sri Gundavelli (sgundave); Charlie Perkins; dmm@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)" >>>>>>> <sgund...@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.perk...@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@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
