Hi Stig, Thanks for raising this third possibility for discussion. With the two options that I described on my mail we were trying to reflect the feedback we received in some of the comments on the mail list and during the meeting. The objective of the second one is to simplify the draft, reducing the complexity of the proposal while, at the same time, opening the door to potential optimizations that could be later specified (at the cost of more complexity).
In this way, removing the flag A mechanism procedures from the draft does not prevent the possibility of further improvements that could be documented separately, decoupling the main handover optimization solution documented in the draft from future improvements (a text can be included to highlight that specific mechanisms could be developed in the future for improving the efficiency of the solution). We as editors are ok in considering your proposed option 3 and working on that if finally it is the option preferred by the WG. However, our feeling is that including the optional mechanism in the document will increase the complexity of the solution. If the decision is to make optional the flag A mechanism, our personal opinion is that it would be better to remove it from the main text. Thanks for your positive contribution, Best regards, Luis -----Mensaje original----- De: [email protected] [mailto:[email protected]] En nombre de Stig Venaas Enviado el: miércoles, 10 de abril de 2013 19:49 Para: [email protected] Asunto: Re: [multimob] WG Poll about the inclusion or not of flag A mechanism in draft-ietf-multimob-handover-optimization Hi I'm responding here with my personal view, and hopefully also the same as I was saying in the meeting. On 4/10/2013 12:49 AM, LUIS MIGUEL CONTRERAS MURILLO wrote: > Dear all, > > After the Orlando meeting discussions on the flag A mechanism > described in draft-ietf-multimob-handover-optimization-02 for > mitigating the internal signaling within the network in case of > reactive handover, we would like to consult WG members about your preference: > > Option 1.- To include the flag A mechanism as an integral (and > mandatory) part of the solution, as described in the draft today. > > Option 2.- To consider the flag A mechanism as an option to reduce > signaling in the core, then removing the reference to this mechanism > from the draft. The final document would consider that the LMA always > queries the pMAG by default, but mentioning that some mechanism > (out-of-scope) could be used to reduce this signaling (by avoiding to > query the pMAG). Wouldn't a 3rd option be to keep it in the draft, but not make the A flag mandatory to implement/enable? I think that may require additional work though, because you may need to know whether the A flag is being used. Basically you need to know that A flag not set, doesn't mean that there is no subscription when A-flag support isn't enabled. My concern is that the A-flag mechanism may not be worth the effort, or even worse, if clients often switch between having multicast subscriptions and not (basically that A is frequently often updated). If the A flag is mostly stable, then I think it is useful. So at least my thinking is that unless we know with some certainty what the usage pattern is, then it is better to make it optional. If we agree on making it optional, then the question is whether we still want it in this document (option 2 or 3). Hope we can get the input of several people in the group and try to figure out what the best option is. Stig > Thanks in advance, > > Best regards, > > Luis > > ________________________________ > > Luis M. Contreras > > Technology / Global CTO / Telefónica > > Efficiency Projects / Telefónica I+D > > Distrito Telefónica, Edificio Sur 3, Planta 3 > > 28050 Madrid > > España / Spain > > [email protected] > > > ---------------------------------------------------------------------- > -- > > Este mensaje se dirige exclusivamente a su destinatario. Puede > consultar nuestra política de envío y recepción de correo electrónico > en el enlace situado más abajo. > This message is intended exclusively for its addressee. We only send > and receive email on the basis of the terms set out at: > http://www.tid.es/ES/PAGINAS/disclaimer.aspx > > > _______________________________________________ > multimob mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/multimob > _______________________________________________ multimob mailing list [email protected] https://www.ietf.org/mailman/listinfo/multimob ________________________________ Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nuestra política de envío y recepción de correo electrónico en el enlace situado más abajo. This message is intended exclusively for its addressee. We only send and receive email on the basis of the terms set out at: http://www.tid.es/ES/PAGINAS/disclaimer.aspx _______________________________________________ multimob mailing list [email protected] https://www.ietf.org/mailman/listinfo/multimob
