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 _______________________________________________ dmm mailing list [email protected] https://www.ietf.org/mailman/listinfo/dmm
