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

From: Carlos Jesús Bernardos Cano <[email-masked]>
Date: Wed, 02 Jul 2014 02:37:59 +0200

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 <[email-masked]>
> >> Date: Thursday, June 19, 2014 6:46 AM
> >> To: "[email-masked]" <[email-masked]>, Hidetoshi
> >> Yokota <[email-masked]>, "[email-masked]" <[email-masked]>
> >> 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: "[email-masked]" <[email-masked]>
> >> Date: Thursday, June 19, 2014 1:32 AM
> >> To: Hidetoshi Yokota <[email-masked]>, "[email-masked]"
> >> <[email-masked]>
> >> 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:[email-masked]] De la part de Hidetoshi
> >> Yokota
> >> Envoyé : jeudi 19 juin 2014 06:41
> >> À : [email-masked]
> >> 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:[email-masked]
> >>
> >>   
> >>
> >> (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
> >>          [email-masked]
> >>          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
> >> [email-masked]
> >> https://www.ietf.org/mailman/listinfo/netext
> >
> >
> >
> >
>

---

From: <[email-masked]>
Date: Wed, 2 Jul 2014 13:37:18 +0000

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:[email-masked]]
>Envoyé : mercredi 2 juillet 2014 02:38
>À : Hidetoshi Yokota
>Cc : Sri Gundavelli; SEITE Pierrick IMT/OLN; [email-masked]
>Objet : Re: [netext] [Fwd: I-D Action: draft-ietf-netext-pmipv6-flowmob-
>09.txt]
>
>Hi Hidetoshi,
>
>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
>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?
>
>>
>reached some time ago, but we can revisit this if the WG wants to do so).
>
>Thanks!
>
>Carlos
>
>>
>> >> 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
>> >>
>> >>
>> >> To: "[email-masked]" <[email-masked]>,
>> >> Hidetoshi Yokota <[email-masked]>, "[email-masked]"
>> >> <[email-masked]>
>> >> 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
>> >>
>> >>
>> >>
>> >>
>> >> 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:[email-masked]] De la part de
>> >> Hidetoshi Yokota Envoyé : jeudi 19 juin 2014 06:41 À :
>> >> [email-masked] Objet : Re: [netext] [Fwd: I-D Action:
>> >> 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.
>> >> 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
>> >>
>___________________________________________________________
>________
>> >> ______________________________________________________
>> >>
>> >> 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.

---

From: Carlos Jesús Bernardos Cano <[email-masked]>
Date: Wed, 02 Jul 2014 15:51:55 +0200

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

---

From: Brian Haberman <[email-masked]>
Date: Wed, 02 Jul 2014 09:59:53 -0400

Carlos is correct, these type of acknowledgements are acceptable.  They
have been in several RFCs published with similar statements.

Brian

---

From: Rajeev Koodli <[email-masked]>
Date: Mon, 14 Jul 2014 09:24:19 -0700

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 <[email-masked]
> wrote:

> 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,
> privileged information that may be protected by law;
> > >> If you have received this email in error, please notify the sender
> and delete this message and its attachments.

---

From: Carlos Jesús Bernardos Cano <[email-masked]>
Date: Sat, 19 Jul 2014 11:01:21 +0200

Hi Rajeev, Hidetoshi, all,

Please see some comments inline below.

On Mon, 2014-07-14 at 09:24 -0700, Rajeev Koodli wrote:
> 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.
> 
> 
> [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
> <[email-masked]> wrote:
>         Hi Hidetoshi,
>         
>         > >> 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,
>         > >> This message and its attachments may contain confidential
>         or privileged information that may be protected by law;
>         > >> 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.