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

[Hidetoshi Yokota <[e-mail]>]

Hi Rajeev,

"New Code" values mean new MH Types or different ones? If your intention
is to define new MH types with exactly the same format as UPN/UPA, then
it would be better to define a new flag or notification reason in UPN/UPA.

Regards,
--
Hidetoshi

(2014/06/24 4:37), Rajeev Koodli wrote:
>
> Yes, but just to be clear: The Flow Mobility ID defines FMI/FMA
> messages which use the same format as UPN with the new Code values.
>
> -Rajeev
>
>
>
> On Thu, Jun 19, 2014 at 6:46 AM, Sri Gundavelli (sgundave)
> <[e-mail] <mailto:[e-mail]>> wrote:
>
>     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]
>     <mailto:[e-mail]>" <[e-mail]
>     <mailto:[e-mail]>>
>     Date: Thursday, June 19, 2014 1:32 AM
>     To: Hidetoshi Yokota <[e-mail]
>     <mailto:[e-mail]>>, "[e-mail]
>     <mailto:[e-mail]>" <[e-mail] <mailto:[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
>     *Envoye' :* jeudi 19 juin 2014 06:41
>     *A` :* [e-mail] <mailto:[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] <mailto:e-mail:[e-mail]>
>
>     (2014/06/14 2:16), Carlos Jesu'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] <mailto:[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] <mailto:[e-mail]>
>     https://www.ietf.org/mailman/listinfo/netext
>