Re: [DMM] MNID Types
"Sri Gundavelli (sgundave)" <sgundave@cisco.com> Thu, 11 September 2014 21:57 UTC
Return-Path: <sgundave@cisco.com>
X-Original-To: dmm@ietfa.amsl.com
Delivered-To: dmm@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 79F0A1A02E1 for <dmm@ietfa.amsl.com>; Thu, 11 Sep 2014 14:57:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -16.152
X-Spam-Level:
X-Spam-Status: No, score=-16.152 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-1.652, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0rw9n0MPDevo for <dmm@ietfa.amsl.com>; Thu, 11 Sep 2014 14:57:23 -0700 (PDT)
Received: from rcdn-iport-2.cisco.com (rcdn-iport-2.cisco.com [173.37.86.73]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5C9521A026F for <dmm@ietf.org>; Thu, 11 Sep 2014 14:57:13 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=30340; q=dns/txt; s=iport; t=1410472634; x=1411682234; h=from:to:subject:date:message-id:in-reply-to:mime-version; bh=aVSe9yNuFlkSf0qA/FH+g0YQ8BtI+rJjsJBdVOzbR9E=; b=Mat+K/K9VR5Nj0hmhldNdCOkw+eOetJf0YjyXbpUqn1DH+Pr4E9V7NKK GSqfzEYzoxDg52qkj84W+QUJI5eCrssS2YdT9fqs5b0rbL3D7FBgRrYub m0fFaCopnuYB4rYoa4rZ/z8ARP52nZmpJF/fLMx7prThS2ZhNGwREGDeM c=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AkMFAKAZElStJV2Y/2dsb2JhbABWCYJHRlNXBIJ4xUkBCYdNARl4FniEAwEBAQQBAQFrFwYBCA4DAwEBAQ4aBQQlCxQJCAIEARIJiCUDEQ2LYZw9Bo5oG4ZYAReNEBCBUjAJBwoYAgSCbYFZBYYeiReCFos2lTuDYWwBgUeBBwEBAQ
X-IronPort-AV: E=Sophos;i="5.04,508,1406592000"; d="scan'208,217";a="354523311"
Received: from rcdn-core-1.cisco.com ([173.37.93.152]) by rcdn-iport-2.cisco.com with ESMTP; 11 Sep 2014 21:57:13 +0000
Received: from xhc-aln-x03.cisco.com (xhc-aln-x03.cisco.com [173.36.12.77]) by rcdn-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id s8BLvCDx015332 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 11 Sep 2014 21:57:12 GMT
Received: from xmb-aln-x03.cisco.com ([169.254.6.21]) by xhc-aln-x03.cisco.com ([173.36.12.77]) with mapi id 14.03.0195.001; Thu, 11 Sep 2014 16:57:12 -0500
From: "Sri Gundavelli (sgundave)" <sgundave@cisco.com>
To: Charlie Perkins <charles.perkins@earthlink.net>, Marco Liebsch <Marco.Liebsch@neclab.eu>, "dmm@ietf.org" <dmm@ietf.org>, Vijay Devarapalli <dvijay@rocketmail.com>
Thread-Topic: [DMM] MNID Types
Thread-Index: AQHPzgtXaaKIRu1CzUiapIsrZvteqQ==
Date: Thu, 11 Sep 2014 21:57:11 +0000
Message-ID: <D03767BD.163EA7%sgundave@cisco.com>
In-Reply-To: <54121835.702@earthlink.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/14.2.3.120616
x-originating-ip: [10.21.64.105]
Content-Type: multipart/alternative; boundary="_000_D03767BD163EA7sgundaveciscocom_"
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/dmm/OlByXlU4Q1ipEVJ7sgLaoJy_hh4
Subject: Re: [DMM] MNID Types
X-BeenThere: dmm@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Distributed Mobility Management Working Group <dmm.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dmm>, <mailto:dmm-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dmm/>
List-Post: <mailto:dmm@ietf.org>
List-Help: <mailto:dmm-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dmm>, <mailto:dmm-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 11 Sep 2014 21:57:26 -0000
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@earthlink.net<mailto:charles.perkins@earthlink.net>> Date: Thursday, September 11, 2014 2:46 PM To: Sri Gundavelli <sgundave@cisco.com<mailto:sgundave@cisco.com>>, Marco Liebsch <Marco.Liebsch@neclab.eu<mailto:Marco.Liebsch@neclab.eu>>, "dmm@ietf.org<mailto:dmm@ietf.org>" <dmm@ietf.org<mailto:dmm@ietf.org>>, Vijay Devarapalli <dvijay@rocketmail.com<mailto:dvijay@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@cisco.com><mailto:sgundave@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@neclab.eu><mailto:Marco.Liebsch@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@cisco.com] Sent: Donnerstag, 11. September 2014 00:42 To: Charlie Perkins; Marco Liebsch; dmm@ietf.org<mailto: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.perkins@earthlink.net><mailto:charles.perkins@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.Liebsch@neclab.eu><mailto:Marco.Liebsch@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@ietf.org] On Behalf Of Sri Gundavelli (sgundave) Sent: Dienstag, 9. September 2014 23:30 To: Sri Gundavelli (sgundave); Charlie Perkins; dmm@ietf.org<mailto: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)" <sgundave@cisco.com><mailto:sgundave@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@earthlink.net><mailto:charles.perkins@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<mailto:dmm@ietf.org>https://www.ietf.org/mailman/listinfo/dmm _______________________________________________ dmm mailing list dmm@ietf.org<mailto:dmm@ietf.org>https://www.ietf.org/mailman/listinfo/dmm _______________________________________________ dmm mailing list dmm@ietf.org<mailto:dmm@ietf.org>https://www.ietf.org/mailman/listinfo/dmm _______________________________________________ dmm mailing list dmm@ietf.org<mailto:dmm@ietf.org>https://www.ietf.org/mailman/listinfo/dmm
- [DMM] regarding the re-chartering.. Jouni Korhonen
- Re: [DMM] regarding the re-chartering.. Behcet Sarikaya
- Re: [DMM] regarding the re-chartering.. Brian Haberman
- Re: [DMM] regarding the re-chartering.. Jouni Korhonen
- Re: [DMM] regarding the re-chartering.. Alper Yegin
- Re: [DMM] regarding the re-chartering.. Behcet Sarikaya
- Re: [DMM] regarding the re-chartering.. Jouni Korhonen
- Re: [DMM] regarding the re-chartering.. Weixinpeng
- Re: [DMM] regarding the re-chartering.. Jouni Korhonen
- Re: [DMM] regarding the re-chartering.. Jouni Korhonen
- Re: [DMM] regarding the re-chartering.. Alper Yegin
- Re: [DMM] regarding the re-chartering.. Jouni Korhonen
- Re: [DMM] regarding the re-chartering.. Alper Yegin
- Re: [DMM] regarding the re-chartering.. Templin, Fred L
- Re: [DMM] regarding the re-chartering.. Jouni Korhonen
- Re: [DMM] regarding the re-chartering.. Templin, Fred L
- Re: [DMM] regarding the re-chartering.. Templin, Fred L
- Re: [DMM] regarding the re-chartering.. Jouni Korhonen
- Re: [DMM] regarding the re-chartering.. Alper Yegin
- Re: [DMM] regarding the re-chartering.. Jouni
- Re: [DMM] regarding the re-chartering.. Behcet Sarikaya
- Re: [DMM] regarding the re-chartering.. Jouni Korhonen
- Re: [DMM] regarding the re-chartering.. Behcet Sarikaya
- Re: [DMM] regarding the re-chartering.. Jouni Korhonen
- Re: [DMM] regarding the re-chartering.. Behcet Sarikaya
- Re: [DMM] regarding the re-chartering.. Brian Haberman
- Re: [DMM] regarding the re-chartering.. Behcet Sarikaya
- Re: [DMM] regarding the re-chartering.. Brian Haberman
- Re: [DMM] regarding the re-chartering.. Behcet Sarikaya
- Re: [DMM] regarding the re-chartering.. Brian Haberman
- Re: [DMM] regarding the re-chartering.. Sri Gundavelli (sgundave)
- Re: [DMM] regarding the re-chartering.. Alexandru Petrescu
- Re: [DMM] regarding the re-chartering.. Jouni
- Re: [DMM] regarding the re-chartering.. Charles E. Perkins
- Re: [DMM] regarding the re-chartering.. Jouni
- Re: [DMM] regarding the re-chartering.. Alexandru Petrescu
- Re: [DMM] regarding the re-chartering.. Alexandru Petrescu
- Re: [DMM] regarding the re-chartering.. Behcet Sarikaya
- Re: [DMM] regarding the re-chartering.. Behcet Sarikaya
- Re: [DMM] regarding the re-chartering.. Zuniga, Juan Carlos
- Re: [DMM] regarding the re-chartering.. Alper Yegin
- Re: [DMM] regarding the re-chartering.. Alper Yegin
- Re: [DMM] regarding the re-chartering.. Alper Yegin
- Re: [DMM] regarding the re-chartering.. Alexandru Petrescu
- Re: [DMM] regarding the re-chartering.. Alper Yegin
- Re: [DMM] regarding the re-chartering.. Alexandru Petrescu
- Re: [DMM] regarding the re-chartering.. Charlie Perkins
- Re: [DMM] regarding the re-chartering.. Alper Yegin
- [DMM] MIP and GTP (was Re: regarding the re-chart… Alper Yegin
- Re: [DMM] MIP and GTP (was Re: regarding the re-c… Jouni
- Re: [DMM] regarding the re-chartering.. MONGAZON-CAZAVET, BRUNO (BRUNO)
- Re: [DMM] MIP and GTP (was Re: regarding the re-c… Templin, Fred L
- Re: [DMM] regarding the re-chartering.. Charlie Perkins
- Re: [DMM] regarding the re-chartering.. pierrick.seite
- Re: [DMM] regarding the re-chartering.. Sri Gundavelli (sgundave)
- Re: [DMM] regarding the re-chartering.. Sri Gundavelli (sgundave)
- Re: [DMM] regarding the re-chartering.. Suresh Krishnan
- Re: [DMM] regarding the re-chartering.. Suresh Krishnan
- Re: [DMM] regarding the re-chartering.. Sri Gundavelli (sgundave)
- Re: [DMM] regarding the re-chartering.. Brian Haberman
- Re: [DMM] regarding the re-chartering.. Sri Gundavelli (sgundave)
- Re: [DMM] regarding the re-chartering.. Charlie Perkins
- Re: [DMM] regarding the re-chartering.. Sri Gundavelli (sgundave)
- Re: [DMM] regarding the re-chartering.. Sri Gundavelli (sgundave)
- Re: [DMM] regarding the re-chartering.. Marco Liebsch
- Re: [DMM] regarding the re-chartering.. Sri Gundavelli (sgundave)
- Re: [DMM] regarding the re-chartering.. Charlie Perkins
- Re: [DMM] regarding the re-chartering.. Sri Gundavelli (sgundave)
- Re: [DMM] regarding the re-chartering.. Marco Liebsch
- Re: [DMM] regarding the re-chartering.. Sri Gundavelli (sgundave)
- [DMM] MNID Types Sri Gundavelli (sgundave)
- Re: [DMM] regarding the re-chartering.. Marco Liebsch
- Re: [DMM] regarding the re-chartering.. Sri Gundavelli (sgundave)
- Re: [DMM] MNID Types Charlie Perkins
- Re: [DMM] MNID Types Sri Gundavelli (sgundave)
- Re: [DMM] MNID Types Sri Gundavelli (sgundave)
- Re: [DMM] MNID Types Charlie Perkins
- Re: [DMM] MNID Types Charles E. Perkins
- Re: [DMM] MNID Types Templin, Fred L
- Re: [DMM] MNID Types Charles E. Perkins
- Re: [DMM] MNID Types Templin, Fred L
- Re: [DMM] MNID Types Sri Gundavelli (sgundave)
- Re: [DMM] MNID Types Sri Gundavelli (sgundave)
- Re: [DMM] MNID Types Charles E. Perkins
- Re: [DMM] MNID Types Sri Gundavelli (sgundave)
- Re: [DMM] MNID Types Sri Gundavelli (sgundave)