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

From: Peter McCann <[email-masked]>
Date: Fri, 28 Mar 2014 18:32:50 +0000

Ryuji,

After viewing your slides from the presentation you did overnight (sorry I couldn't
be on the call) I went back and re-read the draft-matushima-stateless-uplane-vepc-02
draft.  I am still confused about a number of things:

You show in Figure 4, step 15 a Route Update (is this a BGP UPDATE?) going from the
EPC-E to the core network RTR, containing a Destination of UE-prefix and a Next-Hop
of EPC-E address.  However, in Section 3.4, you describe the RTR as knowing only the
PDN prefix, which is the same for all EPC-E, and the use of "hot-potato" routing to
deliver the packets to the nearest EPC-E no matter the UE destination IP address.

Which one is it?  Are the UE prefixes advertised into the core or not?

Assuming for now that the UE prefixes are not advertised into the core, but only the
PDN prefixes are advertised, then that means that every EPC-E must know about every
UE session, including the eNB F-TEID for every UE in the network, correct?  That's
because any one of them at any time could receive a packet for the UE from the core.
This doesn't seem scalable to me.

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.  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.

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.

--
Peter J. McCann
Huawei Technologies (USA)
[email-masked]
+1 908 541 3563
Rm. C-0105, 400 Crossings Blvd. (2nd floor), Bridgewater, NJ  08807-2863  USA

---

From: Satoru Matsushima <[email-masked]>
Date: Mon, 31 Mar 2014 19:25:50 +0900

Hi Peter,

> draft.  I am still confused about a number of things:

Thanks. Let me try to answer your questions.

> Which one is it?  Are the UE prefixes advertised into the core or not?

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.

> UE session, including the eNB F-TEID for every UE in the network, correct?

Yes, it's correct.

>  That's because any one of them at any time could receive a packet for the
> UE from the core.

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.,

> "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.

>  It seems to me that each "set" of EPC-E could cover no more than the
> scope covered by a single

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?

> and so they ALL would need the eNB F-TEIDs for ALL UEs.  Please tell me

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.

cheers,
--satoru

---

From: Peter McCann <[email-masked]>
Date: Mon, 31 Mar 2014 13:18:50 +0000

Hi, Satoru,

Thanks for the answers - I think I understand better now.  Let me
just confirm a few points below...

Satoru Matsushima wrote:
>> 	After viewing your slides from the presentation you did overnight
>> (sorry I couldn't 	be on the call) I went back and re-read the
>> draft-matushima- stateless-uplane-vepc-02 	draft.  I am still confused
>> about a number of things:
> 
> 
> 
>> 	EPC-E to the core network RTR, containing a Destination of UE- prefix
>> and a Next-Hop
> No, it isn't meant that specific routes to indicate each UEs prefix
> are advertised into the core.

Yes please clarify because the current text seems to say that UE prefixes
are advertised into the core.

> 
> 
> 
>> 	Assuming for now that the UE prefixes are not advertised into the core,
>> but only the 	PDN prefixes are advertised, then that means that every
>> EPC-E must know about every 	UE session, including the eNB F-TEID for
>> every UE in the network, correct?
> 
> 
> Yes, it's correct.
> 
> 
>> 	 That's because any one of them at any time could receive a packet
>> for the UE from the core.
> 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).

>> 	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.

>> 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?
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.

> 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.

-Pete