Re: [DMM] 答复: Re: comments on draft-ietf-dmm-requirements-02
On Nov 20, 2012, at 9:03 AM, luo@zte.com.cn wrote: [snip] |I would need to implement the mobility stack whatever support function |anyway even if none of my application care about it. If you are absolutely sure that none of your apps needs mobility support, and none will ever need it in the future, then there's no reason to implement it, sure. But if there's a chance one app may need it and 100 won't, then perhaps you get to implement it. The difference is that, if you do implement that mobility stack, with conditional support you run that code for one app only (and route the respective packets accordingly), while with today's approach you do the same for 101 apps. Fair reasoning. However, what is the mobility stack here then? Is it something we today understand as a MIP enabled stack or could it be something more generic? What I mean here is that we should be very cautious with MN side impacts not to freak out less mobility cautious people. If the mobility stack could be beneficial also outside mobility use cases that would be awesome. [Luowen] Hi Jouni, what do you mean What I mean here is that we should be very cautious with MN side impacts not to freak out less mobility cautious people ? The applicaions on the mobile node doesn't need to understand what is the mobility (i.e. the I mean the below the applications that any random developer can do support.. i.e. middleware, vendor APIs, OS IP stack level things etc. For example, if the mobility stack needs to hook deep inside the IP stack, it basically has to be part of the platform level baseline software to be successful. If the mobility stack is something that just requires higher privileges (like installing a driver) than a consumer has, then operators enterprises can distribute required software at will. - Jouni application developer doesn't need to understand), and it seems to let an ordinary user to understand the mobilty concept is impossible. As per my understanding, the application only care to bind to an IP@ which can survive longer than itself. ___ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm
Re: [DMM] Requirements on cmm
Behcet, On Nov 19, 2012, at 10:41 PM, Behcet Sarikaya wrote: Hi Brian, On Mon, Nov 19, 2012 at 1:53 PM, Brian Haberman br...@innovationslab.net wrote: Behcet, On 11/19/12 12:25 PM, Behcet Sarikaya wrote: Hi all, Here is the requirement I have in mind: The DMM solution SHOULD support more than one cloud network belonging to the same DMM domain. Two points: The above requirement does have protocol impact. Could you elaborate on what that impact would be? It is unclear to me what the impact of using a cloud service would be. The IETF has not had to change other protocols in order to have them work within the cloud. I think it is early to say. I am confused. If you think it is too early to say, then how can you claim cloud has an impact? If there is something concrete you have in mind, just say it. - Jouni Cloud networks have been all Layer 2 based and because of that many mobility issues do not surface. For example virtual machine mobility is just change of Ethernet address and no IP layer changes are needed. However, I think that the trend is towards Layer 3 based clouds and also inter-cloud communication needs are increasing. For example there are many people advocating the development of an IETF virtual machine mobility protocol. I think we need to look at DMM from this perspective,and see if we can make our mobility protocols more suitable to the cloud. That is the reason why I wrote draft-sarikaya-dmm-cloud-mm. With even the simplistic assumptions, my drafts shows that the cloud does have some protocol implications on our protocols. Regards, Behcet ___ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm ___ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm
Re: [DMM] Comments on draft-liebsch-dmm-framework-analysis-00
Hi Pete, please see inline. Sorry for the delay in continuing the discussion. -Original Message- From: Peter McCann [mailto:peter.mcc...@huawei.com] Sent: Donnerstag, 8. November 2012 19:43 To: Marco Liebsch; dmm@ietf.org Subject: RE: Comments on draft-liebsch-dmm-framework-analysis-00 Hi, Marco, Thanks for the response. See below. Marco Liebsch wrote: Hi Pete, please see inline for my response. -Original Message- From: dmm-boun...@ietf.org [mailto:dmm-boun...@ietf.org] On Behalf Of Peter McCann Sent: Mittwoch, 7. November 2012 20:41 To: dmm@ietf.org Subject: [DMM] Comments on draft-liebsch-dmm-framework-analysis-00 Let me ask a question to make sure I understand the approach this document takes to analyzing the problem space. In the Introduction, you state: The initial version of this draft introduces a basic set of FEs and interfaces between these FEs to support IP address continuity in DMM, without being specific to the used mobility management protocol, which operates below the mobility anchor. And later, you introduce the FE_MA to represent this mobility anchor. I *think* you are trying to define DMM as something that runs above another mobility management protocol. That would imply a solution and that is not intended. The four defined DMM FEs can be mapped to components of existing protocols. My intention is to define DMM FEs, which enable DMM use cases but are not dependent on a mobility protocol. So, some functions can be applied to existing components of, say, iBGP in a route reflector, or a LISP resolver. But some components can be placed on a Mobile IP Home Agent or even a Mobile Node. Then we can analyze if the function of the DMM FE is implicitly supported by the existing protocol or if an extension is needed. That's the rationale behind these FEs. The FE_MA is mentioned as existing component and assumed as topological anchor of the MN's IP address. Some or all DMM FEs may apply to the existing MA. Depends on the analysis we want to perform. Ok I understand that you want to put some of your components in the existing mobility anchor (and at least the FE_MA would be there) but you also seem to be distinguishing between a DMM protocol that runs *above* the FE_MA and another mobility protocol that runs *below* the FE_MA. Is that a correct interpretation? The draft is not a solution, but a functional framework. As you write, some functions can be placed on an existing mobility anchor (which may be even co-located with an access router). Typically, the Egress Function is at the MN's topological anchor after anchor relocation. To analyze if a mobility protocol supports one or more of the required functions to enable DMM implicitly, some of the other identified DMM functional entities could be placed on the mobility anchor, or even on a MAG or a MN in case of host mobility. See, this is solely for the analysis. But also for the identification and specification of extensions. If we place the FE_IEC to an iBGP router, maybe the defined DMM function is implicitly supported by the iBGP protocol. That's the rationale behind the framework. And that was my intention to allow enabling DMM with support from non-mobility protocols, e.g. being deployed in the transport network. This can be in your example iBGP, or MPLS or OpenFlow. Would it be legal to set the FE_MA equal to the access router, and the other mobility management protocol to NULL? That is, would it be allowed in your framework to use *only* the DMM protocol to get packets to an AR, to which the MN is currently attached? Yes, legal from my perspective :-) Good. It seems to me that designating the leaf node in your architecture as containing FE_MA is confusing because there may in fact be no mobility protocol running between FE_MA and AR (they may be one and the same entity). Yes, then it's local IPC of a function call ;-) FE_MA is just a general naming of the MN's topological anchor or, maybe better, point of attachment. The DMM framework simply assumes that packets arriving at that point of attachment can be forwarded to the MN without any help of the functional entities of the DMM framework. If this is the Access Router or a Base Station, that requirement is met. Section 3 states: Imported HoA/HNP of a mobile node will be treated as identifier and non-routable IP address (prefix), as it probably does not match the new mobility anchor's location in the topology. I disagree. The old address (prefix) will need to be routable at least inside the new anchor point. If this anchor point is directly connected to the MN (i.e., it is the AR) then the route will be to a local link address. If this new anchor point uses a tunnel to get the packets to the MN, then the old address will be routable to the tunnel interface. The assumption is of course that below a mobility anchor (FE_MA) the mobility protocol performs location tracking and tunnel
Re: [DMM] Comments on draft-liebsch-dmm-framework-analysis-00
..small correction in the figure below: Packets should arrive at the FE_E of the iBGP router, then the next hop state is checked, then packets are transmitted via FE_I. So please swap FE_I and FE_E in the figure. marco -Original Message- From: dmm-boun...@ietf.org [mailto:dmm-boun...@ietf.org] On Behalf Of Marco Liebsch Sent: Dienstag, 20. November 2012 10:59 To: Peter McCann; dmm@ietf.org Subject: Re: [DMM] Comments on draft-liebsch-dmm-framework-analysis-00 Hi Pete, please see inline. Sorry for the delay in continuing the discussion. -Original Message- From: Peter McCann [mailto:peter.mcc...@huawei.com] Sent: Donnerstag, 8. November 2012 19:43 To: Marco Liebsch; dmm@ietf.org Subject: RE: Comments on draft-liebsch-dmm-framework-analysis-00 Hi, Marco, Thanks for the response. See below. Marco Liebsch wrote: Hi Pete, please see inline for my response. -Original Message- From: dmm-boun...@ietf.org [mailto:dmm-boun...@ietf.org] On Behalf Of Peter McCann Sent: Mittwoch, 7. November 2012 20:41 To: dmm@ietf.org Subject: [DMM] Comments on draft-liebsch-dmm-framework-analysis-00 Let me ask a question to make sure I understand the approach this document takes to analyzing the problem space. In the Introduction, you state: The initial version of this draft introduces a basic set of FEs and interfaces between these FEs to support IP address continuity in DMM, without being specific to the used mobility management protocol, which operates below the mobility anchor. And later, you introduce the FE_MA to represent this mobility anchor. I *think* you are trying to define DMM as something that runs above another mobility management protocol. That would imply a solution and that is not intended. The four defined DMM FEs can be mapped to components of existing protocols. My intention is to define DMM FEs, which enable DMM use cases but are not dependent on a mobility protocol. So, some functions can be applied to existing components of, say, iBGP in a route reflector, or a LISP resolver. But some components can be placed on a Mobile IP Home Agent or even a Mobile Node. Then we can analyze if the function of the DMM FE is implicitly supported by the existing protocol or if an extension is needed. That's the rationale behind these FEs. The FE_MA is mentioned as existing component and assumed as topological anchor of the MN's IP address. Some or all DMM FEs may apply to the existing MA. Depends on the analysis we want to perform. Ok I understand that you want to put some of your components in the existing mobility anchor (and at least the FE_MA would be there) but you also seem to be distinguishing between a DMM protocol that runs *above* the FE_MA and another mobility protocol that runs *below* the FE_MA. Is that a correct interpretation? The draft is not a solution, but a functional framework. As you write, some functions can be placed on an existing mobility anchor (which may be even co- located with an access router). Typically, the Egress Function is at the MN's topological anchor after anchor relocation. To analyze if a mobility protocol supports one or more of the required functions to enable DMM implicitly, some of the other identified DMM functional entities could be placed on the mobility anchor, or even on a MAG or a MN in case of host mobility. See, this is solely for the analysis. But also for the identification and specification of extensions. If we place the FE_IEC to an iBGP router, maybe the defined DMM function is implicitly supported by the iBGP protocol. That's the rationale behind the framework. And that was my intention to allow enabling DMM with support from non-mobility protocols, e.g. being deployed in the transport network. This can be in your example iBGP, or MPLS or OpenFlow. Would it be legal to set the FE_MA equal to the access router, and the other mobility management protocol to NULL? That is, would it be allowed in your framework to use *only* the DMM protocol to get packets to an AR, to which the MN is currently attached? Yes, legal from my perspective :-) Good. It seems to me that designating the leaf node in your architecture as containing FE_MA is confusing because there may in fact be no mobility protocol running between FE_MA and AR (they may be one and the same entity). Yes, then it's local IPC of a function call ;-) FE_MA is just a general naming of the MN's topological anchor or, maybe better, point of attachment. The DMM framework simply assumes that packets arriving at that point of attachment can be forwarded to the MN without any help of the functional entities of the DMM framework. If this is the Access Router or a Base Station, that requirement is met. Section 3 states: Imported HoA/HNP of a mobile node will be treated as identifier and non-routable IP address (prefix), as it probably does not match the new mobility anchor's location in the topology. I disagree. The
[DMM] Multicast PS to requirements
Let us also use another thread to check for consensus of the PS from multimob. PS1 (revised): Non-optimal routes Routing via a centralized anchor often results in a longer route. The problem is especially manifested when accessing a local server or servers of a Content Delivery Network (CDN), or when receiving / sending IP multicast packets. PS6: Duplicate multicast traffic IP multicast distribution over architectures using IP mobility solutions may lead to convergence of duplicated multicast subscriptions towards the tunnel's downstream entity (e.g. MAG in PMIPv6). Concretely, when multicast subscription for individual mobile nodes is coupled with mobility tunnels, duplicate multicast subscription(s) is prone to be received through different upstream paths. This problem is potentially more severe in a distributed mobility environment [draft-sfigueiredo-multimob-use-case-dmm-03]. H Anthony Chan From: dmm-boun...@ietf.org [mailto:dmm-boun...@ietf.org] On Behalf Of Sérgio Figueiredo Sent: Monday, November 19, 2012 5:24 PM To: dmm@ietf.org Subject: Re: [DMM] Multicast requirements Hi Anthony, Thank you for trying to progress on this matter. I mostly agree with your analysis. As for the question you posed, first I would like to exactly understand what you mean with multicast distribution scenario in DMM solutions should enable multicast services which are compatible with multicast distribution scenario, etc.. It seems like there is no major difference between this and the DMM solutions should enable solutions to support multicast services. requirement? Aren't both expressing the need to enable multicast in a DMM solution? As you stated, neglecting the requirement 7.1 we proposed, leads to the PSs you referred. So, while 7.2 and 7.3 express the need for DMM solutions to allow deployment of multicast services, 7.1 concerns how IP multicast should be enabled in order to avoid the aforementioned PSs. The usage of the word flexibleis explained by: This flexibility enables different IP multicast flows with respect to a mobile host to be managed (e.g., subscribed, received and/or transmitted) using multiple endpoints. In other words, compatibility with multicast distribution scenario doesn't necessarily avoid PS1 and PS6. Thank you and best regards, Sérgio On 11/19/2012 10:28 PM, h chan wrote: There are 3 proposals for multicast requirements. Before comparing these proposals, let us understand what are the problems first. Two problem statements have been proposed: PS1 (revised): Non-optimal routes Routing via a centralized anchor often results in a longer route. The problem is especially manifested when accessing a local server or servers of a Content Delivery Network (CDN), or when receiving / sending IP multicast packets. PS6: Duplicate multicast traffic IP multicast distribution over architectures using IP mobility solutions may lead to convergence of duplicated multicast subscriptions towards the tunnel's downstream entity (e.g. MAG in PMIPv6). Concretely, when multicast subscription for individual mobile nodes is coupled with mobility tunnels, duplicate multicast subscription(s) is prone to be received through different upstream paths. This problem is potentially more severe in a distributed mobility environment [draft-sfigueiredo-multimob-use-case-dmm-03]. Then, let us see whether all the 3 REQ proposals have the same intention. In the following, I rephrase them to highlight their similarities. REQ7.1: Flexible multicast distribution DMM solutions should be compatible with flexible multicast distribution scenario. Etc. The Motivation is to allow flexibility in (enable) multicast solutions to solve the problems PS1 and PS6 as explained in use cases already presented and discussed in multimob wg. REQ7.2: DMM solutions should enable solutions to support multicast traffic. (Original wording was The DMM (unicast) solution MUST be specified in such a way that it can be extended to also support multicast traffic. I rephrase it to highlight the similarity with the other proposals and also changed the must to should.) REQ7.3: DMM solutions should enable solutions to support multicast services. Original wording was DMM solutions should support multicast services ... etc. Given that it is the scope of multimob and not dmm wg to provide the multicast solution, I think support here means enable solutions to be developed (by multimob). Similarity and subtle differences: Both REQ7.2 and REQ7.3 want to enable multicast services. Yet the explanation in REQ7.1 seems to indicate not just to enable any one multicast solution but also needs the flexibility in multicast solution. Not all multicast solutions are the same. Some of them results in PS1 or PS6. Are there any are essential differences between: In REQ7.1, DMM solutions should be compatible with flexible multicast distribution scenario, etc. Versus DMM solutions should enable multicast services
