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
>