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

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.



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

cheers,
--satoru

_______________________________________________
dmm mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/dmm