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

Behcet Sarikaya <[email protected]>
Newsgroups gmane.ietf.nemo
Message-ID <CAC8QAcewzM6YLu5t+XhUQwpmjCZNMRoNbNdQ_ekOhtgqHHaiNA__47682.8148625374$1400687947$gmane$org@mail.gmail.com>
Hi Satoru,

Thanks again.

Please see my replies inline.

Regards,

Behcet

On Tue, May 20, 2014 at 8:47 PM, Satoru Matsushima
<[email protected]> wrote:
> Hi Behcet,
>
>
> On Wed, May 21, 2014 at 1:17 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?

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

>
>>
>>
>> >Step 14 makes EPC-E not to
>> > detect mobility directly.
>>
>> I understand that.
>>
>> >
>> >> 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.
>>
>> You mean to another EPC-E?
>>
>
> I just meant that the packets are always forwarded along with the routing
> table of each node.
>

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

> cheers,
> --satoru
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.