Re: [netext] [Fwd: I-D Action: draft-ietf-netext-pmipv6-flowmob-09.txt]

[Carlos Jesús Bernardos Cano <[e-mail]>]

Hi,

I've just posted -10, now including only one single signaling
mechanisms, as discussed on the ML.

I think this version is ready for WGLC.

Carlos

On Thu, 2014-06-19 at 18:09 +0000, Sri Gundavelli (sgundave) wrote:
> Hi Carlos/All,
> 
> 
> Can we plan to close this work in the next few days. AFAIK, this
> FMI/FMA issue is now resolved. If you still doubt the consensus on
> this issue, we can wait for 2 days for any comments and post the next
> rev.
> 
> 
> I'm hoping we will close this work this week and go LC on Monday (if
> chairs agree). Waiting for Toronto meeting can delay the work by
> another few months.
> 
> 
> 
> 
> Regards
> Sri
> 
> 
> From: Sri Gundavelli <[e-mail]>
> Date: Thursday, June 19, 2014 6:46 AM
> To: "[e-mail]" <[e-mail]>, Hidetoshi
> Yokota <[e-mail]>, "[e-mail]" <[e-mail]>
> Subject: Re: [netext] [Fwd: I-D Action:
> draft-ietf-netext-pmipv6-flowmob-09.txt]
> 
> 
> 
> Hi Pierrick,
> 
> 
> After the NETEXT meeting in London, we had some offline discussions
> with Rajiv and folks. There is agreement to use the RFC-7077 (UPN)
> messaging format for FMI/FMA. So, the Flow Mobility spec may refer to
> this message as FMI/FMA, but the underneath messaging format will
> confirm to RFC-7077 format and will have references to RFC-7077. We
> are not going to define a new MH message. This closes the key issue of
> using two notification approaches in the same spec. AFAIK, no one has
> any objection to this. If any does, its now time to speak up :)
> 
> 
> Regards
> Sri
> 
> 
> 
> 
> From: "[e-mail]" <[e-mail]>
> Date: Thursday, June 19, 2014 1:32 AM
> To: Hidetoshi Yokota <[e-mail]>, "[e-mail]"
> <[e-mail]>
> Subject: Re: [netext] [Fwd: I-D Action:
> draft-ietf-netext-pmipv6-flowmob-09.txt]
> 
> 
> 
> Hi Hidetoshi/all,
> 
>  
> 
> Release -08 mandates RFC7077 and the doc was good, IMHO. But, in
> London, we have decided (group consensus) to reintroduce FMI/FMA to
> avoid dependency between RFC. Now, it’s true that introducing 2
> options for message format makes the solution more complex for little
> added-value (no major differences between messages)… So, maybe the
> question is “is it good or bad to have RFC dependency?” then update
> the draft according the answer...
> 
>  
> 
> Pierrick
> 
>  
> 
> De : netext [mailto:[e-mail]] De la part de Hidetoshi
> Yokota
> Envoyé : jeudi 19 juin 2014 06:41
> À : [e-mail]
> Objet : Re: [netext] [Fwd: I-D Action:
> draft-ietf-netext-pmipv6-flowmob-09.txt]
> 
> 
>  
> 
> Hello Carlos,
> 
> Thanks for updating the draft. 
> I have a couple of questions and comments:
> 
> o In Section 3.2.1, which is the shared prefix case, there is no
> message exchange between the LMA and MAG, so there is no flow
> information on the MAG side. It should work in the sense of routing,
> but if, for example, each flow has a specific QoS, the MAG should also
> need to know which flow should go on which QoS path especially for
> upstream traffic towards the LMA. Or, the MAG may want to send a
> trigger for flow mobility to the MN (the exact mechanism is out of
> scope).  Some mobility signaling should be there, too.
> 
> o In Section 3.3, FMI/FMA are revived considering the case where UPN
> is not supported, but they convey very little information. There is no
> special information that cannot be conveyed by the existing messages.
> Since RFC7077 is now a proposed standard, I cannot think of a
> situation where the UPN/UPA are not supported, nevertheless FMI/FMA
> are supported. It rather seems more natural to mandate the support of
> RFC7077 or to mandate FMI/FMA for all flow mobility operations.
> Also, when compared with UPN/UPA case in Figure 4, FMI/FMA seem to
> convey different set of parameters in Figure 7. Could you clarify it a
> little bit more please?
> 
> o In Section 3.3, just above Figure 7, there is a description: "...,
> and the type of flow mobility operation (add flow)", but does RFC6089
> define such an operation code? This kind of operation should also be
> defined in the draft.
> 
> Regards,
> 
> 
> 
> -- 
> Hidetoshi Yokota
>  
> KDDI R&D Laboratories, Inc.
> e-mail:[e-mail]
> 
>  
> 
> (2014/06/14 2:16), Carlos Jesús Bernardos Cano wrote:
> 
> 
>         Hi,
>          
>         As agreed in London, I've updated the flow mobility draft to include
>         also the FMI/FMA signaling option (in addition to the use of Update
>         Notifications). The draft also includes a mechanism to allow selecting
>         which one of the two signaling mechanisms to use.
>          
>         In my personal opinion, it'd be much cleaner and simpler to just specify
>         one signaling mechanism, but this is up to the WG to decide.
>          
>         Comments, reviews and discussion on this new revision would be welcome.
>         Hopefully we could get at least a new revision before Toronto.
>          
>         Thanks,
>          
>         Carlos
>         
>         
>         
>         
>         _______________________________________________
>         netext mailing list
>         [e-mail]
>         https://www.ietf.org/mailman/listinfo/netext
> 
>  
> 
> 
> _________________________________________________________________________________________________________________________
> 
> Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
> pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
> a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
> Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.
> 
> This message and its attachments may contain confidential or privileged information that may be protected by law;
> they should not be distributed, used or copied without authorisation.
> If you have received this email in error, please notify the sender and delete this message and its attachments.
> As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
> Thank you.
> _______________________________________________
> netext mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/netext