Re: [DMM] Fwd: New Version Notification for draft-matsushima-stateless-uplane-vepc-00.txt

Satoru Matsushima <satoru.matsushima@gmail.com> Sat, 13 July 2013 17:21 UTC

Return-Path: <satoru.matsushima@gmail.com>
X-Original-To: dmm@ietfa.amsl.com
Delivered-To: dmm@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 61F2B21F9A51 for <dmm@ietfa.amsl.com>; Sat, 13 Jul 2013 10:21:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.471
X-Spam-Level:
X-Spam-Status: No, score=-2.471 tagged_above=-999 required=5 tests=[AWL=0.129, BAYES_00=-2.599, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id x4+4BZbPVeTH for <dmm@ietfa.amsl.com>; Sat, 13 Jul 2013 10:21:00 -0700 (PDT)
Received: from mail-pb0-x22e.google.com (mail-pb0-x22e.google.com [IPv6:2607:f8b0:400e:c01::22e]) by ietfa.amsl.com (Postfix) with ESMTP id 3358D21F8423 for <dmm@ietf.org>; Sat, 13 Jul 2013 10:21:00 -0700 (PDT)
Received: by mail-pb0-f46.google.com with SMTP id rq2so9949142pbb.5 for <dmm@ietf.org>; Sat, 13 Jul 2013 10:20:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=content-type:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to:x-mailer; bh=KBs/nEGuj67PtNDyxRporSTiCrYEtJx7EKmDtJiai0w=; b=OEPvdQInpOT0uR4OjRejLJk1lqHY5YJtg7DHlTDc6x3QT0PrKt5zyPGqkpUpVfWKWC RkGHlY/bgW1SW3Ajup0o/UiYAVV4fchgrSOs5plKcLn5sDEnl5hU2kq8Q+027atl2B1y tRKNw3h+vFK5kWXHCbMGbm0FpYu0a96HAZi/cLC4cfC4Y7Fy33cH78hcmrmCrnmj8Syw 6jIhaDHdGcC7uztd7BVyNwYwmDPELvAqaczhHobGryKjiCaIxiNpnQSibknG3WRaaeb2 04swvyKYTrMorUWP9dND2XpSLIJ+icPdlmk/w+IgOiZtgDm8Lw10JYO7k4zJSCF1SE6W rp6g==
X-Received: by 10.69.8.164 with SMTP id dl4mr47053788pbd.125.1373736058777; Sat, 13 Jul 2013 10:20:58 -0700 (PDT)
Received: from ?IPv6:2400:2411:8900::9cf6:a7db:4393:dcfe? ([2400:2411:8900:0:9cf6:a7db:4393:dcfe]) by mx.google.com with ESMTPSA id qg10sm21898235pbb.2.2013.07.13.10.20.55 for <multiple recipients> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sat, 13 Jul 2013 10:20:57 -0700 (PDT)
Content-Type: text/plain; charset="us-ascii"
Mime-Version: 1.0 (Mac OS X Mail 6.5 \(1508\))
From: Satoru Matsushima <satoru.matsushima@gmail.com>
In-Reply-To: <5963DDF1F751474D8DEEFDCDBEE43AE716F4F1E8@dfweml512-mbx.china.huawei.com>
Date: Sun, 14 Jul 2013 02:20:53 +0900
Content-Transfer-Encoding: quoted-printable
Message-Id: <504A19F8-3C16-4821-86A5-3C3BCA96FE78@gmail.com>
References: <20130710160944.11064.6824.idtracker@ietfa.amsl.com> <724A5F78-33A4-4608-82B9-231DC2AAE2F6@gmail.com> <5963DDF1F751474D8DEEFDCDBEE43AE716F4F1E8@dfweml512-mbx.china.huawei.com>
To: Peter McCann <Peter.McCann@huawei.com>
X-Mailer: Apple Mail (2.1508)
Cc: "dmm@ietf.org" <dmm@ietf.org>
Subject: Re: [DMM] Fwd: New Version Notification for draft-matsushima-stateless-uplane-vepc-00.txt
X-BeenThere: dmm@ietf.org
X-Mailman-Version: 2.1.12
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: Sat, 13 Jul 2013 17:21:01 -0000

Hi Pete,

Thanks for your comments.

On 2013/07/14, at 0:49, Peter McCann <Peter.McCann@huawei.com> wrote:

> Hi, Ryuji, Satoru,
> 
> If I understand your draft correctly, you are encoding the PGW ID and the
> TEID into the prefix portion of an IPv6 address.  You seem to allocate
> 16 bits for the TEID.  I thought that TEIDs in 3GPP were 32 bits.  Do you
> have enough space?  Could you instead encode the TEID in the Interface
> Identifier part of the IPv6 address?

Oops. Yes, you are correct. I'll update it soon.
Using TEID is one of the candidates of generating unique MN's prefix as described in stateless-pd draft.
(http://tools.ietf.org/html/draft-savolainen-stateless-pd-01)

Full of 32bits space is not necessary because embedded ID could be shortened by taking a part 16 bits or more longer from an TEID as long as its uniqueness is kept. We assume that the RAN side TEID assigned by SGW are encoded to MN's prefix. 

> 
> Perhaps I have misunderstood how the routing update is supposed to work,
> but why do you need to encode the UE's prefix or address at all in the
> Next-Hop IPv6 address?  You have the UE's prefix as the Destination, and
> the Next-Hop can just point to the tunnel, correct?

UE's prefix is not encoded in the next-hop. The next-hop indicates tunnel endpoint in the way of BGP remote next-hop draft. Please see "http://tools.ietf.org/html/draft-vandevelde-idr-remote-next-hop-03"

cheers,
--satoru

> 
> -Pete
> 
> Ryuji Wakikawa wrote:
>> Hi
>> 
>> We submit a new document.  Your comments are appreciated!
>> 
>> thanks,
>> ryuji
>> 
>> 
>> Begin forwarded message:
>> 
>>> From: internet-drafts@ietf.org
>>> Subject: New Version Notification for
>>> draft-matsushima-stateless-uplane-vepc-00.txt
>>> Date: July 10, 2013 9:09:44 AM PDT
>>> To: Ryuji Wakikawa <ryuji.wakikawa@gmail.com>, Satoru Matsushima
>>> <satoru.matsushima@g.softbank.co.jp>
>>> 
>>> 
>>> A new version of I-D, draft-matsushima-stateless-uplane-vepc-00.txt has
>>> been successfully submitted by Satoru Matsushima and posted to the IETF
>>> repository.
>>> 
>>> Filename:	 draft-matsushima-stateless-uplane-vepc Revision:	 00
>>> Title:		 Stateless user-plane architecture for virtualized EPC (vEPC)
>>> Creation date:	 2013-07-10 Group:		 Individual Submission Number of
>>> pages: 19 URL:             http://www.ietf.org/internet-drafts/draft-
>>> matsushima-stateless-uplane-vepc-00.txt Status:         
>>> http://datatracker.ietf.org/doc/draft-matsushima- stateless-uplane-vepc
>>> Htmlized:        http://tools.ietf.org/html/draft-matsushima-
>>> stateless-uplane-vepc-00
>>> 
>>> 
>>> Abstract:
>>>  We envision a new mobile architecture for the future Evolved Packet
>>>  Core (EPC).  The new architecture is designed to support the
>>>  virtualization scheme called NFV (Network Function Virtualization).
>>>  In our architecture, the user plane of EPC is decoupled from the
>>>  control-plane and uses routing information to forward packets of
>>>  mobile nodes.  Although the EPC control plane will run on hypervisor,
>>>  our proposal does not modify the signaling of the EPC control plane.
>>>  The benefits of our architecture are 1) scalability, 2) flexibility
>>>  and 3) Manageability.  How to run the EPC control plane on NFV is out
>>>  of our focus in this document.
>>> 
>>> 
>>> 
>>> The IETF Secretariat
>>> 
>> 
>> _______________________________________________
>> 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