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

Behcet,

> This draft is in no way close WG LC.

That has been just your comment since day-1. AFAIK, no one in the WG is
able to understand the technical issue you are raising, other than these
vague comments. 

If you see a technical issue, explain it, challenge us and we are up for
it. If you cannot, park the issue and its time to move forward.

FWIW, Suresh, when chairing the WG in one of the meetings did a poll in
the room and no one agreed with your views. So, its time to move on ..

Sri

On 6/19/14 3:52 PM, "Behcet Sarikaya" <sarikaya2012@gmail.com> wrote:

>On Thu, Jun 19, 2014 at 1:09 PM, Sri Gundavelli (sgundave)
><sgundave@cisco.com> 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.
>>
>
>This draft is in no way close WG LC.
>
>At the outset Raj has set out very clearly the direction for this work
>in his mail way back on March 3, 2011
>http://www.ietf.org/mail-archive/web/netext/current/msg01839.html
>
>Quote
>Flow mobility in the context of Proxy MIP6 is the switching of a flow
>by the LMA from MAGx to MAGy when the MN is attached to the LMA via
>multiple
>interfaces through different MAGs. The LMA makes the decision to move
>a flow based on some policy.
>Unquote
>
>No mention of LMA-initiated flow mobility can be found in this draft.
>Use case scenario 1, common set of prefixes is not feasible.
>MN can get different prefixes even on a single interface, what is the
>point of considering same prefix on all interfaces?
>
>If we remove Use Case 1 then there are no use cases.
>
>This draft needs to be reworked.
>
>Regards,
>
>Behcet
>
>
>> 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 <sgundave@cisco.com>
>> Date: Thursday, June 19, 2014 6:46 AM
>> To: "pierrick.seite@orange.com" <pierrick.seite@orange.com>, Hidetoshi
>> Yokota <yokota@kddilabs.jp>, "netext@ietf.org" <netext@ietf.org>
>>
>> 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: "pierrick.seite@orange.com" <pierrick.seite@orange.com>
>> Date: Thursday, June 19, 2014 1:32 AM
>> To: Hidetoshi Yokota <yokota@kddilabs.jp>, "netext@ietf.org"
>> <netext@ietf.org>
>> 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:netext-bounces@ietf.org] De la part de Hidetoshi
>>Yokota
>> Envoyé : jeudi 19 juin 2014 06:41
>> À : netext@ietf.org
>> 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:yokota@kddilabs.jp
>>
>>
>>
>> (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
>>
>> netext@ietf.org
>>
>> 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
>> netext@ietf.org
>> https://www.ietf.org/mailman/listinfo/netext
>>