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

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

Hi Rajeev, Hidetoshi, all,

Please see some comments inline below.

On Mon, 2014-07-14 at 09:24 -0700, Rajeev Koodli wrote:
> 
> Hi Carlos, Yokota-san,
> 
> 
> sorry for the delay in my response.
> 
> 
> I would like to clarify something: The FMI/FMA messages make use of
> the UPN/UPA format with specific New Reason/Status Codes. In other
> words, the _only_ requirement is to support the UPN/UPA messages for
> these specific FMI/FMA purposes, and that there is no requirement to
> support RFC 7077 in its entirety. So, I suggest adding the following
> text, perhaps in the Message Format section.
> 
> 
> "This specification requires implementation of UPN [RFC7077] and UPA
> [RFC7077] messages with the specific Notification Reason and Status
> Code as defined by this document. This document does not require
> implementation of any other aspects of RFC 7077."

I'm fine adding some text along those lines.
> 
> 
> I am supportive of adding the Flow ID mobility option.

OK, we can check the consensus during the meeting and if the group is
supporting, I'll add it.

Carlos
> 
> 
> Regards,
> 
> 
> -Rajeev
> 
> 
> 
> 
> On Tue, Jul 1, 2014 at 5:37 PM, Carlos Jesús Bernardos Cano
> <[e-mail]> wrote:
>         Hi Hidetoshi,
>         
>         Thanks again for your comments. Please see inline below some
>         comments/replies from my side:
>         
>         On Sun, 2014-06-29 at 22:32 +0900, Hidetoshi Yokota wrote:
>         > Hi Carlos,
>         >
>         > I briefly reviewed the updated draft and have a couple of
>         comments.
>         >
>         > o The messages named as FMI/FMA in this document are
>         actually UPN/UPA,
>         > so the description is confusing since it looks as if new
>         messages were
>         > defined. I would propose a new flag or notification
>         reason/status code
>         > to indicate that UPN/UPA are used for flow mobility.
>         
>         
>         The use of FMI/FMA is simply to make clearer that these
>         UPN/UPA messages
>         are for flow mobility purposes. New notification reason codes
>         are
>         actually defined in the document for this purpose.
>         
>         >
>         > o In the previous version, FMI could convey the Flow ID
>         mobility option,
>         > but the latest version can convey only HNPs. This looks like
>         a
>         > degradation and I'm not sure how both LMA and MAG can share
>         the same
>         > flow mobility cache.
>         
>         
>         With the UPN/UPA signaling option, the document has never
>         supported
>         conveying the Flow ID mobility option. Ensuring that both the
>         LMA and
>         MAG keep the same flow mobility cache was out of the scope of
>         the
>         document. If the WG agrees, we could add the possibility of
>         supporting
>         UPN/UPA (FMI/FMA) optionally conveying the Flow ID mobility
>         option. What
>         do other people think?
>         
>         >
>         > o The flow mobility operation such as "add" or "remove"
>         should be able
>         > to specify the targeted flow. To this end, the Flow ID
>         mobility option
>         > in RFC6089 should be used. The flow binding action
>         sub-option defined in
>         > RFC7109 can be used for the flow mobility operation.
>         
>         
>         In the current version "add" and "remove" are performed with
>         prefix
>         granularity (as I mentioned in a previous e-mail, this was the
>         consensus
>         reached some time ago, but we can revisit this if the WG wants
>         to do
>         so).
>         
>         Thanks!
>         
>         Carlos
>         
>         >
>         > Please take these points into consideration.
>         >
>         > Regards,
>         > --
>         > Hidetoshi
>         >
>         > (2014/06/26 7:05), Carlos Jesús Bernardos Cano wrote:
>         > > 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
>         > >
>         > >
>         > >
>         > >
>         >
>         
>         
>         _______________________________________________
>         netext mailing list
>         [e-mail]
>         https://www.ietf.org/mailman/listinfo/netext
>         
> 
>