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

From: Behcet Sarikaya <[email-masked]>
Date: Thu, 8 May 2014 16:25:19 -0500

Hi Matsushima-san,

I have some other questions on your draft.

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?

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?

For the uplink traffic from UE, you seem to assume that it is always
towards RTR. Could it not be directed to another UE? What happens in that
case?

You say that
EPC-E supports the user
      plane functions of SGW and PGW.

So there is no PGW in your design, I mean no anchor PGW?

What happens to the control plane functions of SGW and PGW? Where are they?

Regards,

Behcet

---

From: Satoru Matsushima <[email-masked]>
Date: Tue, 20 May 2014 15:06:26 +0900

Hi Behcet,

Sorry for my late response. Let me try to answer to your questions.

> 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

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

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. Step 14 makes EPC-E not to
detect mobility directly.

> For the uplink traffic from UE, you seem to assume that it is always
towards RTR. Could it not be directed to
> another UE? What happens in that case?

When an EPC-E router has a route for destination of the packet from UE, the
EPC-E router forward the packet to the destination. Otherwise, the packet
would be forwarded along with routing table of the router.

> So there is no PGW in your design, I mean no anchor PGW?

Yes, there're no entities of PGW and SGW in terms of user-plane. Also in
the routing point of view, since a cluster of EPC-Es share same UE routes
set, each of them can be an anchor.

> What happens to the control plane functions of SGW and PGW? Where are
they?

In terms of control-plane, they are expected to exist in the vEPC. You can
see another benefit for that in section 4.2 of the draft.

cheers,
--satoru

On Fri, May 9, 2014 at 6:25 AM, Behcet Sarikaya <[email-masked]>wrote:

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

---

From: Behcet Sarikaya <[email-masked]>
Date: Tue, 20 May 2014 11:17:31 -0500

Hi Satoru,

Thanks for your reply.
My further comments are inline.

Regards,

Behcet

> router is the receiving node of routing update

You mean more than one node can initiate it, my question was which node(s)?

> routing operation within operator's network.

You mean host routes are not needed in the upstream BGP routers? How
does that work?

>Step 14 makes EPC-E not to

I understand that.

> EPC-E router forward the packet to the destination.

You mean to another EPC-E?

> Otherwise, the packet
> Yes, there're no entities of PGW and SGW in terms of user-plane. Also in the
> routing point of view, since a cluster of EPC-Es share same UE routes set,
> each of them can be an anchor.
>

---

From: Satoru Matsushima <[email-masked]>
Date: Wed, 21 May 2014 10:47:03 +0900

Hi Behcet,

On Wed, May 21, 2014 at 1:17 AM, Behcet Sarikaya <[email-masked]>wrote:
-- snip --

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

> You mean host routes are not needed in the upstream BGP routers? How

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.

> You mean to another EPC-E?
I just meant that the packets are always forwarded along with the routing
table of each node.

cheers,
--satoru

---

From: Behcet Sarikaya <[email-masked]>
Date: Wed, 21 May 2014 10:58:20 -0500

Hi Satoru,

Thanks again.

Please see my replies inline.

Regards,

Behcet

On Tue, May 20, 2014 at 8:47 PM, Satoru Matsushima
<[email-masked]> wrote:
> 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

Are you sure?
How would RR or RS know about UE mobility?

I was expecting you to say MME?

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

> I just meant that the packets are always forwarded along with the routing

Yes, I think that the packet to another UE would be routed downstream
before reaching the RTR.

---

From: Satoru Matsushima <[email-masked]>
Date: Thu, 22 May 2014 11:49:27 +0900

Hi Behcet,

On Thu, May 22, 2014 at 12:58 AM, Behcet Sarikaya <[email-masked]>wrote:
-- snip --

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

> 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

---

From: Behcet Sarikaya <[email-masked]>
Date: Thu, 22 May 2014 14:15:59 -0500

On Wed, May 21, 2014 at 9:49 PM, Satoru Matsushima
<[email-masked]> wrote:
> 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.
>

So MME should be BGP speaker?
If not then what would happen?

> Is that the assigned prefixes are disordered to be aggregated?

Yes. UE moves to another EPC-E which supports a different prefix than UE has?
You need to keep host-based prefixes as routes, is there another way?

Regards,

Behcet

---

From: Satoru Matsushima <[email-masked]>
Date: Fri, 23 May 2014 17:39:20 +0900

Behcet, thanks for clarifying more clearly. :)

On Fri, May 23, 2014 at 4:15 AM, Behcet Sarikaya <[email-masked]>wrote:
-- snip --

> plays
Precisely, say MME, which 3GPP defined mobility management entity, doesn't
have the BGP function. IMO, If the entity can be coexist with BGP in a
single node, an interface for exposing/retrieving mobility information
would be required between them.

> You need to keep host-based prefixes as routes, is there another way?
In the draft, as long as an UE keeps same prefix during hand-over among
EPC-E routers, those routers belong to a same group that is expected to
preserve same prefix for the UE. It should be initial attach when the UE is
attached to different EPC-E and assigned different prefix from previous
one. Please read section 3.3 and 3.4 of the draft.

cheers,
--satoru

---

From: Behcet Sarikaya <[email-masked]>
Date: Fri, 23 May 2014 11:23:36 -0500

Hi Satoru,

It seems most issues are resolved, except one below.

Regards,

Behcet

On Fri, May 23, 2014 at 3:39 AM, Satoru Matsushima
<[email-masked]> wrote:
> single node, an interface for exposing/retrieving mobility information would
> be required between them.
>
>
>>
> attached to different EPC-E and assigned different prefix from previous one.
> Please read section 3.3 and 3.4 of the draft.
>

Attach is OK but I am talking about handover. In Section 3.4 you say:
Thus, UE's address
   is unchanged even after handover.

I don't understand your statement
those routers belong to a same group that is expected to
 preserve same prefix for the UE.

I think you mentioned this before in another conversation that EPC-E's
will be assigned prefixes based on geographical division. If a UE
moves to a different region, how could the routers preserve the same
prefix for the UE without host routes or host prefixes?

Regards,

Behcet

---

From: Satoru Matsushima <[email-masked]>
Date: Tue, 27 May 2014 11:27:28 +0900

Hi Behcet,

On Sat, May 24, 2014 at 1:23 AM, Behcet Sarikaya <[email-masked]>wrote:
-- snip --

> one.
That's true geographical prefix could be a type of operation policy, but it
doesn't mean connectivity within the access and core network are also
divided geographically. If connectivity is also divided by the area, the UE
prefix must be re-assinged when the handover across the area. But that's an
operation matter.

If it's not, which is my thought, the EPC-E routers that belong to one
group can be reachable from eNBs during UE handover,  the control-plane
doesn't need to change the tunnel endpoint address. Since that address is
an anycast address shared among the EPC-Es, all packets come from UE are
continuously forwarded to same EPC-E group. So the UE can keep same prefix.

cheers,
--satoru