Re: Questions on draft-matsushima-stateless-uplane-vepc-02

On Wed, May 21, 2014 at 9:49 PM, Satoru Matsushima
<[email protected]> wrote:
> Hi Behcet,
>
>
> On Thu, May 22, 2014 at 12:58 AM, Behcet Sarikaya <[email protected]>
> 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.
>

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

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

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
> cheers,
> --satoru