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

[Rajeev Koodli <[e-mail]>]

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 am supportive of adding the Flow ID mobility option.

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
>