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

Brian Haberman <brian@innovationslab.net> Wed, 02 July 2014 13:59 UTC

Return-Path: <brian@innovationslab.net>
X-Original-To: netext@ietfa.amsl.com
Delivered-To: netext@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A5791A00F8 for <netext@ietfa.amsl.com>; Wed, 2 Jul 2014 06:59:57 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LdvbtqU_Swng for <netext@ietfa.amsl.com>; Wed, 2 Jul 2014 06:59:53 -0700 (PDT)
Received: from uillean.fuaim.com (uillean.fuaim.com [206.197.161.140]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 310531A00E8 for <netext@ietf.org>; Wed, 2 Jul 2014 06:59:53 -0700 (PDT)
Received: from clairseach.fuaim.com (clairseach-high.fuaim.com [206.197.161.158]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by uillean.fuaim.com (Postfix) with ESMTP id 16C0188124 for <netext@ietf.org>; Wed, 2 Jul 2014 06:59:53 -0700 (PDT)
Received: from 10252102127.rude2.ra.johnshopkins.edu (addr16212925014.ippl.jhmi.edu [162.129.250.14]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by clairseach.fuaim.com (Postfix) with ESMTP id A48F571B0001 for <netext@ietf.org>; Wed, 2 Jul 2014 06:59:52 -0700 (PDT)
Message-ID: <53B41059.7080505@innovationslab.net>
Date: Wed, 02 Jul 2014 09:59:53 -0400
From: Brian Haberman <brian@innovationslab.net>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: netext@ietf.org
References: <CFC87176.13FB6C%sgundave@cisco.com> <1403733921.11909.19.camel@acorde.it.uc3m.es> <53B0155E.2050002@gmail.com> <1404261479.5086.15.camel@acorde.it.uc3m.es> <6571_1404308239_53B40B0E_6571_3159_1_81C77F07008CA24F9783A98CFD706F711426CDF6@PEXCVZYM12.corporate.adroot.infra.ftgroup> <1404309115.8479.24.camel@acorde.it.uc3m.es>
In-Reply-To: <1404309115.8479.24.camel@acorde.it.uc3m.es>
X-Enigmail-Version: 1.6
Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="fTRtbIqbQv54vM03r5ifFjfmeRHA4i3np"
Archived-At: http://mailarchive.ietf.org/arch/msg/netext/y_rXJbJNvIUZH2J_muiv-u2bu-w
Subject: Re: [netext] [Fwd: I-D Action: draft-ietf-netext-pmipv6-flowmob-09.txt]
X-BeenThere: netext@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " <netext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/netext>, <mailto:netext-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/netext/>
List-Post: <mailto:netext@ietf.org>
List-Help: <mailto:netext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/netext>, <mailto:netext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 02 Jul 2014 13:59:57 -0000

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

Brian

On 7/2/14 9:51 AM, Carlos Jesús Bernardos Cano wrote:
> 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, pierrick.seite@orange.com 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:cjbc@it.uc3m.es]
>>> Envoyé : mercredi 2 juillet 2014 02:38
>>> À : Hidetoshi Yokota
>>> Cc : Sri Gundavelli; SEITE Pierrick IMT/OLN; netext@ietf.org
>>> 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 <sgundave@cisco.com>
>>>>>> Date: Thursday, June 19, 2014 6:46 AM
>>>>>> To: "pierrick.seite@orange.com" <pierrick.seite@orange.com>om>,
>>>>>> Hidetoshi Yokota <yokota@kddilabs.jp>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>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
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>
>>
>>
>> _________________________________________________________________________________________________________________________
>>
>> 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
>