Re: [DMM] Multicast requirements
So, if we rephrase 7.1 as REQ7.1: Flexible multicast distribution DMM solutions should enable multicast services which are compatible with (flexible?) multicast distribution scenario. Etc. It will have the same intention as REQ7.2 and REQ7.3. Is that right? 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 "flexible"is 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 which are compatible with multicast distribution scenario, etc. H Anthony Chan From: dmm-boun...@ietf.org<mailto:dmm-boun...@ietf.org> [mailto:dmm-boun...@ietf.org] On Behalf Of Seil Jeon Sent: Monday, November 19, 2012 5:15 AM To: pierrick.se...@orange.com<mailto:pierrick.se...@orange.com> Cc: dmm@ietf.org<mailto:dmm@ietf.org> Subject: Re: [DMM] Multicast requirements Hi Pierrick, I've many times thought about your question. I would say how effectively should
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 "flexible"is 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 which are compatible with multicast distribution scenario, etc. H Anthony Chan *From:*dmm-boun...@ietf.org [mailto:dmm-boun...@ietf.org] *On Behalf Of *Seil Jeon *Sent:* Monday, November 19, 2012 5:15 AM *To:* pierrick.se...@orange.com *Cc:* dmm@ietf.org *Subject:* Re: [DMM] Multicast requirements Hi Pierrick, I've many times thought about your question. I would say how effectively should we deploy/support multicast over distributed mobility rather than distributed mobile multicast. As a result, you can find this deployment use case and gap analysis at http://tools.ietf.org/html/draft-sfigueiredo-multimob-use-case-dmm-03 presented in multimob several times. In unicast DMM, main innovation is to distribute the anchor function at many access routers from single core. Following architectural concept of DMM, flexible multicast distribution is one of multicast requirement resulted from the dr
Re: [DMM] Multicast requirements
Hi Pierrick, I’ve many times thought about your question. I would say how effectively should we deploy/support multicast over distributed mobility rather than distributed mobile multicast. As a result, you can find this deployment use case and gap analysis at http://tools.ietf.org/html/draft-sfigueiredo-multimob-use-case-dmm-03 presented in multimob several times. In unicast DMM, main innovation is to distribute the anchor function at many access routers from single core. Following architectural concept of DMM, flexible multicast distribution is one of multicast requirement resulted from the draft described above. REQ8: Flexible multicast distribution "DMM solutions SHOULD be compatible with flexible multicast distribution scenarios. 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". Motivation: The motivation for this requirement is to enable flexibility in multicast distribution. The multicast solution may therefore avoid having multicast-capable access routers being restricted to manage all IP multicast traffic relative to a host via a single endpoint (e.g. regular or tunnel interface), which would lead to the problems described in PS1 and PS6. 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]. Regards, Seil From: pierrick.se...@orange.com [mailto:pierrick.se...@orange.com] Sent: Monday, November 19, 2012 8:55 AM To: 'karag...@cs.utwente.nl'; seilj...@av.it.pt; juancarlos.zun...@interdigital.com Cc: dmm@ietf.org Subject: RE: [DMM] Multicast requirements Hi all, I tend to agree with Georgious, however I still do not figure out what is the use-case for distributed mobile multicast (other than academic considerations)? Can someone give concrete example? I haven’t real all messages from this thread. So, maybe I missed important points. BR, Pierrick De : dmm-boun...@ietf.org [mailto:dmm-boun...@ietf.org] De la part de karag...@cs.utwente.nl Envoyé : samedi 17 novembre 2012 13:01 À : seilj...@av.it.pt; juancarlos.zun...@interdigital.com Cc : dmm@ietf.org Objet : Re: [DMM] Multicast requirements Hi all, I also agree that the DMM solution should somehow consider muticast deployment. However, I do not thnk that the DMM WG is the right WG to provide the multicast based DMM solution! One alternative solution will be to have a multicast requirement that emphasizes the need of having extensibility hooks (possibilities) that can be used later on by the multimob WG to provide a a multicast enabled DMM solution! So a requirement that specifies something like the following could be used for this purpose: "The DMM (unicast) solution MUST be specified in such a way that it can be extended to also support multicast traffic." Best regards, Georgios _ Van: <mailto:dmm-boun...@ietf.org> dmm-boun...@ietf.org [dmm-boun...@ietf.org] namens Seil Jeon [seilj...@av.it.pt] Verzonden: vrijdag 16 november 2012 22:25 To: 'Zuniga, Juan Carlos' Cc: <mailto:dmm@ietf.org> dmm@ietf.org Onderwerp: Re: [DMM] Multicast requirements Hi Juan, I've been looked at changed flow of your proposed text but sorry now that my comment is posted. At first time, I couldn't make sure however, on hearing Stig's description, it seems quite reasonable at the first step, not giving any restrictions but leaving some-specific for the DMM solution it does not support multicast. On the other hand, it remains at a basic stage for the DMM solution to support multicast. So I think additional requirements need to be made for the DMM solution, accordingly. But of course, this should not also give any specific limitation and restriction but should be made towards the direction not limiting the benefits provided by distributed deployment. I hope to get more comments on this. Regards, Seil -Original Message- From: <mailto:dmm-boun...@ietf.org> dmm-boun...@ietf.org [ <mailto:dmm-boun...@ietf.org> mailto:dmm-boun...@ietf.org] On Behalf Of Zuniga, Juan Carlos Sent: Friday, November 16, 2012 8:14 PM To: Stig Venaas; <mailto:dmm@ietf.org> dmm@ietf.org Subject: Re: [DMM] Multicast requirements > -Original Message- > From: Stig Venaas [ <mailto:s...@venaas.com> mailto:s...@venaas.com] > Sent: Friday
Re: [DMM] Multicast requirements
Hi all, I tend to agree with Georgious, however I still do not figure out what is the use-case for distributed mobile multicast (other than academic considerations)? Can someone give concrete example? I haven't real all messages from this thread. So, maybe I missed important points. BR, Pierrick De : dmm-boun...@ietf.org [mailto:dmm-boun...@ietf.org] De la part de karag...@cs.utwente.nl Envoyé : samedi 17 novembre 2012 13:01 À : seilj...@av.it.pt; juancarlos.zun...@interdigital.com Cc : dmm@ietf.org Objet : Re: [DMM] Multicast requirements Hi all, I also agree that the DMM solution should somehow consider muticast deployment. However, I do not thnk that the DMM WG is the right WG to provide the multicast based DMM solution! One alternative solution will be to have a multicast requirement that emphasizes the need of having extensibility hooks (possibilities) that can be used later on by the multimob WG to provide a a multicast enabled DMM solution! So a requirement that specifies something like the following could be used for this purpose: "The DMM (unicast) solution MUST be specified in such a way that it can be extended to also support multicast traffic." Best regards, Georgios Van: dmm-boun...@ietf.org<mailto:dmm-boun...@ietf.org> [dmm-boun...@ietf.org] namens Seil Jeon [seilj...@av.it.pt] Verzonden: vrijdag 16 november 2012 22:25 To: 'Zuniga, Juan Carlos' Cc: dmm@ietf.org<mailto:dmm@ietf.org> Onderwerp: Re: [DMM] Multicast requirements Hi Juan, I've been looked at changed flow of your proposed text but sorry now that my comment is posted. At first time, I couldn't make sure however, on hearing Stig's description, it seems quite reasonable at the first step, not giving any restrictions but leaving some-specific for the DMM solution it does not support multicast. On the other hand, it remains at a basic stage for the DMM solution to support multicast. So I think additional requirements need to be made for the DMM solution, accordingly. But of course, this should not also give any specific limitation and restriction but should be made towards the direction not limiting the benefits provided by distributed deployment. I hope to get more comments on this. Regards, Seil -Original Message- From: dmm-boun...@ietf.org<mailto:dmm-boun...@ietf.org> [mailto:dmm-boun...@ietf.org] On Behalf Of Zuniga, Juan Carlos Sent: Friday, November 16, 2012 8:14 PM To: Stig Venaas; dmm@ietf.org<mailto:dmm@ietf.org> Subject: Re: [DMM] Multicast requirements > -Original Message- > From: Stig Venaas [mailto:s...@venaas.com] > Sent: Friday, November 16, 2012 3:01 PM > To: jouni korhonen > Cc: sarik...@ieee.org<mailto:sarik...@ieee.org>; Zuniga, Juan Carlos; > Konstantinos Pentikousis; > Peter McCann; dmm@ietf.org<mailto:dmm@ietf.org> > Subject: Re: [DMM] Multicast requirements > > On 11/15/2012 3:17 AM, jouni korhonen wrote: > > > > On Nov 15, 2012, at 1:03 AM, Behcet Sarikaya wrote: > > > >> > >> I think we are reading too much into multicast and unicast should be > >> designed in an integrated manner. > >> > >> The fact is that multicast is considered as an area of > specialization, > >> it requires knowledge of very different protocols than we are > >> accustomed to in mobility. > > > > "Requirement: DMM solutions SHOULD support multicast services. If a > specific DMM solution does not support multicast services, an > explanation MUST be provided." > > This sounds good to me. > > The main thing I want to achieve is what was describes as motivation > earlier in this thread. Multicast should at least be considered when > looking into DMM solutions, and not just an afterthought once the > solution is decided. > > Stig [JCZ] I fully agree with this. That was the intention of the proposed text. Regards, Juan Carlos > > > To me that reads basically "do not break foundations for multicast > unless you have a valid & documented reason for it". If we look e.g. > into RFC625 multicast wording that is there very briefly but gives a > hint to a developer where to head to. That is the level I would expect > DMM documents should aim to. > > > > - Jouni > > > > > >> Let dmm deal with its current charter that does not include a word > of > >> multicast and if everything goes well we can come back and discuss > dmm > >> multicast. > >> > >> Regards, > >> > >> Behcet ___ dmm mailing list dmm@ietf.org<mailto:dmm@ietf.org> https://www.ietf.org/mailman/listinfo/dmm ___ dmm mailing l
Re: [DMM] Multicast requirements
Hi all, I also agree that the DMM solution should somehow consider muticast deployment. However, I do not thnk that the DMM WG is the right WG to provide the multicast based DMM solution! One alternative solution will be to have a multicast requirement that emphasizes the need of having extensibility hooks (possibilities) that can be used later on by the multimob WG to provide a a multicast enabled DMM solution! So a requirement that specifies something like the following could be used for this purpose: "The DMM (unicast) solution MUST be specified in such a way that it can be extended to also support multicast traffic." Best regards, Georgios Van: dmm-boun...@ietf.org [dmm-boun...@ietf.org] namens Seil Jeon [seilj...@av.it.pt] Verzonden: vrijdag 16 november 2012 22:25 To: 'Zuniga, Juan Carlos' Cc: dmm@ietf.org Onderwerp: Re: [DMM] Multicast requirements Hi Juan, I've been looked at changed flow of your proposed text but sorry now that my comment is posted. At first time, I couldn't make sure however, on hearing Stig's description, it seems quite reasonable at the first step, not giving any restrictions but leaving some-specific for the DMM solution it does not support multicast. On the other hand, it remains at a basic stage for the DMM solution to support multicast. So I think additional requirements need to be made for the DMM solution, accordingly. But of course, this should not also give any specific limitation and restriction but should be made towards the direction not limiting the benefits provided by distributed deployment. I hope to get more comments on this. Regards, Seil -Original Message- From: dmm-boun...@ietf.org [mailto:dmm-boun...@ietf.org] On Behalf Of Zuniga, Juan Carlos Sent: Friday, November 16, 2012 8:14 PM To: Stig Venaas; dmm@ietf.org Subject: Re: [DMM] Multicast requirements > -Original Message- > From: Stig Venaas [mailto:s...@venaas.com] > Sent: Friday, November 16, 2012 3:01 PM > To: jouni korhonen > Cc: sarik...@ieee.org; Zuniga, Juan Carlos; Konstantinos Pentikousis; > Peter McCann; dmm@ietf.org > Subject: Re: [DMM] Multicast requirements > > On 11/15/2012 3:17 AM, jouni korhonen wrote: > > > > On Nov 15, 2012, at 1:03 AM, Behcet Sarikaya wrote: > > > >> > >> I think we are reading too much into multicast and unicast should be > >> designed in an integrated manner. > >> > >> The fact is that multicast is considered as an area of > specialization, > >> it requires knowledge of very different protocols than we are > >> accustomed to in mobility. > > > > "Requirement: DMM solutions SHOULD support multicast services. If a > specific DMM solution does not support multicast services, an > explanation MUST be provided." > > This sounds good to me. > > The main thing I want to achieve is what was describes as motivation > earlier in this thread. Multicast should at least be considered when > looking into DMM solutions, and not just an afterthought once the > solution is decided. > > Stig [JCZ] I fully agree with this. That was the intention of the proposed text. Regards, Juan Carlos > > > To me that reads basically "do not break foundations for multicast > unless you have a valid & documented reason for it". If we look e.g. > into RFC625 multicast wording that is there very briefly but gives a > hint to a developer where to head to. That is the level I would expect > DMM documents should aim to. > > > > - Jouni > > > > > >> Let dmm deal with its current charter that does not include a word > of > >> multicast and if everything goes well we can come back and discuss > dmm > >> multicast. > >> > >> 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 ___ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm
Re: [DMM] Multicast requirements
Hi Juan, I've been looked at changed flow of your proposed text but sorry now that my comment is posted. At first time, I couldn't make sure however, on hearing Stig's description, it seems quite reasonable at the first step, not giving any restrictions but leaving some-specific for the DMM solution it does not support multicast. On the other hand, it remains at a basic stage for the DMM solution to support multicast. So I think additional requirements need to be made for the DMM solution, accordingly. But of course, this should not also give any specific limitation and restriction but should be made towards the direction not limiting the benefits provided by distributed deployment. I hope to get more comments on this. Regards, Seil -Original Message- From: dmm-boun...@ietf.org [mailto:dmm-boun...@ietf.org] On Behalf Of Zuniga, Juan Carlos Sent: Friday, November 16, 2012 8:14 PM To: Stig Venaas; dmm@ietf.org Subject: Re: [DMM] Multicast requirements > -Original Message- > From: Stig Venaas [mailto:s...@venaas.com] > Sent: Friday, November 16, 2012 3:01 PM > To: jouni korhonen > Cc: sarik...@ieee.org; Zuniga, Juan Carlos; Konstantinos Pentikousis; > Peter McCann; dmm@ietf.org > Subject: Re: [DMM] Multicast requirements > > On 11/15/2012 3:17 AM, jouni korhonen wrote: > > > > On Nov 15, 2012, at 1:03 AM, Behcet Sarikaya wrote: > > > >> > >> I think we are reading too much into multicast and unicast should be > >> designed in an integrated manner. > >> > >> The fact is that multicast is considered as an area of > specialization, > >> it requires knowledge of very different protocols than we are > >> accustomed to in mobility. > > > > "Requirement: DMM solutions SHOULD support multicast services. If a > specific DMM solution does not support multicast services, an > explanation MUST be provided." > > This sounds good to me. > > The main thing I want to achieve is what was describes as motivation > earlier in this thread. Multicast should at least be considered when > looking into DMM solutions, and not just an afterthought once the > solution is decided. > > Stig [JCZ] I fully agree with this. That was the intention of the proposed text. Regards, Juan Carlos > > > To me that reads basically "do not break foundations for multicast > unless you have a valid & documented reason for it". If we look e.g. > into RFC625 multicast wording that is there very briefly but gives a > hint to a developer where to head to. That is the level I would expect > DMM documents should aim to. > > > > - Jouni > > > > > >> Let dmm deal with its current charter that does not include a word > of > >> multicast and if everything goes well we can come back and discuss > dmm > >> multicast. > >> > >> 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] Multicast requirements
> -Original Message- > From: Stig Venaas [mailto:s...@venaas.com] > Sent: Friday, November 16, 2012 3:01 PM > To: jouni korhonen > Cc: sarik...@ieee.org; Zuniga, Juan Carlos; Konstantinos Pentikousis; > Peter McCann; dmm@ietf.org > Subject: Re: [DMM] Multicast requirements > > On 11/15/2012 3:17 AM, jouni korhonen wrote: > > > > On Nov 15, 2012, at 1:03 AM, Behcet Sarikaya wrote: > > > >> > >> I think we are reading too much into multicast and unicast should be > >> designed in an integrated manner. > >> > >> The fact is that multicast is considered as an area of > specialization, > >> it requires knowledge of very different protocols than we are > >> accustomed to in mobility. > > > > "Requirement: DMM solutions SHOULD support multicast services. If a > specific DMM solution does not support multicast services, an > explanation MUST be provided." > > This sounds good to me. > > The main thing I want to achieve is what was describes as motivation > earlier in this thread. Multicast should at least be considered when > looking into DMM solutions, and not just an afterthought once the > solution is decided. > > Stig [JCZ] I fully agree with this. That was the intention of the proposed text. Regards, Juan Carlos > > > To me that reads basically "do not break foundations for multicast > unless you have a valid & documented reason for it". If we look e.g. > into RFC625 multicast wording that is there very briefly but gives a > hint to a developer where to head to. That is the level I would expect > DMM documents should aim to. > > > > - Jouni > > > > > >> Let dmm deal with its current charter that does not include a word > of > >> multicast and if everything goes well we can come back and discuss > dmm > >> multicast. > >> > >> Regards, > >> > >> Behcet ___ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm
Re: [DMM] Multicast requirements
On 11/15/2012 3:17 AM, jouni korhonen wrote: On Nov 15, 2012, at 1:03 AM, Behcet Sarikaya wrote: I think we are reading too much into multicast and unicast should be designed in an integrated manner. The fact is that multicast is considered as an area of specialization, it requires knowledge of very different protocols than we are accustomed to in mobility. "Requirement: DMM solutions SHOULD support multicast services. If a specific DMM solution does not support multicast services, an explanation MUST be provided." This sounds good to me. The main thing I want to achieve is what was describes as motivation earlier in this thread. Multicast should at least be considered when looking into DMM solutions, and not just an afterthought once the solution is decided. Stig To me that reads basically "do not break foundations for multicast unless you have a valid & documented reason for it". If we look e.g. into RFC625 multicast wording that is there very briefly but gives a hint to a developer where to head to. That is the level I would expect DMM documents should aim to. - Jouni Let dmm deal with its current charter that does not include a word of multicast and if everything goes well we can come back and discuss dmm multicast. Regards, Behcet ___ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm
Re: [DMM] Multicast requirements
Dear all, As requested we have been working on a proposal for updating current DMM Requirements draft, reflecting the work developed in "draft-sfigueiredo-multimob-use-case-dmm-03.txt". We were careful to follow the expressed concerns, mainly by not impacting the current (mostly accepted) draft structure and content. As such, we propose the following 2 changes: # Proposal 1 - small update to PS1 # PS1: Non-optimal routesRouting 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 using IP multicasting*. # Proposal 2 - Add a new requirement# REQ8: Flexible multicast distribution "DMM solutions SHOULD be compatible with flexible multicast distribution scenarios. 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". Motivation: The motivation for this requirement is to enable flexibility in multicast distribution. The multicast solution may therefore avoid having multicast-capable access routers being restricted to manage all IP multicast traffic relative to a host via a single endpoint (e.g. regular or tunnel interface), which would lead to the problems described in PS1 and PS6. 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]. Best regards, Sérgio & Seil On 11/12/2012 10:49 PM, Seil Jeon wrote: Hi Pete, That might be one of them we can take on DMM. Imagine, depending on deployment of existing IP multicasting standard entities, we can think of various use cases as presented in http://tools.ietf.org/html/draft-sfigueiredo-multimob-use-case-dmm-03. Direct routing cannot be applied in every scenario. After I came back from the trip, we (me and Sergio) have been working on this with priority. After carefully reviewing the requirement from the use cases, we'll announce it soon. Regards, Seil -Original Message- From: dmm-boun...@ietf.org [mailto:dmm-boun...@ietf.org] On Behalf Of Peter McCann Sent: Monday, November 12, 2012 9:53 PM To: Thomas C. Schmidt Cc: Stig Venaas; Behcet Sarikaya; dmm@ietf.org Subject: Re: [DMM] Multicast requirements In the DMM case my assumption is that the anchor points are closer to the access routers and therefore are very likely to be in the same administrative domain. In these cases, joining the multicast group directly from the access router gives you the same access to the same multicast streams and so tunneling the multicast packets won't be necessary. -Pete Thomas C. Schmidt wrote: Dear Pete, multicast mobility management is a route adaptation problem. As in the unicast case, mobility can only be treated by routing dynamics in trivial cases (re-connect of a tunnel, re-association with next hop). Otherwise it is unwise to delegate mobility adaptation to routing protocols (-> OSPF, BGP ...). Accordingly, if DMM distributes mobility operations, handover management should foresee easy interconnects to previous distribution trees - both for receivers and for mobile multicast sources. I guess, if DMM people are careful, this is not a world-class item and can be treated along the lines of unicast solutions - an isolated multicast protocol treatment (as has been previously proposed from MULTIMOB folks) seems inappropriate. In core PMIP, multicast treatment has turned out to work out simply (-> RFC6224). Thus my argument: talk to the multicast guys before adopting a solution ... and make the rest an easy game. Cheers, Thomas On 12.11.2012 21:39, Peter McCann wrote: jouni korhonen wrote: Folks, This mail is to kick off the discussion on multicast requirement(s) for the draft-ietf-dmm-requirements-02 document. I hope we can nail down the essential multicast requirement(s) as soon as possible. To me, multicast in a DMM environment means joining multicast groups directly from access routers. It means re-joining the multicast tree from a new access router after handover. I would hope that we can use existing MLD protocols between the MN and its first hop AR to accomplish this. -Pete ___ 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] Multicast requirements
On Nov 15, 2012, at 1:03 AM, Behcet Sarikaya wrote: > > I think we are reading too much into multicast and unicast should be > designed in an integrated manner. > > The fact is that multicast is considered as an area of specialization, > it requires knowledge of very different protocols than we are > accustomed to in mobility. "Requirement: DMM solutions SHOULD support multicast services. If a specific DMM solution does not support multicast services, an explanation MUST be provided." To me that reads basically "do not break foundations for multicast unless you have a valid & documented reason for it". If we look e.g. into RFC625 multicast wording that is there very briefly but gives a hint to a developer where to head to. That is the level I would expect DMM documents should aim to. - Jouni > Let dmm deal with its current charter that does not include a word of > multicast and if everything goes well we can come back and discuss dmm > multicast. > > Regards, > > Behcet ___ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm
Re: [DMM] Multicast requirements
Dear Pete, multicast mobility management is a route adaptation problem. As in the unicast case, mobility can only be treated by routing dynamics in trivial cases (re-connect of a tunnel, re-association with next hop). Otherwise it is unwise to delegate mobility adaptation to routing protocols (-> OSPF, BGP ...). Accordingly, if DMM distributes mobility operations, handover management should foresee easy interconnects to previous distribution trees - both for receivers and for mobile multicast sources. I guess, if DMM people are careful, this is not a world-class item and can be treated along the lines of unicast solutions - an isolated multicast protocol treatment (as has been previously proposed from MULTIMOB folks) seems inappropriate. In core PMIP, multicast treatment has turned out to work out simply (-> RFC6224). Thus my argument: talk to the multicast guys before adopting a solution ... and make the rest an easy game. Cheers, Thomas On 12.11.2012 21:39, Peter McCann wrote: jouni korhonen wrote: Folks, This mail is to kick off the discussion on multicast requirement(s) for the draft-ietf-dmm-requirements-02 document. I hope we can nail down the essential multicast requirement(s) as soon as possible. To me, multicast in a DMM environment means joining multicast groups directly from access routers. It means re-joining the multicast tree from a new access router after handover. I would hope that we can use existing MLD protocols between the MN and its first hop AR to accomplish this. -Pete ___ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm -- Prof. Dr. Thomas C. Schmidt ° Hamburg University of Applied Sciences Berliner Tor 7 ° ° Dept. Informatik, Internet Technologies Group20099 Hamburg, Germany ° ° http://www.haw-hamburg.de/inet Fon: +49-40-42875-8452 ° ° http://www.informatik.haw-hamburg.de/~schmidtFax: +49-40-42875-8409 ° ___ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm
Re: [DMM] Multicast requirements
> [JCZ] I also agree with explicitly covering multicast. Implicitly > covering it has not been good enough, as this is what triggered this > whole discussion. Explicitly covering it does not seem to be harmful > either. > The amended text by Kostas seems good to me and I think that we can move > forward with it. Hence, I support including that text in the WG > requirements draft. Disagree. Such requirements state nothing new, and are useless. How are we going to judge on somebody's multicast solution by looking at this requirement? If we include this requirement then we should also have a requirement saying that fast handover should supported. If we have a requirement saying that fast handover should be supported then we should also have a requirement saying that even faster handover should be supported. I think we are reading too much into multicast and unicast should be designed in an integrated manner. The fact is that multicast is considered as an area of specialization, it requires knowledge of very different protocols than we are accustomed to in mobility. Let dmm deal with its current charter that does not include a word of multicast and if everything goes well we can come back and discuss dmm multicast. Regards, Behcet ___ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm
Re: [DMM] Multicast requirements
Hi, > -Original Message- > From: dmm-boun...@ietf.org [mailto:dmm-boun...@ietf.org] On Behalf Of > Konstantinos Pentikousis > Sent: Wednesday, November 14, 2012 12:21 PM > To: sarik...@ieee.org; jouni korhonen > Cc: Stig Venaas; Behcet Sarikaya; Peter McCann; dmm@ietf.org > Subject: Re: [DMM] Multicast requirements > > Hi Behcet > > |As you know, Costas has changed his view "thinking wider". > > I didn't change my view :) Maybe it was not so clearly explained, > apologies for that. I think that it does not harm to have a separate > "REQ no. 7" addressing multicast along the lines previously mentioned > in the mailing list. However, if drafting such a REQ delays our > progress in the WG wrt the -reqs draft, the best practices/gap analysis > work or, even worse, going after concrete DMM solutions in a speedy > manner, it makes more sense to tweak some of the existing requirements > text so we can accommodate the requirement for multicast support. After > all, the current DMM chapter does not explicitly mention "multicast". > > > |If existing requirements are covering what we want, as it seems with > |REQ 3/4/5, why not go with them? > > I agree, but it's reasonable, since the point was brought up, to > explicitly cover multicast (one way or another, see above) in the -reqs > draft. [JCZ] I also agree with explicitly covering multicast. Implicitly covering it has not been good enough, as this is what triggered this whole discussion. Explicitly covering it does not seem to be harmful either. The amended text by Kostas seems good to me and I think that we can move forward with it. Hence, I support including that text in the WG requirements draft. Regards, JC > > Best Regards, > > Kostas > > > > ___ > 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] Multicast requirements
Hi Behcet |As you know, Costas has changed his view "thinking wider". I didn't change my view :) Maybe it was not so clearly explained, apologies for that. I think that it does not harm to have a separate "REQ no. 7" addressing multicast along the lines previously mentioned in the mailing list. However, if drafting such a REQ delays our progress in the WG wrt the -reqs draft, the best practices/gap analysis work or, even worse, going after concrete DMM solutions in a speedy manner, it makes more sense to tweak some of the existing requirements text so we can accommodate the requirement for multicast support. After all, the current DMM chapter does not explicitly mention "multicast". |If existing requirements are covering what we want, as it seems with |REQ 3/4/5, why not go with them? I agree, but it's reasonable, since the point was brought up, to explicitly cover multicast (one way or another, see above) in the -reqs draft. Best Regards, Kostas ___ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm
Re: [DMM] Multicast requirements
Behcet, On Nov 14, 2012, at 4:35 AM, Behcet Sarikaya wrote: > Hi Jouni, > >>> Requirement: DMM solutions SHOULD support multicast services. > > So here it is a should. It seems so. >>> If a specific DMM solution does not support multicast services, an >>> explanation MUST be provided. > > Why is it a must here? So that one provides a proper justification why the solution chose to leverage the former SHOULD and left multicast support unattended. That makes sense to me. > My comment on this requirement is in mobility area, we have never had > these types of requirements. > > For example PMIPv6 was developed with no multicast support. I doubt it was intentional. RFC6224 did a good job clarifying the operation of a MAG as a MLD proxy later on. > MIPv6 and PMIPv6 were developed with no fast handover support. MIPSHOP > WG worked on handover extensions to these protocols. > > As you know, Costas has changed his view "thinking wider". I'll let him speak for himself. > If we look back to the beginning of this discussion, i.e. Multimob > meeting in Atlanta and Seil's presentation, we, at least myself, were > mislead. In that presentation at > http://www.ietf.org/proceedings/85/slides/slides-85-multimob-6.pptx > > We thought that he had a multicast requirement and a reasonable > suggestion was to take it to dmm. However, if you look at his slide 6, > he does have a requirement there but it is REQ1 from the DMM > requirements draft :-). > > If existing requirements are covering what we want, as it seems with > REQ 3/4/5, why not go with them? Perhaps we should have learned what happened with PMIPv6. The assumption was that multicast would work over it just fine, which was at the end not quite true. Thus a specific requirement reminding us about that should be ok. If that multicast specific note boils down to a clarification to an existing requirement, it is ok. I just don't think we are there yet to jump into that conclusion. So, coming back to the proposal from JC & Kostas. There was a concrete text proposal. If someone thinks the multicast requirement can be part of existing requirements; propose text. - Jouni > > Regards, > > Behcet ___ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm
Re: [DMM] Multicast requirements
Hi Jouni, >> Requirement: DMM solutions SHOULD support multicast services. So here it is a should. >> If a specific DMM solution does not support multicast services, an >> explanation MUST be provided. Why is it a must here? My comment on this requirement is in mobility area, we have never had these types of requirements. For example PMIPv6 was developed with no multicast support. MIPv6 and PMIPv6 were developed with no fast handover support. MIPSHOP WG worked on handover extensions to these protocols. As you know, Costas has changed his view "thinking wider". If we look back to the beginning of this discussion, i.e. Multimob meeting in Atlanta and Seil's presentation, we, at least myself, were mislead. In that presentation at http://www.ietf.org/proceedings/85/slides/slides-85-multimob-6.pptx We thought that he had a multicast requirement and a reasonable suggestion was to take it to dmm. However, if you look at his slide 6, he does have a requirement there but it is REQ1 from the DMM requirements draft :-). If existing requirements are covering what we want, as it seems with REQ 3/4/5, why not go with them? Regards, Behcet ___ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm
Re: [DMM] Multicast requirements
On Nov 13, 2012, at 4:49 PM, Konstantinos Pentikousis wrote: > Hi Juan Carlos, all, > > |Requirement: DMM solutions SHOULD support multicast services. In case > |the solution does not address multicast, a justification MUST be provided > |for the omission of multicast from the solution. > > I like this proposal. It appears to me to capture the essence of the request > to cover multicast in DMM. I would make it even shorter however: > > Requirement: DMM solutions SHOULD support multicast services. If a specific > DMM solution does not support multicast services, an explanation MUST be > provided. Sounds ok to me. > |Motivation: The purpose of this requirement is to encourage people to > |consider the impacts of running multicast services in a DMM environment > |from the beginning of the development, thereby avoiding the need to > |make protocol extensions in the future to support this kind of > functionality. > > I second the motivation part, although I would also rephrase it a bit: > > Motivation: From an operational perspective, if a network domain provides > multicast services already, the deployment of a DMM solution should not > impede the delivery of such services. From a protocol perspective, a DMM > solution should aim to address unicast as well as multicast in a coherent > manner, thus avoiding the recurrence of "multicast add-ons", as is the case > with today's mobility management solutions. Ack. - Jouni > > Best Regards, > > Kostas > > > ___ > 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] Multicast requirements
> And, to be honest, if I just "think wider", REQ3, 4, and 5 (IPv6, existing > mobility protocols, and compatibility) should be sufficient to cover > "multicast support". I copy-paste from the respective motivation sections: > "DMM solutions SHOULD target IPv6 as the primary deployment environment." > [..] "A DMM solution SHOULD first consider reusing and extending > IETF-standardized protocols before specifying new protocols." I think these > two would in general cover also stuff developed in multimob. And, as if this > is not sufficient, then REQ5 should close this discussion: "The DMM solution > MUST be able to co-exist with existing network deployments and end hosts." > Therefore, if you already have multicast services in your domain, the DMM > solution should handle them. > > Now, we did agree in Atlanta to have a quick resolution wrt to multicast, and > perhaps explicitly add "REQ7: Multicast support", if the multimob folks can > deal with this in an expedient manner. If not, imo, REQs 3/4/5 should more > than suffice to cover "multicast support in DMM". > I agree. Existing requirements do cover what we need. Regards, Behcet ___ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm
Re: [DMM] Multicast requirements
Hi Thomas, all, |Thus my argument: talk to the multicast guys before adopting a |solution... and make the rest an easy game. Somehow I got the feeling that it was the "multicast guys" who wanted to partake in DMM, not the other way around. Therefore, the challenge is on those guys to come up with a coherent DMM requirement and motivation text, in line with the rest of the draft, proportional to the significance of the matter and with respect to the other 6 REQs. There is already a proposal by Juan Carlos or, if you will, the one I edited, on the floor. Please feel free to propose specific changes, keeping in mind that the current average number of words for each of the requirements is 48 (min: REQ4 with 15 words; max: REQ5 with 79 words). Best Regards, Kostas ___ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm
Re: [DMM] Multicast requirements
Hi, |I can tell you that in Multimob meeting in Atlanta, we have not |discussed any requirements. Indeed. I was at the multicast meeting in Atlanta, well, the better part of it, and I do not recall any excitement about working on the requirements for multicast support in DMM. On the contrary, as I'm sure the minutes will reflect, the discussion went on about "current issues" in mulitmob drafts. Multicast is very important. Moving forward with the work in DMM is also very important. I hope we do not stall the progress on DMM requirements till Orlando... Best Regards, Kostas ___ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm
Re: [DMM] Multicast requirements
Hi Sergio, all, |Although the motivation is clear, this seems as a light requirement to |be achieved, in the sense that it can be easily transposed. Do you |have in mind what is a valid "justification" for not addressing multicast? I think we already discussed this in Atlanta. Multicast support should not become yet-another-reason to delay DMM solutions, let alone the requirements document. And, to be honest, if I just "think wider", REQ3, 4, and 5 (IPv6, existing mobility protocols, and compatibility) should be sufficient to cover "multicast support". I copy-paste from the respective motivation sections: "DMM solutions SHOULD target IPv6 as the primary deployment environment." [..] "A DMM solution SHOULD first consider reusing and extending IETF-standardized protocols before specifying new protocols." I think these two would in general cover also stuff developed in multimob. And, as if this is not sufficient, then REQ5 should close this discussion: "The DMM solution MUST be able to co-exist with existing network deployments and end hosts." Therefore, if you already have multicast services in your domain, the DMM solution should handle them. Now, we did agree in Atlanta to have a quick resolution wrt to multicast, and perhaps explicitly add "REQ7: Multicast support", if the multimob folks can deal with this in an expedient manner. If not, imo, REQs 3/4/5 should more than suffice to cover "multicast support in DMM". Best Regards, Kostas ___ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm
Re: [DMM] Multicast requirements
Hi Juan Carlos, all, |Requirement: DMM solutions SHOULD support multicast services. In case |the solution does not address multicast, a justification MUST be provided |for the omission of multicast from the solution. I like this proposal. It appears to me to capture the essence of the request to cover multicast in DMM. I would make it even shorter however: Requirement: DMM solutions SHOULD support multicast services. If a specific DMM solution does not support multicast services, an explanation MUST be provided. |Motivation: The purpose of this requirement is to encourage people to |consider the impacts of running multicast services in a DMM environment |from the beginning of the development, thereby avoiding the need to |make protocol extensions in the future to support this kind of functionality. I second the motivation part, although I would also rephrase it a bit: Motivation: From an operational perspective, if a network domain provides multicast services already, the deployment of a DMM solution should not impede the delivery of such services. From a protocol perspective, a DMM solution should aim to address unicast as well as multicast in a coherent manner, thus avoiding the recurrence of "multicast add-ons", as is the case with today's mobility management solutions. Best Regards, Kostas ___ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm
Re: [DMM] Multicast requirements
Hi Sergio, I wasn't implying that you were proposing a solution. I just meant that using the word module was perhaps not appropriate for drafting the requirement. Having said that, if you believe there is some wording to that we can propose to reflect your thinking in a clear requirement, please suggest it. Regards, Juan Carlos > -Original Message- > From: Sérgio Figueiredo [mailto:sfigueir...@av.it.pt] > Sent: Monday, November 12, 2012 6:46 PM > To: Zuniga, Juan Carlos > Cc: dmm@ietf.org > Subject: Re: [DMM] Multicast requirements > > Hi Juan Carlos, > > Don't get me wrong. Although I use the word "module" I'm not referring > to solution details. What I was referring to was to the optional > deployment of (at least) multicast discovery / routing protocols, which > this requirement keeps as is if I understood it correctly. > > Cheers, > Sérgio > > On 11/12/2012 11:20 PM, Zuniga, Juan Carlos wrote: > > Hi Sergio, > > > >> -Original Message- > >> From: dmm-boun...@ietf.org [mailto:dmm-boun...@ietf.org] On Behalf > Of > >> Sérgio Figueiredo > >> Sent: Monday, November 12, 2012 6:10 PM > >> To: dmm@ietf.org > >> Subject: Re: [DMM] Multicast requirements > >> > >> Hi Juan Carlos, > >> > >> On 11/12/2012 10:51 PM, Zuniga, Juan Carlos wrote: > >>> I believe the purpose of the discussion was to propose some > >> requirement > >>> text for draft-ietf-dmm-requirements, rather than getting in the > >>> solution space. > >> We're inline here. > > [JCZ] Good. We don't have time much time for religious battles, so > better to propose text soon and get the requirements finalized. > >>> I propose the following: > >>> > >>> > >>> Requirement: DMM solutions SHOULD support multicast services. In > case > >>> the solution > >>> does not address multicast, a justification MUST be > >> provided > >>> for the > >>> omission of multicast from the solution. > >>> > >>> Motivation: The purpose of this requirement is to encourage people > to > >>> consider the impacts of running multicast services in a > >> DMM > >>> environment > >>> from the beginning of the development, thereby avoiding > >> the > >>> need to > >>> make protocol extensions in the future to support this > >> kind of > >>> functionality. > >> This requirement paves the way for the ones I'm reviewing with Seil, > >> and > >> keeps IP multicast position, i.e. as a "module" that may or not be > >> included by operators. > >> > > [JCZ] I agree. However, talking about "modules" seems to me getting > into the solution space, which should not be done in the requirements. > >> Although the motivation is clear, this seems as a light requirement > to > >> be achieved, in the sense that it can be easily transposed. Do you > have > >> in mind what is a valid "justification" for not addressing > multicast? > >> > > [JCZ] I don't have one and I believe it is up to the solution > proponents to write one in case they do not support multicast. If they > do, a justification would not be needed. The reason for using SHOULD is > to allow for people that believe this is not needed to still bring > their proposals forward, but giving the reasoning why they believe this > is not needed. > > > > Regards, > > > > Juan Carlos > >> BR, > >> Sérgio > >>> Regards, > >>> > >>> Juan Carlos > >>> > >>>> -Original Message- > >>>> From: dmm-boun...@ietf.org [mailto:dmm-boun...@ietf.org] On Behalf > >> Of > >>>> Thomas C. Schmidt > >>>> Sent: Monday, November 12, 2012 5:06 PM > >>>> To: Peter McCann > >>>> Cc: Stig Venaas; Behcet Sarikaya; dmm@ietf.org > >>>> Subject: Re: [DMM] Multicast requirements > >>>> > >>>> Hi Pete, > >>>> > >>>> things would be simple, if topology were as described. > >>>> > >>>> Let's wait what dmm is birthing out ... and continue discussion > >> then. > >>>> In > >>>> any case, complex and incompatible "grand new schemes" do not > appear > >>> to > >>>>
Re: [DMM] Multicast requirements
Hi Juan Carlos, Don't get me wrong. Although I use the word "module" I'm not referring to solution details. What I was referring to was to the optional deployment of (at least) multicast discovery / routing protocols, which this requirement keeps as is if I understood it correctly. Cheers, Sérgio On 11/12/2012 11:20 PM, Zuniga, Juan Carlos wrote: Hi Sergio, -Original Message- From: dmm-boun...@ietf.org [mailto:dmm-boun...@ietf.org] On Behalf Of Sérgio Figueiredo Sent: Monday, November 12, 2012 6:10 PM To: dmm@ietf.org Subject: Re: [DMM] Multicast requirements Hi Juan Carlos, On 11/12/2012 10:51 PM, Zuniga, Juan Carlos wrote: I believe the purpose of the discussion was to propose some requirement text for draft-ietf-dmm-requirements, rather than getting in the solution space. We're inline here. [JCZ] Good. We don't have time much time for religious battles, so better to propose text soon and get the requirements finalized. I propose the following: Requirement: DMM solutions SHOULD support multicast services. In case the solution does not address multicast, a justification MUST be provided for the omission of multicast from the solution. Motivation: The purpose of this requirement is to encourage people to consider the impacts of running multicast services in a DMM environment from the beginning of the development, thereby avoiding the need to make protocol extensions in the future to support this kind of functionality. This requirement paves the way for the ones I'm reviewing with Seil, and keeps IP multicast position, i.e. as a "module" that may or not be included by operators. [JCZ] I agree. However, talking about "modules" seems to me getting into the solution space, which should not be done in the requirements. Although the motivation is clear, this seems as a light requirement to be achieved, in the sense that it can be easily transposed. Do you have in mind what is a valid "justification" for not addressing multicast? [JCZ] I don't have one and I believe it is up to the solution proponents to write one in case they do not support multicast. If they do, a justification would not be needed. The reason for using SHOULD is to allow for people that believe this is not needed to still bring their proposals forward, but giving the reasoning why they believe this is not needed. Regards, Juan Carlos BR, Sérgio Regards, Juan Carlos -Original Message- From: dmm-boun...@ietf.org [mailto:dmm-boun...@ietf.org] On Behalf Of Thomas C. Schmidt Sent: Monday, November 12, 2012 5:06 PM To: Peter McCann Cc: Stig Venaas; Behcet Sarikaya; dmm@ietf.org Subject: Re: [DMM] Multicast requirements Hi Pete, things would be simple, if topology were as described. Let's wait what dmm is birthing out ... and continue discussion then. In any case, complex and incompatible "grand new schemes" do not appear to make much sense. Cheers, Thomas On 12.11.2012 22:53, Peter McCann wrote: In the DMM case my assumption is that the anchor points are closer to the access routers and therefore are very likely to be in the same administrative domain. In these cases, joining the multicast group directly from the access router gives you the same access to the same multicast streams and so tunneling the multicast packets won't be necessary. -Pete Thomas C. Schmidt wrote: Dear Pete, multicast mobility management is a route adaptation problem. As in the unicast case, mobility can only be treated by routing dynamics in trivial cases (re-connect of a tunnel, re-association with next hop). Otherwise it is unwise to delegate mobility adaptation to routing protocols (-> OSPF, BGP ...). Accordingly, if DMM distributes mobility operations, handover management should foresee easy interconnects to previous distribution trees - both for receivers and for mobile multicast sources. I guess, if DMM people are careful, this is not a world-class item and can be treated along the lines of unicast solutions - an isolated multicast protocol treatment (as has been previously proposed from MULTIMOB folks) seems inappropriate. In core PMIP, multicast treatment has turned out to work out simply (-> RFC6224). Thus my argument: talk to the multicast guys before adopting a solution ... and make the rest an easy game. Cheers, Thomas On 12.11.2012 21:39, Peter McCann wrote: jouni korhonen wrote: Folks, This mail is to kick off the discussion on multicast requirement(s) for the draft-ietf-dmm-requirements-02 document. I hope we can nail down the essential multicast requirement(s) as soon as possible. To me, multicast in a DMM environment means joining multicast groups directly from access routers. It means re-joining the multicast tree from a new access router after handover. I would hope that we
Re: [DMM] Multicast requirements
Hi Juan Carlos, On Mon, Nov 12, 2012 at 4:51 PM, Zuniga, Juan Carlos wrote: > I believe the purpose of the discussion was to propose some requirement > text for draft-ietf-dmm-requirements, rather than getting in the > solution space. I propose the following: > Absolutely, let's not lose time on this. > Requirement: DMM solutions SHOULD support multicast services. In case > the solution > does not address multicast, a justification MUST be provided > for the > omission of multicast from the solution. OK. Justification could be out of scope. > > Motivation: The purpose of this requirement is to encourage people to > consider the impacts of running multicast services in a DMM > environment > from the beginning of the development, thereby avoiding the > need to > make protocol extensions in the future to support this kind of > functionality. > Agreed. Regards, Behcet ___ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm
Re: [DMM] Multicast requirements
Hi Sergio, > -Original Message- > From: dmm-boun...@ietf.org [mailto:dmm-boun...@ietf.org] On Behalf Of > Sérgio Figueiredo > Sent: Monday, November 12, 2012 6:10 PM > To: dmm@ietf.org > Subject: Re: [DMM] Multicast requirements > > Hi Juan Carlos, > > On 11/12/2012 10:51 PM, Zuniga, Juan Carlos wrote: > > I believe the purpose of the discussion was to propose some > requirement > > text for draft-ietf-dmm-requirements, rather than getting in the > > solution space. > We're inline here. [JCZ] Good. We don't have time much time for religious battles, so better to propose text soon and get the requirements finalized. > > > I propose the following: > > > > > > Requirement: DMM solutions SHOULD support multicast services. In case > > the solution > >does not address multicast, a justification MUST be > provided > > for the > >omission of multicast from the solution. > > > > Motivation: The purpose of this requirement is to encourage people to > >consider the impacts of running multicast services in a > DMM > > environment > >from the beginning of the development, thereby avoiding > the > > need to > >make protocol extensions in the future to support this > kind of > >functionality. > This requirement paves the way for the ones I'm reviewing with Seil, > and > keeps IP multicast position, i.e. as a "module" that may or not be > included by operators. > [JCZ] I agree. However, talking about "modules" seems to me getting into the solution space, which should not be done in the requirements. > > Although the motivation is clear, this seems as a light requirement to > be achieved, in the sense that it can be easily transposed. Do you have > in mind what is a valid "justification" for not addressing multicast? > [JCZ] I don't have one and I believe it is up to the solution proponents to write one in case they do not support multicast. If they do, a justification would not be needed. The reason for using SHOULD is to allow for people that believe this is not needed to still bring their proposals forward, but giving the reasoning why they believe this is not needed. Regards, Juan Carlos > > BR, > Sérgio > > > > Regards, > > > > Juan Carlos > > > >> -Original Message- > >> From: dmm-boun...@ietf.org [mailto:dmm-boun...@ietf.org] On Behalf > Of > >> Thomas C. Schmidt > >> Sent: Monday, November 12, 2012 5:06 PM > >> To: Peter McCann > >> Cc: Stig Venaas; Behcet Sarikaya; dmm@ietf.org > >> Subject: Re: [DMM] Multicast requirements > >> > >> Hi Pete, > >> > >> things would be simple, if topology were as described. > >> > >> Let's wait what dmm is birthing out ... and continue discussion > then. > >> In > >> any case, complex and incompatible "grand new schemes" do not appear > > to > >> make much sense. > >> > >> Cheers, > >> > >> Thomas > >> > >> On 12.11.2012 22:53, Peter McCann wrote: > >>> In the DMM case my assumption is that the anchor points are closer > >>> to the access routers and therefore are very likely to be in the > > same > >>> administrative domain. In these cases, joining the multicast group > >>> directly from the access router gives you the same access to the > > same > >>> multicast streams and so tunneling the multicast packets won't be > >>> necessary. > >>> > >>> -Pete > >>> > >>> Thomas C. Schmidt wrote: > >>>> Dear Pete, > >>>> > >>>> multicast mobility management is a route adaptation problem. As in > >> the > >>>> unicast case, mobility can only be treated by routing dynamics in > >>>> trivial cases (re-connect of a tunnel, re-association with next > >> hop). > >>>> Otherwise it is unwise to delegate mobility adaptation to routing > >>>> protocols (-> OSPF, BGP ...). > >>>> > >>>> Accordingly, if DMM distributes mobility operations, handover > >>>> management should foresee easy interconnects to previous > >> distribution > >>>> trees - both for receivers and for mobile multicast sources. > >>>> > >>>> I guess, if DMM people are careful, this is not a world-class item > >> and > >>>> can be treated along the l
Re: [DMM] Multicast requirements
That is right. I had discussed with Seil, and I understand that he will come up with his proposed text soon. H Anthony Chan -Original Message- From: dmm-boun...@ietf.org [mailto:dmm-boun...@ietf.org] On Behalf Of Seil Jeon Sent: Monday, November 12, 2012 4:49 PM To: Peter McCann Cc: 'Stig Venaas'; 'Behcet Sarikaya'; dmm@ietf.org Subject: Re: [DMM] Multicast requirements Hi Pete, That might be one of them we can take on DMM. Imagine, depending on deployment of existing IP multicasting standard entities, we can think of various use cases as presented in http://tools.ietf.org/html/draft-sfigueiredo-multimob-use-case-dmm-03. Direct routing cannot be applied in every scenario. After I came back from the trip, we (me and Sergio) have been working on this with priority. After carefully reviewing the requirement from the use cases, we'll announce it soon. Regards, Seil -Original Message- From: dmm-boun...@ietf.org [mailto:dmm-boun...@ietf.org] On Behalf Of Peter McCann Sent: Monday, November 12, 2012 9:53 PM To: Thomas C. Schmidt Cc: Stig Venaas; Behcet Sarikaya; dmm@ietf.org Subject: Re: [DMM] Multicast requirements In the DMM case my assumption is that the anchor points are closer to the access routers and therefore are very likely to be in the same administrative domain. In these cases, joining the multicast group directly from the access router gives you the same access to the same multicast streams and so tunneling the multicast packets won't be necessary. -Pete Thomas C. Schmidt wrote: > Dear Pete, > > multicast mobility management is a route adaptation problem. As in the > unicast case, mobility can only be treated by routing dynamics in > trivial cases (re-connect of a tunnel, re-association with next hop). > Otherwise it is unwise to delegate mobility adaptation to routing > protocols (-> OSPF, BGP ...). > > Accordingly, if DMM distributes mobility operations, handover > management should foresee easy interconnects to previous distribution > trees - both for receivers and for mobile multicast sources. > > I guess, if DMM people are careful, this is not a world-class item and > can be treated along the lines of unicast solutions - an isolated > multicast protocol treatment (as has been previously proposed from > MULTIMOB folks) seems inappropriate. In core PMIP, multicast treatment > has turned out to work out simply (-> RFC6224). > > Thus my argument: talk to the multicast guys before adopting a > solution ... and make the rest an easy game. > > Cheers, > > Thomas > > On 12.11.2012 21:39, Peter McCann wrote: >> jouni korhonen wrote: >>> Folks, >>> >>> This mail is to kick off the discussion on multicast requirement(s) >>> for the draft-ietf-dmm-requirements-02 document. I hope we can nail >>> down the essential multicast requirement(s) as soon as possible. >> >> To me, multicast in a DMM environment means joining multicast groups >> directly from access routers. It means re-joining the multicast tree >> from a new access router after handover. I would hope that we can >> use existing MLD protocols between the MN and its first hop AR to >> accomplish this. >> >> -Pete >> >> ___ >> 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 ___ 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] Multicast requirements
Hi Juan Carlos, On 11/12/2012 10:51 PM, Zuniga, Juan Carlos wrote: I believe the purpose of the discussion was to propose some requirement text for draft-ietf-dmm-requirements, rather than getting in the solution space. We're inline here. I propose the following: Requirement: DMM solutions SHOULD support multicast services. In case the solution does not address multicast, a justification MUST be provided for the omission of multicast from the solution. Motivation: The purpose of this requirement is to encourage people to consider the impacts of running multicast services in a DMM environment from the beginning of the development, thereby avoiding the need to make protocol extensions in the future to support this kind of functionality. This requirement paves the way for the ones I'm reviewing with Seil, and keeps IP multicast position, i.e. as a "module" that may or not be included by operators. Although the motivation is clear, this seems as a light requirement to be achieved, in the sense that it can be easily transposed. Do you have in mind what is a valid "justification" for not addressing multicast? BR, Sérgio Regards, Juan Carlos -Original Message- From: dmm-boun...@ietf.org [mailto:dmm-boun...@ietf.org] On Behalf Of Thomas C. Schmidt Sent: Monday, November 12, 2012 5:06 PM To: Peter McCann Cc: Stig Venaas; Behcet Sarikaya; dmm@ietf.org Subject: Re: [DMM] Multicast requirements Hi Pete, things would be simple, if topology were as described. Let's wait what dmm is birthing out ... and continue discussion then. In any case, complex and incompatible "grand new schemes" do not appear to make much sense. Cheers, Thomas On 12.11.2012 22:53, Peter McCann wrote: In the DMM case my assumption is that the anchor points are closer to the access routers and therefore are very likely to be in the same administrative domain. In these cases, joining the multicast group directly from the access router gives you the same access to the same multicast streams and so tunneling the multicast packets won't be necessary. -Pete Thomas C. Schmidt wrote: Dear Pete, multicast mobility management is a route adaptation problem. As in the unicast case, mobility can only be treated by routing dynamics in trivial cases (re-connect of a tunnel, re-association with next hop). Otherwise it is unwise to delegate mobility adaptation to routing protocols (-> OSPF, BGP ...). Accordingly, if DMM distributes mobility operations, handover management should foresee easy interconnects to previous distribution trees - both for receivers and for mobile multicast sources. I guess, if DMM people are careful, this is not a world-class item and can be treated along the lines of unicast solutions - an isolated multicast protocol treatment (as has been previously proposed from MULTIMOB folks) seems inappropriate. In core PMIP, multicast treatment has turned out to work out simply (-> RFC6224). Thus my argument: talk to the multicast guys before adopting a solution ... and make the rest an easy game. Cheers, Thomas On 12.11.2012 21:39, Peter McCann wrote: jouni korhonen wrote: Folks, This mail is to kick off the discussion on multicast requirement(s) for the draft-ietf-dmm-requirements-02 document. I hope we can nail down the essential multicast requirement(s) as soon as possible. To me, multicast in a DMM environment means joining multicast groups directly from access routers. It means re-joining the multicast tree from a new access router after handover. I would hope that we can use existing MLD protocols between the MN and its first hop AR to accomplish this. -Pete ___ 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 ___ 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] Multicast requirements
Hi Juan Carlos, this all sounds very abstract and more from an administrative point of view. Point is (and relevant arguments always have an understanding of the solution space) that some routing scenarios are easy to accomodate multicast and others aren't. My major point was: If DMM picks a solution, people should just think wider (including multicast) and then there is no need to come up with weirdo type of "solutions" in Multimob that are only justified by unicast solutions being ignorant of other use cases. In other words: Rather be clever than smart. Cheers, Thomas On 12.11.2012 23:51, Zuniga, Juan Carlos wrote: I believe the purpose of the discussion was to propose some requirement text for draft-ietf-dmm-requirements, rather than getting in the solution space. I propose the following: Requirement: DMM solutions SHOULD support multicast services. In case the solution does not address multicast, a justification MUST be provided for the omission of multicast from the solution. Motivation: The purpose of this requirement is to encourage people to consider the impacts of running multicast services in a DMM environment from the beginning of the development, thereby avoiding the need to make protocol extensions in the future to support this kind of functionality. Regards, Juan Carlos -Original Message- From: dmm-boun...@ietf.org [mailto:dmm-boun...@ietf.org] On Behalf Of Thomas C. Schmidt Sent: Monday, November 12, 2012 5:06 PM To: Peter McCann Cc: Stig Venaas; Behcet Sarikaya; dmm@ietf.org Subject: Re: [DMM] Multicast requirements Hi Pete, things would be simple, if topology were as described. Let's wait what dmm is birthing out ... and continue discussion then. In any case, complex and incompatible "grand new schemes" do not appear to make much sense. Cheers, Thomas On 12.11.2012 22:53, Peter McCann wrote: In the DMM case my assumption is that the anchor points are closer to the access routers and therefore are very likely to be in the same administrative domain. In these cases, joining the multicast group directly from the access router gives you the same access to the same multicast streams and so tunneling the multicast packets won't be necessary. -Pete Thomas C. Schmidt wrote: Dear Pete, multicast mobility management is a route adaptation problem. As in the unicast case, mobility can only be treated by routing dynamics in trivial cases (re-connect of a tunnel, re-association with next hop). Otherwise it is unwise to delegate mobility adaptation to routing protocols (-> OSPF, BGP ...). Accordingly, if DMM distributes mobility operations, handover management should foresee easy interconnects to previous distribution trees - both for receivers and for mobile multicast sources. I guess, if DMM people are careful, this is not a world-class item and can be treated along the lines of unicast solutions - an isolated multicast protocol treatment (as has been previously proposed from MULTIMOB folks) seems inappropriate. In core PMIP, multicast treatment has turned out to work out simply (-> RFC6224). Thus my argument: talk to the multicast guys before adopting a solution ... and make the rest an easy game. Cheers, Thomas On 12.11.2012 21:39, Peter McCann wrote: jouni korhonen wrote: Folks, This mail is to kick off the discussion on multicast requirement(s) for the draft-ietf-dmm-requirements-02 document. I hope we can nail down the essential multicast requirement(s) as soon as possible. To me, multicast in a DMM environment means joining multicast groups directly from access routers. It means re-joining the multicast tree from a new access router after handover. I would hope that we can use existing MLD protocols between the MN and its first hop AR to accomplish this. -Pete ___ 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 ___ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm
Re: [DMM] Multicast requirements
I believe the purpose of the discussion was to propose some requirement text for draft-ietf-dmm-requirements, rather than getting in the solution space. I propose the following: Requirement: DMM solutions SHOULD support multicast services. In case the solution does not address multicast, a justification MUST be provided for the omission of multicast from the solution. Motivation: The purpose of this requirement is to encourage people to consider the impacts of running multicast services in a DMM environment from the beginning of the development, thereby avoiding the need to make protocol extensions in the future to support this kind of functionality. Regards, Juan Carlos > -Original Message- > From: dmm-boun...@ietf.org [mailto:dmm-boun...@ietf.org] On Behalf Of > Thomas C. Schmidt > Sent: Monday, November 12, 2012 5:06 PM > To: Peter McCann > Cc: Stig Venaas; Behcet Sarikaya; dmm@ietf.org > Subject: Re: [DMM] Multicast requirements > > Hi Pete, > > things would be simple, if topology were as described. > > Let's wait what dmm is birthing out ... and continue discussion then. > In > any case, complex and incompatible "grand new schemes" do not appear to > make much sense. > > Cheers, > > Thomas > > On 12.11.2012 22:53, Peter McCann wrote: > > In the DMM case my assumption is that the anchor points are closer > > to the access routers and therefore are very likely to be in the same > > administrative domain. In these cases, joining the multicast group > > directly from the access router gives you the same access to the same > > multicast streams and so tunneling the multicast packets won't be > > necessary. > > > > -Pete > > > > Thomas C. Schmidt wrote: > >> Dear Pete, > >> > >> multicast mobility management is a route adaptation problem. As in > the > >> unicast case, mobility can only be treated by routing dynamics in > >> trivial cases (re-connect of a tunnel, re-association with next > hop). > >> Otherwise it is unwise to delegate mobility adaptation to routing > >> protocols (-> OSPF, BGP ...). > >> > >> Accordingly, if DMM distributes mobility operations, handover > >> management should foresee easy interconnects to previous > distribution > >> trees - both for receivers and for mobile multicast sources. > >> > >> I guess, if DMM people are careful, this is not a world-class item > and > >> can be treated along the lines of unicast solutions - an isolated > >> multicast protocol treatment (as has been previously proposed from > >> MULTIMOB folks) seems inappropriate. In core PMIP, multicast > treatment > >> has turned out to work out simply (-> RFC6224). > >> > >> Thus my argument: talk to the multicast guys before adopting a > >> solution ... and make the rest an easy game. > >> > >> Cheers, > >> > >> Thomas > >> > >> On 12.11.2012 21:39, Peter McCann wrote: > >>> jouni korhonen wrote: > >>>> Folks, > >>>> > >>>> This mail is to kick off the discussion on multicast > requirement(s) > >>>> for the draft-ietf-dmm-requirements-02 document. I hope we can > nail > >>>> down the essential multicast requirement(s) as soon as possible. > >>> > >>> To me, multicast in a DMM environment means joining multicast > groups > >>> directly from access routers. It means re-joining the multicast > tree > >>> from a new access router after handover. I would hope that we can > use > >>> existing MLD protocols between the MN and its first hop AR to > >>> accomplish this. > >>> > >>> -Pete > >>> > >>> ___ > >>> 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 ___ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm
Re: [DMM] Multicast requirements
Hi Pete, That might be one of them we can take on DMM. Imagine, depending on deployment of existing IP multicasting standard entities, we can think of various use cases as presented in http://tools.ietf.org/html/draft-sfigueiredo-multimob-use-case-dmm-03. Direct routing cannot be applied in every scenario. After I came back from the trip, we (me and Sergio) have been working on this with priority. After carefully reviewing the requirement from the use cases, we'll announce it soon. Regards, Seil -Original Message- From: dmm-boun...@ietf.org [mailto:dmm-boun...@ietf.org] On Behalf Of Peter McCann Sent: Monday, November 12, 2012 9:53 PM To: Thomas C. Schmidt Cc: Stig Venaas; Behcet Sarikaya; dmm@ietf.org Subject: Re: [DMM] Multicast requirements In the DMM case my assumption is that the anchor points are closer to the access routers and therefore are very likely to be in the same administrative domain. In these cases, joining the multicast group directly from the access router gives you the same access to the same multicast streams and so tunneling the multicast packets won't be necessary. -Pete Thomas C. Schmidt wrote: > Dear Pete, > > multicast mobility management is a route adaptation problem. As in the > unicast case, mobility can only be treated by routing dynamics in > trivial cases (re-connect of a tunnel, re-association with next hop). > Otherwise it is unwise to delegate mobility adaptation to routing > protocols (-> OSPF, BGP ...). > > Accordingly, if DMM distributes mobility operations, handover > management should foresee easy interconnects to previous distribution > trees - both for receivers and for mobile multicast sources. > > I guess, if DMM people are careful, this is not a world-class item and > can be treated along the lines of unicast solutions - an isolated > multicast protocol treatment (as has been previously proposed from > MULTIMOB folks) seems inappropriate. In core PMIP, multicast treatment > has turned out to work out simply (-> RFC6224). > > Thus my argument: talk to the multicast guys before adopting a > solution ... and make the rest an easy game. > > Cheers, > > Thomas > > On 12.11.2012 21:39, Peter McCann wrote: >> jouni korhonen wrote: >>> Folks, >>> >>> This mail is to kick off the discussion on multicast requirement(s) >>> for the draft-ietf-dmm-requirements-02 document. I hope we can nail >>> down the essential multicast requirement(s) as soon as possible. >> >> To me, multicast in a DMM environment means joining multicast groups >> directly from access routers. It means re-joining the multicast tree >> from a new access router after handover. I would hope that we can >> use existing MLD protocols between the MN and its first hop AR to >> accomplish this. >> >> -Pete >> >> ___ >> 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 ___ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm
Re: [DMM] Multicast requirements
Hi Pete, things would be simple, if topology were as described. Let's wait what dmm is birthing out ... and continue discussion then. In any case, complex and incompatible "grand new schemes" do not appear to make much sense. Cheers, Thomas On 12.11.2012 22:53, Peter McCann wrote: In the DMM case my assumption is that the anchor points are closer to the access routers and therefore are very likely to be in the same administrative domain. In these cases, joining the multicast group directly from the access router gives you the same access to the same multicast streams and so tunneling the multicast packets won't be necessary. -Pete Thomas C. Schmidt wrote: Dear Pete, multicast mobility management is a route adaptation problem. As in the unicast case, mobility can only be treated by routing dynamics in trivial cases (re-connect of a tunnel, re-association with next hop). Otherwise it is unwise to delegate mobility adaptation to routing protocols (-> OSPF, BGP ...). Accordingly, if DMM distributes mobility operations, handover management should foresee easy interconnects to previous distribution trees - both for receivers and for mobile multicast sources. I guess, if DMM people are careful, this is not a world-class item and can be treated along the lines of unicast solutions - an isolated multicast protocol treatment (as has been previously proposed from MULTIMOB folks) seems inappropriate. In core PMIP, multicast treatment has turned out to work out simply (-> RFC6224). Thus my argument: talk to the multicast guys before adopting a solution ... and make the rest an easy game. Cheers, Thomas On 12.11.2012 21:39, Peter McCann wrote: jouni korhonen wrote: Folks, This mail is to kick off the discussion on multicast requirement(s) for the draft-ietf-dmm-requirements-02 document. I hope we can nail down the essential multicast requirement(s) as soon as possible. To me, multicast in a DMM environment means joining multicast groups directly from access routers. It means re-joining the multicast tree from a new access router after handover. I would hope that we can use existing MLD protocols between the MN and its first hop AR to accomplish this. -Pete ___ 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] Multicast requirements
In the DMM case my assumption is that the anchor points are closer to the access routers and therefore are very likely to be in the same administrative domain. In these cases, joining the multicast group directly from the access router gives you the same access to the same multicast streams and so tunneling the multicast packets won't be necessary. -Pete Thomas C. Schmidt wrote: > Dear Pete, > > multicast mobility management is a route adaptation problem. As in the > unicast case, mobility can only be treated by routing dynamics in > trivial cases (re-connect of a tunnel, re-association with next hop). > Otherwise it is unwise to delegate mobility adaptation to routing > protocols (-> OSPF, BGP ...). > > Accordingly, if DMM distributes mobility operations, handover > management should foresee easy interconnects to previous distribution > trees - both for receivers and for mobile multicast sources. > > I guess, if DMM people are careful, this is not a world-class item and > can be treated along the lines of unicast solutions - an isolated > multicast protocol treatment (as has been previously proposed from > MULTIMOB folks) seems inappropriate. In core PMIP, multicast treatment > has turned out to work out simply (-> RFC6224). > > Thus my argument: talk to the multicast guys before adopting a > solution ... and make the rest an easy game. > > Cheers, > > Thomas > > On 12.11.2012 21:39, Peter McCann wrote: >> jouni korhonen wrote: >>> Folks, >>> >>> This mail is to kick off the discussion on multicast requirement(s) >>> for the draft-ietf-dmm-requirements-02 document. I hope we can nail >>> down the essential multicast requirement(s) as soon as possible. >> >> To me, multicast in a DMM environment means joining multicast groups >> directly from access routers. It means re-joining the multicast tree >> from a new access router after handover. I would hope that we can use >> existing MLD protocols between the MN and its first hop AR to >> accomplish this. >> >> -Pete >> >> ___ >> 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] Multicast requirements
Dear Pete, multicast mobility management is a route adaptation problem. As in the unicast case, mobility can only be treated by routing dynamics in trivial cases (re-connect of a tunnel, re-association with next hop). Otherwise it is unwise to delegate mobility adaptation to routing protocols (-> OSPF, BGP ...). Accordingly, if DMM distributes mobility operations, handover management should foresee easy interconnects to previous distribution trees - both for receivers and for mobile multicast sources. I guess, if DMM people are careful, this is not a world-class item and can be treated along the lines of unicast solutions - an isolated multicast protocol treatment (as has been previously proposed from MULTIMOB folks) seems inappropriate. In core PMIP, multicast treatment has turned out to work out simply (-> RFC6224). Thus my argument: talk to the multicast guys before adopting a solution ... and make the rest an easy game. Cheers, Thomas On 12.11.2012 21:39, Peter McCann wrote: jouni korhonen wrote: Folks, This mail is to kick off the discussion on multicast requirement(s) for the draft-ietf-dmm-requirements-02 document. I hope we can nail down the essential multicast requirement(s) as soon as possible. To me, multicast in a DMM environment means joining multicast groups directly from access routers. It means re-joining the multicast tree from a new access router after handover. I would hope that we can use existing MLD protocols between the MN and its first hop AR to accomplish this. -Pete ___ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm -- Prof. Dr. Thomas C. Schmidt ° Hamburg University of Applied Sciences Berliner Tor 7 ° ° Dept. Informatik, Internet Technologies Group20099 Hamburg, Germany ° ° http://www.haw-hamburg.de/inet Fon: +49-40-42875-8452 ° ° http://www.informatik.haw-hamburg.de/~schmidtFax: +49-40-42875-8409 ° ___ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm
Re: [DMM] Multicast requirements
Hi Jouni, This discussion originated by a presentation in Multimob of a draft on IP Multicast Use Cases and Analysis over Distributed Mobility Management, http://tools.ietf.org/html/draft-sfigueiredo-multimob-use-case-dmm-03. This draft is on use cases not on requirements. The author, Seil mentioned that maybe he can extract some requirements from his draft. As a possible way going forward, I suggest that Seil does this and proposes some requirements maybe as part of this thread and we go from there. I can tell you that in Multimob meeting in Atlanta, we have not discussed any requirements. Regards, Behcet On Mon, Nov 12, 2012 at 1:59 PM, jouni korhonen wrote: > Folks, > > This mail is to kick off the discussion on multicast requirement(s) for the > draft-ietf-dmm-requirements-02 document. I hope we can nail down the > essential multicast requirement(s) as soon as possible. > > - Jouni > ___ > 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] Multicast requirements
Hi Pete, For PMIPv6, Multimob has defined a base multicast support protocol which is documented in RFC 6224. You may wish to take a look at this RFC. Currently Multimob is working on several extensions to the base protocol. Let's stop speculating how the multicast is supported and concentrate on dmm multicast requirements. Regards, Behcet On Mon, Nov 12, 2012 at 2:39 PM, Peter McCann wrote: > jouni korhonen wrote: >> Folks, >> >> This mail is to kick off the discussion on multicast requirement(s) >> for the draft-ietf-dmm-requirements-02 document. I hope we can nail >> down the essential multicast requirement(s) as soon as possible. > > To me, multicast in a DMM environment means joining multicast > groups directly from access routers. It means re-joining the > multicast tree from a new access router after handover. I would > hope that we can use existing MLD protocols between the MN and > its first hop AR to accomplish this. > > -Pete > > ___ > 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] Multicast requirements
jouni korhonen wrote: > Folks, > > This mail is to kick off the discussion on multicast requirement(s) > for the draft-ietf-dmm-requirements-02 document. I hope we can nail > down the essential multicast requirement(s) as soon as possible. To me, multicast in a DMM environment means joining multicast groups directly from access routers. It means re-joining the multicast tree from a new access router after handover. I would hope that we can use existing MLD protocols between the MN and its first hop AR to accomplish this. -Pete ___ dmm mailing list dmm@ietf.org https://www.ietf.org/mailman/listinfo/dmm
