Re: [DMM] Questions on draft-matsushima-stateless-uplane-vepc-02
Behcet, thanks for clarifying more clearly. :) On Fri, May 23, 2014 at 4:15 AM, Behcet Sarikaya sarikaya2...@gmail.comwrote: -- snip -- 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? 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. 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? 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 ___ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm
Re: [DMM] Questions on draft-matsushima-stateless-uplane-vepc-02
Hi Satoru, Thanks again. Please see my replies inline. Regards, Behcet On Tue, May 20, 2014 at 8:47 PM, Satoru Matsushima satoru.matsush...@gmail.com wrote: Hi Behcet, On Wed, May 21, 2014 at 1:17 AM, Behcet Sarikaya sarikaya2...@gmail.com 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 ___ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm
Re: [DMM] Questions on draft-matsushima-stateless-uplane-vepc-02
Hi Satoru, Thanks for your reply. My further comments are inline. Regards, Behcet On Tue, May 20, 2014 at 1:06 AM, Satoru Matsushima satoru.matsush...@gmail.com wrote: 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 You mean more than one node can initiate it, my question was which node(s)? 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? 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? Otherwise, the packet would be forwarded along with routing table of the router. 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? 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 sarikaya2...@gmail.com wrote: 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 ___ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm
Re: [DMM] Questions on draft-matsushima-stateless-uplane-vepc-02
Hi Behcet, Yes, EPC-E routers should be default router for UEs. If I understand the background of your question correctly, you think an UE session is moved from an EPC-E router from another while moving around. It should be true because the UE sending packets are routed most closest node of the anycast tunnel. The assumption here is the c-plane will guide the UE session to connect an appropriate EPC-E routers set which preserve the UE route and shares the anycast address. That sounds like UEs are always in the area where it wouldn't require eNB to changing remote end-point of the tunnel. cheers, --satoru On Fri, Apr 18, 2014 at 6:57 AM, Behcet Sarikaya sarikaya2...@gmail.comwrote: Hi Satoru, I have a question about vEPC. As the UE moves around its default router changes. Which node is the default router? EPC-E? Regards, Behcet On Tue, Apr 1, 2014 at 10:07 PM, Satoru Matsushima satoru.matsush...@gmail.com wrote: Peter, On Mon, Mar 31, 2014 at 10:18 PM, Peter McCann peter.mcc...@huawei.comwrote: --snip-- No, it isn't meant that specific routes to indicate each UEs prefix are advertised into the core. I'll try to improve that text in next revision of the draft. Yes please clarify because the current text seems to say that UE prefixes are advertised into the core. Yes, thanks. I agree with you if a EPC-E has whole UE specific routes that exceed its capacity, it doesn't scale, yes. In the recent presentation through the webex, Ryuji were trying to explain that it's not intended to do. Routes contained in EPC-E will be limited/partitioned by operators policy, such as region, service, population scale, etc., I was a bit confused by the suggestion to partition by region, because there would be no mobility across regions if you partitioned in this way. That's because different regions would use different PDN prefixes. But, I suppose it would be ok to do this if you didn't need to support UE mobility across regions (or if you used OTT mobility such as client MIP for those cases). Partitioned by region sounds like that each regional network is isolated so that they has no connectivity between them. But it is not what I meant. Although a PDN prefix would be partitioned by region, the networks doesn't really need to be isolated. For example, when all EPC-E routers have connectivity to reach all RAN nodes, it makes easy to provide mobility across regions. Do you think that describing in the draft this kind of networking concept would be helpful to make things clear? You seem to attempt to address this issue in Section 4.1 when you talk about multiple sets of EPC-E devices, each one dedicated to a given geographic region. Ah, no. Sec 4.1 is intended to explain just scalability issue, and how to deal that issues with routing techniques in operation. Ok, I guess in the most common case you would have several slices of EPC-E, each set serving a different PDN prefix and a different set of UEs. There would be one EPC-E from each slice, each representing a partition of the PDN prefixes, at each EPC-E deployment site between eNBs and core. A given UE's current location would need to be BGP UPDATEd to each of the EPC-E in the slice that covered that UE's PDN prefix. In my mind, that sounds like when an operator assign a prefix to a PDN, the operator can divide the prefix into several longer prefixes. Each divided prefix, let's say sub-PDN prefix, may be allocated to a region, or any other operator's partition policy. It doesn't need to be assign a whole PDN prefix to a partition, or slice you said. It seems to me that each set of EPC-E could cover no more than the scope covered by a singleSGW today, because they each have the same amount of state as an SGW. Essentially you have described how to build a replicated SGW with failover to different nodesbased on the re-convergence of BGP after a failure (presumably you could get the core network to react to the closure of a BGP TCP session). So I think this addresses the problem of fault-tolerance that has been identified with the tunnel-based solutions, but not really the scalability bottleneck problem. The nature of BGP makes easy to do that. I think Sec 3.4 would be right place to explain that. But I couldn't see that flavor of text in sec 4.1. Would you point which text in Sec 4.1 makes you confuse? It was the text in the penultimate paragraph that talked about partitioning by region. If you do that, there is no mobility across regions, right? As I mentioned before, mobility across regions is available. But if you partition by PDN prefix (sets of UEs) then you can have a whole stack of EPC-E at each deployment site, covering the entire population of UEs. In fact, if you consider mobility from one set to another, if you want to keep the UE's IP address,
Re: [DMM] Questions on draft-matsushima-stateless-uplane-vepc-02
Hi Satoru, I have a question about vEPC. As the UE moves around its default router changes. Which node is the default router? EPC-E? Regards, Behcet On Tue, Apr 1, 2014 at 10:07 PM, Satoru Matsushima satoru.matsush...@gmail.com wrote: Peter, On Mon, Mar 31, 2014 at 10:18 PM, Peter McCann peter.mcc...@huawei.comwrote: --snip-- No, it isn't meant that specific routes to indicate each UEs prefix are advertised into the core. I'll try to improve that text in next revision of the draft. Yes please clarify because the current text seems to say that UE prefixes are advertised into the core. Yes, thanks. I agree with you if a EPC-E has whole UE specific routes that exceed its capacity, it doesn't scale, yes. In the recent presentation through the webex, Ryuji were trying to explain that it's not intended to do. Routes contained in EPC-E will be limited/partitioned by operators policy, such as region, service, population scale, etc., I was a bit confused by the suggestion to partition by region, because there would be no mobility across regions if you partitioned in this way. That's because different regions would use different PDN prefixes. But, I suppose it would be ok to do this if you didn't need to support UE mobility across regions (or if you used OTT mobility such as client MIP for those cases). Partitioned by region sounds like that each regional network is isolated so that they has no connectivity between them. But it is not what I meant. Although a PDN prefix would be partitioned by region, the networks doesn't really need to be isolated. For example, when all EPC-E routers have connectivity to reach all RAN nodes, it makes easy to provide mobility across regions. Do you think that describing in the draft this kind of networking concept would be helpful to make things clear? You seem to attempt to address this issue in Section 4.1 when you talk about multiple sets of EPC-E devices, each one dedicated to a given geographic region. Ah, no. Sec 4.1 is intended to explain just scalability issue, and how to deal that issues with routing techniques in operation. Ok, I guess in the most common case you would have several slices of EPC-E, each set serving a different PDN prefix and a different set of UEs. There would be one EPC-E from each slice, each representing a partition of the PDN prefixes, at each EPC-E deployment site between eNBs and core. A given UE's current location would need to be BGP UPDATEd to each of the EPC-E in the slice that covered that UE's PDN prefix. In my mind, that sounds like when an operator assign a prefix to a PDN, the operator can divide the prefix into several longer prefixes. Each divided prefix, let's say sub-PDN prefix, may be allocated to a region, or any other operator's partition policy. It doesn't need to be assign a whole PDN prefix to a partition, or slice you said. It seems to me that each set of EPC-E could cover no more than the scope covered by a singleSGW today, because they each have the same amount of state as an SGW. Essentially you have described how to build a replicated SGW with failover to different nodesbased on the re-convergence of BGP after a failure (presumably you could get the core network to react to the closure of a BGP TCP session). So I think this addresses the problem of fault-tolerance that has been identified with the tunnel-based solutions, but not really the scalability bottleneck problem. The nature of BGP makes easy to do that. I think Sec 3.4 would be right place to explain that. But I couldn't see that flavor of text in sec 4.1. Would you point which text in Sec 4.1 makes you confuse? It was the text in the penultimate paragraph that talked about partitioning by region. If you do that, there is no mobility across regions, right? As I mentioned before, mobility across regions is available. But if you partition by PDN prefix (sets of UEs) then you can have a whole stack of EPC-E at each deployment site, covering the entire population of UEs. In fact, if you consider mobility from one set to another, if you want to keep the UE's IP address, you would need to broadcast the same set of PDN prefixes from all sets of EPC-E. In fact this would mean that all EPC-E throughout the network, even if they are in different sets, need to be prepared to handle packets for any UE and so they ALL would need the eNB F-TEIDs for ALL UEs. Please tell me where I have made a mistake. No, an EPC-E just only receives packets from v6 core network toward UEs that routes installed into EPC-E. Because of that an EPC-E should advertise aggregated routes only for that includes its downstream UEs. When the EPC-E advertises whole routes to the core as you explained, yes I agree with you that won't be scalable. But it
Re: [DMM] Questions on draft-matsushima-stateless-uplane-vepc-02
Hi Peter, On Sat, Mar 29, 2014 at 3:32 AM, Peter McCann peter.mcc...@huawei.comwrote: Ryuji, After viewing your slides from the presentation you did overnight (sorry I couldn't be on the call) I went back and re-read the draft-matushima-stateless-uplane-vepc-02 draft. I am still confused about a number of things: Thanks. Let me try to answer your questions. You show in Figure 4, step 15 a Route Update (is this a BGP UPDATE?) going from the EPC-E to the core network RTR, containing a Destination of UE-prefix and a Next-Hop of EPC-E address. However, in Section 3.4, you describe the RTR as knowing only the PDN prefix, which is the same for all EPC-E, and the use of hot-potato routing to deliver the packets to the nearest EPC-E no matter the UE destination IP address. Which one is it? Are the UE prefixes advertised into the core or not? No, it isn't meant that specific routes to indicate each UEs prefix are advertised into the core. I'll try to improve that text in next revision of the draft. Assuming for now that the UE prefixes are not advertised into the core, but only the PDN prefixes are advertised, then that means that every EPC-E must know about every UE session, including the eNB F-TEID for every UE in the network, correct? Yes, it's correct. That's because any one of them at any time could receive a packet for the UE from the core. This doesn't seem scalable to me. I agree with you if a EPC-E has whole UE specific routes that exceed its capacity, it doesn't scale, yes. In the recent presentation through the webex, Ryuji were trying to explain that it's not intended to do. Routes contained in EPC-E will be limited/partitioned by operators policy, such as region, service, population scale, etc., You seem to attempt to address this issue in Section 4.1 when you talk about multiple sets of EPC-E devices, each one dedicated to a given geographic region. Ah, no. Sec 4.1 is intended to explain just scalability issue, and how to deal that issues with routing techniques in operation. It seems to me that each set of EPC-E could cover no more than the scope covered by a single SGW today, because they each have the same amount of state as an SGW. Essentially you have described how to build a replicated SGW with failover to different nodes based on the re-convergence of BGP after a failure (presumably you could get the core network to react to the closure of a BGP TCP session). So I think this addresses the problem of fault-tolerance that has been identified with the tunnel-based solutions, but not really the scalability bottleneck problem. The nature of BGP makes easy to do that. I think Sec 3.4 would be right place to explain that. But I couldn't see that flavor of text in sec 4.1. Would you point which text in Sec 4.1 makes you confuse? In fact, if you consider mobility from one set to another, if you want to keep the UE's IP address, you would need to broadcast the same set of PDN prefixes from all sets of EPC-E. In fact this would mean that all EPC-E throughout the network, even if they are in different sets, need to be prepared to handle packets for any UE and so they ALL would need the eNB F-TEIDs for ALL UEs. Please tell me where I have made a mistake. No, an EPC-E just only receives packets from v6 core network toward UEs that routes installed into EPC-E. Because of that an EPC-E should advertise aggregated routes only for that includes its downstream UEs. When the EPC-E advertises whole routes to the core as you explained, yes I agree with you that won't be scalable. But it would depend on EPC-E capacity and size of UE population in the network. cheers, --satoru ___ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm
Re: [DMM] Questions on draft-matsushima-stateless-uplane-vepc-02
Hi, Satoru, Thanks for the answers - I think I understand better now. Let me just confirm a few points below... Satoru Matsushima wrote: Hi Peter, On Sat, Mar 29, 2014 at 3:32 AM, Peter McCann peter.mcc...@huawei.com wrote: Ryuji, After viewing your slides from the presentation you did overnight (sorry I couldn'tbe on the call) I went back and re-read the draft-matushima- stateless-uplane-vepc-02draft. I am still confused about a number of things: Thanks. Let me try to answer your questions. You show in Figure 4, step 15 a Route Update (is this a BGP UPDATE?) going from the EPC-E to the core network RTR, containing a Destination of UE- prefix and a Next-Hop of EPC-E address. However, in Section 3.4, you describe the RTR as knowing only the PDN prefix, which is the same for all EPC-E, and the use of hot- potato routing to deliver the packets to the nearest EPC-E no matter the UE destination IP address. Which one is it? Are the UE prefixes advertised into the core or not? No, it isn't meant that specific routes to indicate each UEs prefix are advertised into the core. I'll try to improve that text in next revision of the draft. Yes please clarify because the current text seems to say that UE prefixes are advertised into the core. Assuming for now that the UE prefixes are not advertised into the core, but only the PDN prefixes are advertised, then that means that every EPC-E must know about every UE session, including the eNB F-TEID for every UE in the network, correct? Yes, it's correct. That's because any one of them at any time could receive a packet for the UE from the core. This doesn't seem scalable to me. I agree with you if a EPC-E has whole UE specific routes that exceed its capacity, it doesn't scale, yes. In the recent presentation through the webex, Ryuji were trying to explain that it's not intended to do. Routes contained in EPC-E will be limited/partitioned by operators policy, such as region, service, population scale, etc., I was a bit confused by the suggestion to partition by region, because there would be no mobility across regions if you partitioned in this way. That's because different regions would use different PDN prefixes. But, I suppose it would be ok to do this if you didn't need to support UE mobility across regions (or if you used OTT mobility such as client MIP for those cases). You seem to attempt to address this issue in Section 4.1 when you talk about multiple sets of EPC-E devices, each one dedicated to a given geographic region. Ah, no. Sec 4.1 is intended to explain just scalability issue, and how to deal that issues with routing techniques in operation. Ok, I guess in the most common case you would have several slices of EPC-E, each set serving a different PDN prefix and a different set of UEs. There would be one EPC-E from each slice, each representing a partition of the PDN prefixes, at each EPC-E deployment site between eNBs and core. A given UE's current location would need to be BGP UPDATEd to each of the EPC-E in the slice that covered that UE's PDN prefix. It seems to me that each set of EPC-E could cover no more than the scope covered by a singleSGW today, because they each have the same amount of state as an SGW. Essentially you have described how to build a replicated SGW with failover to different nodesbased on the re-convergence of BGP after a failure (presumably you could get the core network to react to the closure of a BGP TCP session). So I think this addresses the problem of fault-tolerance that has been identified with the tunnel-based solutions, but not really the scalability bottleneck problem. The nature of BGP makes easy to do that. I think Sec 3.4 would be right place to explain that. But I couldn't see that flavor of text in sec 4.1. Would you point which text in Sec 4.1 makes you confuse? It was the text in the penultimate paragraph that talked about partitioning by region. If you do that, there is no mobility across regions, right? But if you partition by PDN prefix (sets of UEs) then you can have a whole stack of EPC-E at each deployment site, covering the entire population of UEs. In fact, if you consider mobility from one set to another, if you want to keep the UE's IP address, you would need to broadcast the same set of PDN prefixes from all sets of EPC-E. In fact this would mean that all EPC-E throughout the network, even if they are in different sets, need to be prepared to handle packets for any UE and so they ALL would need the eNB F-TEIDs for ALL UEs. Please tell me where I have made a mistake. No, an EPC-E just only receives packets from v6 core network toward UEs that routes installed into EPC-E. Because of that an EPC-E should advertise
