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

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

Hi Pierrick,

This should be fine. I've put similar statements in previous documents
and I haven't had any problems so far. The statement just refers to my
work (e.g., supporting travels, etc).

Carlos

On Wed, 2014-07-02 at 13:37 +0000, [e-mail] wrote:
> Hi,
> 
> Just a minor comment:
> 
> The acknowledgement section states that this work has been partially funded by the European Community via a research project. Is such statement acceptable for an IETF document? Shoudn't we remove this ack?
> 
> Pierrick
> 
> >-----Message d'origine-----
> >De : Carlos Jesús Bernardos Cano [mailto:[e-mail]]
> >Envoyé : mercredi 2 juillet 2014 02:38
> >À : Hidetoshi Yokota
> >Cc : Sri Gundavelli; SEITE Pierrick IMT/OLN; [e-mail]
> >Objet : Re: [netext] [Fwd: I-D Action: draft-ietf-netext-pmipv6-flowmob-
> >09.txt]
> >
> >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
> >> >
> >> >
> >> >
> >> >
> >>
> >
> 
> 
> _________________________________________________________________________________________________________________________
> 
> 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.
>