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

From: Satoru Matsushima <[email-masked]>
Date: Wed, 2 Apr 2014 12:07:26 +0900

Peter,

On Mon, Mar 31, 2014 at 10:18 PM, Peter McCann <[email-masked]>wrote:
--snip--

> > No, it isn't meant that specific routes to indicate each UEs prefix
> > are advertised into the core.
> > I'll try to improve that text in next revision of the draft.
>
> Yes please clarify because the current text seems to say that UE prefixes
> are advertised into the core.
>
>
Yes, thanks.

> > I agree with you if a EPC-E has whole UE specific routes that exceed
> > its capacity, it doesn't scale, yes. In the recent presentation
> > through the webex, Ryuji were trying to explain that it's not intended
> to do.
> > Routes contained in EPC-E will be limited/partitioned by operators
> > policy, such as region, service, population scale, etc.,
>
> I was a bit confused by the suggestion to partition by region, because
> there would be no mobility across regions if you partitioned in this way.
> That's because different regions would use different PDN prefixes.  But,
> I suppose it would be ok to do this if you didn't need to support UE
> mobility across regions (or if you used OTT mobility such as client MIP
> for those cases).
>
>
Partitioned by region sounds like that each regional network is isolated so
that they has no connectivity between them.
But it is not what I meant. Although a PDN prefix would be partitioned by
region, the networks doesn't really need to be isolated.
For example, when all EPC-E routers have connectivity to reach all RAN
nodes, it makes easy to provide mobility across regions.
Do you think that describing in the draft this kind of networking concept
would be helpful to make things clear?

> >>      You seem to attempt to address this issue in Section 4.1 when you
> talk
> >> about multiple       "sets" of EPC-E devices, each one dedicated to a
> given
> >> geographic region.
> >
> >
> > Ah, no. Sec 4.1 is intended to explain just scalability issue, and how
> > to deal that issues with routing techniques in operation.
>
> Ok, I guess in the most common case you would have several "slices" of
> EPC-E, each set serving a different PDN prefix and a different set of UEs.
> There would be one EPC-E from each slice, each representing a partition of
> the PDN prefixes, at each EPC-E deployment site between eNBs and core.
> A given UE's current location would need to be BGP UPDATEd to each of the
> EPC-E in the slice that covered that UE's PDN prefix.
>

In my mind, that sounds like when an operator assign a prefix to a PDN, the
operator can divide the prefix into several longer prefixes. Each divided
prefix, let's say "sub-PDN prefix", may be allocated to a region, or any
other operator's partition policy. It doesn't need to be assign a whole PDN
prefix to a partition, or "slice" you said.

>
> >>       It seems to me that each "set" of EPC-E could cover no more than
> the
> >> scope covered by a single    SGW today, because they each have the same
> >> amount of state as an SGW. Essentially       you have described how to
> build
> >> a replicated SGW with failover to different nodes    based on the
> >> re-convergence of BGP after a failure (presumably you could get the
> >>      core network to react to the closure of a BGP TCP session).  So I
> think
> >> this addresses       the problem of fault-tolerance that has been
> identified
> >> with the tunnel-based solutions,     but not really the scalability
> >> bottleneck problem.
> >
> > The nature of BGP makes easy to do that. I think Sec 3.4 would be
> > right place to explain that. But I couldn't see that flavor of text in
> > sec 4.1. Would you point which text in Sec 4.1 makes you confuse?
>
> It was the text in the penultimate paragraph that talked about partitioning
> by region.  If you do that, there is no mobility across regions, right?
>

As I mentioned before, mobility across regions is available.

> But if you partition by PDN prefix (sets of UEs) then you can have a whole
> stack of EPC-E at each deployment site, covering the entire population of
> UEs.
>
> >>      In fact, if you consider mobility from one "set" to another, if you
> >> want to keep the
> >>      UE's IP address, you would need to broadcast the same set of PDN
> >> prefixes from all
> >>      sets of EPC-E.  In fact this would mean that all EPC-E throughout
> the
> >> network, even
> >>      if they are in different "sets", need to be prepared to handle
> >> packets for any UE
> >>      and so they ALL would need the eNB F-TEIDs for ALL UEs.  Please
> tell
> >> me where I have
> >>      made a mistake.
> >
> >
> >
> > No, an EPC-E just only receives packets from v6 core network toward
> > UEs that routes installed into EPC-E. Because of that an EPC-E should
> > advertise aggregated routes only for that includes its downstream UEs.
> > When the EPC-E advertises whole routes to the core as you explained,
> > yes I agree with you that won't be scalable. But it would depend on
> > EPC-E capacity and size of UE population in the network.
>
> Ok, so each EPC-E just serves a slice (set of PDN prefixes) of the UE
> population, right?  There is no need to put all UEs on all EPC-Es.
>

Right.

cheers,
--satoru

---

From: Behcet Sarikaya <[email-masked]>
Date: Thu, 17 Apr 2014 16:57:04 -0500

Hi Satoru,

I have a question about vEPC.

As the UE moves around its default router changes. Which node is the
default router? EPC-E?

Regards,

Behcet

On Tue, Apr 1, 2014 at 10:07 PM, Satoru Matsushima <
[email-masked]> wrote:

> Partitioned by region sounds like that each regional network is isolated
> so that they has no connectivity between them.
> In my mind, that sounds like when an operator assign a prefix to a PDN,
> the operator can divide the prefix into several longer prefixes. Each
> divided prefix, let's say "sub-PDN prefix", may be allocated to a region,
> or any other operator's partition policy. It doesn't need to be assign a
> whole PDN prefix to a partition, or "slice" you said.
>
>
>
>>
> _______________________________________________
> dmm mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dmm
>
>

---

From: Satoru Matsushima <[email-masked]>
Date: Sat, 19 Apr 2014 12:58:42 +0900

Hi Behcet,

Yes, EPC-E routers should be default router for UEs. If I understand the
background of your question correctly, you think an UE session is moved
from an EPC-E router from another while moving around. It should be true
because the UE sending packets are routed most closest node of the anycast
tunnel.

The assumption here is the c-plane will guide the UE session to connect an
appropriate EPC-E routers set which preserve the UE route and shares the
anycast address. That sounds like UEs are always in the area where it
wouldn't require eNB to changing remote end-point of the tunnel.

cheers,
--satoru

On Fri, Apr 18, 2014 at 6:57 AM, Behcet Sarikaya <[email-masked]>wrote:

>>> >>      You seem to attempt to address this issue in Section 4.1 when
>>> you talk
>>> >>       It seems to me that each "set" of EPC-E could cover no more
>>> than the
>>> >> amount of state as an SGW. Essentially       you have described how
>>> to build
>>> >>      core network to react to the closure of a BGP TCP session).  So
>>> I think
>>> >>      sets of EPC-E.  In fact this would mean that all EPC-E
>>> throughout the
>>> >> network, even