Re: [Ideas] Mobility usecase draft-padma-ideas-problem-statement-00.txt
Tom Herbert <tom@herbertland.com> Fri, 28 October 2016 23:53 UTC
Return-Path: <tom@herbertland.com>
X-Original-To: ideas@ietfa.amsl.com
Delivered-To: ideas@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1])
by ietfa.amsl.com (Postfix) with ESMTP id 951D71296D8
for <ideas@ietfa.amsl.com>; Fri, 28 Oct 2016 16:53:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5
tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
RCVD_IN_DNSWL_LOW=-0.7] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key)
header.d=herbertland-com.20150623.gappssmtp.com
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 AJ4Zgj95zX_g for <ideas@ietfa.amsl.com>;
Fri, 28 Oct 2016 16:53:21 -0700 (PDT)
Received: from mail-qk0-x22c.google.com (mail-qk0-x22c.google.com
[IPv6:2607:f8b0:400d:c09::22c])
(using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits))
(No client certificate requested)
by ietfa.amsl.com (Postfix) with ESMTPS id 960E11296D7
for <ideas@ietf.org>; Fri, 28 Oct 2016 16:53:21 -0700 (PDT)
Received: by mail-qk0-x22c.google.com with SMTP id v138so14832980qka.0
for <ideas@ietf.org>; Fri, 28 Oct 2016 16:53:21 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=herbertland-com.20150623.gappssmtp.com; s=20150623;
h=mime-version:in-reply-to:references:from:date:message-id:subject:to
:cc; bh=htptznJ1CRmmdIHNI5iRD/Xl1WWLuMhEW9QHVH4vBe8=;
b=BtlKpZ1N/iBp1W3NPe47KrJIj+wWuN5pN89cL46T/WpeD/cWGPuhUghS7Lny6F1Jx1
j/KVOPsgSr3zZMe7qyRRAirUV26sKYe011Lr6yRb/Y5ccN5a4mi8Nn7wDIMIPn4i6SFM
7xS8R0i1qYKhgWQxg0hWfnO4kZU12gch8ALHVceFeqmvsCf7q+9Pmq/oXa2c6vEp6Gju
dX0l5qAz0I4GV3wdUpxq9qu4ajXNGAer5AAVN0IJlgJx9q14p60q45Krl1wKMj4pBV9k
un+f5dwDnxqAMZ6g85pwD0n23BNCj7l1qiJuKuFfA/mzApD0mjplGb75NcTDhbSPeRSb
Jm3Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20130820;
h=x-gm-message-state:mime-version:in-reply-to:references:from:date
:message-id:subject:to:cc;
bh=htptznJ1CRmmdIHNI5iRD/Xl1WWLuMhEW9QHVH4vBe8=;
b=B1PfRfoE23NTsRwYWbdeB+CudZ7+qebp9LtnomSrOyDjdRJ0HJ3Vp9rqTU0kkoMmOf
Gm27DxmH12s50ynAF9MuCPP6JcTJ5p4qju6TkqkFQTPuyF2JBzaMP5VOBJ32CeKbPRJd
74YR7CqpJCPNT9y1jzMN3y/TMidLkkB91qQe02Hb8AZ+8aXbd3m1w7i8/R28/eJNjCql
429WMv75Bw5G3c19/zDvXn2HzyR1voxqpuOfnnjoSkYWYJoEu3pj+4+pM8EQMZZRUefR
sn+pEcAA+Kyo5NOs6BPqJGnxZFJ0ALV2iC+jwVZ3fB48N0EaCKhOi2aneQVqBJYmq817
IoKw==
X-Gm-Message-State: ABUngvdROdk+meXpkvJN26K431hX9KiLb6bazIEp11awJKqlQY49KbfkfWQ7/THYd/5FTNyjBomq6TBSBsTFlQ==
X-Received: by 10.55.41.39 with SMTP id p39mr13148039qkh.245.1477698800577;
Fri, 28 Oct 2016 16:53:20 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.237.44.71 with HTTP; Fri, 28 Oct 2016 16:53:20 -0700 (PDT)
In-Reply-To: <CAEZ-O0m7__b5v-zydAcjzgLQWXU_xYnLyiOT+7KPh=Q4HHBZdg@mail.gmail.com>
References: <CAEZ-O0m7__b5v-zydAcjzgLQWXU_xYnLyiOT+7KPh=Q4HHBZdg@mail.gmail.com>
From: Tom Herbert <tom@herbertland.com>
Date: Fri, 28 Oct 2016 16:53:20 -0700
Message-ID: <CALx6S37MoFjXuxqaLRmDsY62zwdLLPz=OxUmnCi1aQ60aN9ikw@mail.gmail.com>
To: Kiran Makhijani <kiranmak@gmail.com>
Content-Type: text/plain; charset=UTF-8
Archived-At: <https://mailarchive.ietf.org/arch/msg/ideas/5XpOgPG-6OcGkN5oUwcVnlPUnq8>
Cc: ideas@ietf.org
Subject: Re: [Ideas] Mobility usecase
draft-padma-ideas-problem-statement-00.txt
X-BeenThere: ideas@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: "Discussions relating to the development, clarification,
and implementation of control-plane infrastructures and
functionalities in ID enabled networks." <ideas.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ideas>,
<mailto:ideas-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ideas/>
List-Post: <mailto:ideas@ietf.org>
List-Help: <mailto:ideas-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ideas>,
<mailto:ideas-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 28 Oct 2016 23:53:23 -0000
On Tue, Oct 4, 2016 at 4:02 PM, Kiran Makhijani <kiranmak@gmail.com> wrote: > Hello authors, > +1 on the problem statement. I think a uniform approach to mapping system > framework is very much needed. > But if it is ID specific there are many more functionalities related to > Identity in the networks than just the mapping systems. Is the scope only > limited to mapping function aspects? > For the purposes of this I would say that the scope is limited to mapping function aspects. But, even with that scope it is going to be hard to produce a mapping system without having some discussion as to how IDs are generated and managed in the first place (like how do we ensure uniqueness, ID namespaces, etc.). So in the end the scope actually will be pretty broad it we're trying for a general solution. > I also have some questions in the mobility section. > - In 7.1.1, "we assume that ID functionality is handled within the network > and is transparent to the UEs or hosts." > What kind of ID functionality is being assumed here? I'd say this refers to the mapping of location to identifiers. A UE might know its identity and give that do the network, but the mapping, mobility related functions are more likely handled by the network. This pragmatic in that we can't change all UEs (e.g. smart phones) to participate in a new mobility protocol. > - Figure in 7.1.1 assumes that MGW is only required for mobile networks. Are > you saying that Host1 and Host2 are not ID enabled and IDs are only mappable > in mobile networks. So, if UE does not need mobility, it need not go through > MGW? I thinks that's true based on the scalability problem I mentioned above about UEs participating in mobility. Most likely they will live behind a MGW (ILA router in ILA nomenclature) that does mapping and forwarding for mobile nodes. If a MGW doesn't need mobility then it's packets (directed to it) wouldn't need to go through MGW-- it just looks like a non-mobile host at that point. > - Can I assume that functional block "Mapping System" is missing from > figure? OR is it not same as the MGW? > MGW uses mapping system. The mapping system wouldn't be a discrete node in the network. Although there might be devices that just provide resolutions and mapping without implementing gateway functionality (may like an NVA in nvo3 parlance). > 1. The new carrier provides the full locator (mapping to > Base_station2) and the MGW sends directly to that locator > > - Not sure what you said in this part and the lines that followed in 7.1.2. > Could you explain what is full locator (vs just locator) and only > significant in inter-provider case? a UE can move from one base station to > other in single provider network too. Why wont you need 'full locator' > there? > I think we're making a subtle distinction that should probably be spelled out. Consider that after migration UE.A wants to speak to UE.B in a different carrier network. We need an MGW to resolve the address. There's are two possibilities reference here: 1) Two mappings: UE.A sends packet to a local MGW. MGW maps destination to an address of a MGW in the other provider. Packet forwarded to that provider. Received by the MGW at that provider and then a second mapping occurs to get packet to UE.B within that provider. 2) One mapping: UE.A sends packet to a local MGW. The local MGW knows the exact mapping for the address of UE.B in other provider (this is what we meant by full locator). The packet is mapped and forwarded direct to where UE.B without any further mapping. The advantage of #1 is that providers don't need to share as much information. For instance, if UE.B is moving around in the new providers network, UE.A's network doesn't need to know about that. The downside is that it results in more hops and triangular rouitng. Tom > Thanks > Kiran > > > > -- > Kiran > > _______________________________________________ > Ideas mailing list > Ideas@ietf.org > https://www.ietf.org/mailman/listinfo/ideas >
- [Ideas] Mobility usecase draft-padma-ideas-proble… Kiran Makhijani
- Re: [Ideas] Mobility usecase draft-padma-ideas-pr… Tom Herbert
- Re: [Ideas] Mobility usecase draft-padma-ideas-pr… Dino Farinacci