Re: [DMM] Questions on draft-matsushima-stateless-uplane-vepc-02

Satoru Matsushima <satoru.matsushima@gmail.com> Thu, 22 May 2014 02:49 UTC

Return-Path: <satoru.matsushima@gmail.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 06A801A0078 for <dmm@ietfa.amsl.com>; Wed, 21 May 2014 19:49:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] 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 5wQeNG8OWNnX for <dmm@ietfa.amsl.com>; Wed, 21 May 2014 19:49:28 -0700 (PDT)
Received: from mail-yh0-x22c.google.com (mail-yh0-x22c.google.com [IPv6:2607:f8b0:4002:c01::22c]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 89BD51A006D for <dmm@ietf.org>; Wed, 21 May 2014 19:49:28 -0700 (PDT)
Received: by mail-yh0-f44.google.com with SMTP id b6so2467632yha.31 for <dmm@ietf.org>; Wed, 21 May 2014 19:49:27 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=lYzrQYNcdSAbm3OnFijZX1NzeRIGcDCGjP/cJwS920s=; b=QoplVtqEAdiUq7pjImJ1Yr1cO6gM/M275efKNM7C4CEYu5MaVPoWYDnHMKabLnpIyU MwD5n8ATOf8ymEmalCIMxbft+2UQtXnWSOeAlmKL38m90MpgOb6iwMY53YHYSkL1v+5A oZuzFNa0DaGiWBX67FRR4PaiyC39GRAfaH5ieoGhKheOani4lFRsHIoYa4LDlelO7oa2 8tgf3SNBTbDZqgaX1tj/JjGJqV+H2bKRM+vPtvCHtvE3AaBhB/axHcwB7bPoEs/tPGqh FNouUGvWqogAyxPU8LFokldTEsW0KribBSY7WFxnZDtkn8/7P6ACATrA0u7kfGWw9/Ts Pddw==
MIME-Version: 1.0
X-Received: by 10.236.172.170 with SMTP id t30mr32197287yhl.136.1400726967078; Wed, 21 May 2014 19:49:27 -0700 (PDT)
Received: by 10.170.155.213 with HTTP; Wed, 21 May 2014 19:49:27 -0700 (PDT)
In-Reply-To: <CAC8QAcewzM6YLu5t+XhUQwpmjCZNMRoNbNdQ_ekOhtgqHHaiNA@mail.gmail.com>
References: <CAC8QAcf-__v4qR+Z2Zh2az+W3BTR_Bu8JkZxbWirHHw7zKm2WQ@mail.gmail.com> <CAFwJXX6FN2TRt4RUafDEw0VSPapVHZzWBP81k6aEr5reUh+vvg@mail.gmail.com> <CAC8QAcfhxvSDH-NoaFeuCuWQC5JudLq1h8Xj2No0i5bAd_MPqA@mail.gmail.com> <CAFwJXX5xUNXjjmtN5PuCLFGHsfZL-mvBVjRfbAnGdrc3wvqL0g@mail.gmail.com> <CAC8QAcewzM6YLu5t+XhUQwpmjCZNMRoNbNdQ_ekOhtgqHHaiNA@mail.gmail.com>
Date: Thu, 22 May 2014 11:49:27 +0900
Message-ID: <CAFwJXX7Eco5UC0Yznr3t1be_1FCiPC5Z5sNtbaPCs5n_r01NQA@mail.gmail.com>
From: Satoru Matsushima <satoru.matsushima@gmail.com>
To: sarikaya@ieee.org
Content-Type: multipart/alternative; boundary="20cf30426ef04d35eb04f9f4299a"
Archived-At: http://mailarchive.ietf.org/arch/msg/dmm/glteYOOV1o0rOTkdMByfRqM3s0M
Cc: "dmm@ietf.org" <dmm@ietf.org>
Subject: Re: [DMM] Questions on draft-matsushima-stateless-uplane-vepc-02
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, 22 May 2014 02:49:30 -0000

Hi Behcet,


On Thu, May 22, 2014 at 12:58 AM, Behcet Sarikaya <sarikaya2012@gmail.com>wrote:
-- snip --


> >> >> Referring to Steps 14 and 15 in Figure 4, in Step 14, Route Update (I
> >> >> guess BGP Route Update) is initiated by
> >> >> which node and is going to which node?
> >> >
> >> > As you see step 14 in the sequence, any specific node aren't assumed
> to
> >> > initiate routing update on vEPC side, due to the scope of the draft,
> >> > EPC-E
> >> > router is the receiving node of routing update
> >>
> >> You mean more than one node can initiate it, my question was which
> >> node(s)?
> >>
> >
> > I meant that the draft doesn't mention exactly which node advertise
> that, it
> > could be expected to exist in the vEPC side. But I find that in terms of
> > usual BGP operation, that node could be Route-Reflector(RR), or
> > Route-Server(RS).
> > Just one case would be expected that a set of information which includes
> an
> > endpoint information of tunnel and an UE assigned prefix is informed
> from a
> > mobility management node in the vEPC to RR or RS.
> >
>
> Are you sure?
> How would RR or RS know about UE mobility?
>
> I was expecting you to say MME?
>
>
Ah, I see what you mean. Yes, I'm sure that RR/RS just only know about
routes, nor whole mobility information exists. When I see a node which
plays MME role, the node could also be a BGP speaker to export the mobility
info transformed to the routes.



> >
> >>
> >> >
> >> >> In Step 15 you have EPC-E initiating this and it is going towards
> RTR.
> >> >> Why
> >> >> is this not sufficient? i.e. since EPC-E
> >> >> can detect mobility?
> >> >> Why do you need Step 14?
> >> >
> >> > The reason of the EPC-E advertise route toward RTR is that EPC-E can
> >> > aggregate multiple UE's prefixes into less BGP routes as a part of
> >> > normal
> >> > routing operation within operator's network.
> >>
> >> You mean host routes are not needed in the upstream BGP routers? How
> >> does that work?
> >
> >
> > Yes, host routes are not needed in the upstream routers because
> aggregated
> > routes EPC-E router advertised work well for the upstream routers to send
> > out packets toward advertising EPC-E routers.
> >
>
> Isn't it kind of host routes? Maybe host prefixes? Otherwise I can not
> image how you would route to UEs that are topologically incorrect?
>

What do you mean by "topologically incorrect"?
Is that the assigned prefixes are disordered to be aggregated?

cheers,
--satoru