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>, >>>>>> 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 >>>>> >>>>> >>>>> >>>>> >>>> >>> >> >> >> _________________________________________________________________________________________________________________________ >> >> 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 >
- [netext] I-D Action: draft-ietf-netext-pmipv6-flo… internet-drafts
- [netext] [Fwd: I-D Action: draft-ietf-netext-pmip… Carlos Jesús Bernardos Cano
- Re: [netext] [Fwd: I-D Action: draft-ietf-netext-… Hidetoshi Yokota
- Re: [netext] [Fwd: I-D Action: draft-ietf-netext-… pierrick.seite
- Re: [netext] [Fwd: I-D Action: draft-ietf-netext-… Sri Gundavelli (sgundave)
- Re: [netext] [Fwd: I-D Action: draft-ietf-netext-… Carlos Jesús Bernardos Cano
- Re: [netext] [Fwd: I-D Action: draft-ietf-netext-… Sri Gundavelli (sgundave)
- Re: [netext] [Fwd: I-D Action: draft-ietf-netext-… Behcet Sarikaya
- Re: [netext] [Fwd: I-D Action: draft-ietf-netext-… Sri Gundavelli (sgundave)
- Re: [netext] [Fwd: I-D Action: draft-ietf-netext-… Hidetoshi Yokota
- Re: [netext] [Fwd: I-D Action: draft-ietf-netext-… Rajeev Koodli
- Re: [netext] [Fwd: I-D Action: draft-ietf-netext-… Hidetoshi Yokota
- Re: [netext] [Fwd: I-D Action: draft-ietf-netext-… Carlos Jesús Bernardos Cano
- Re: [netext] [Fwd: I-D Action: draft-ietf-netext-… Carlos Jesús Bernardos Cano
- Re: [netext] [Fwd: I-D Action: draft-ietf-netext-… Hidetoshi Yokota
- Re: [netext] [Fwd: I-D Action: draft-ietf-netext-… Carlos Jesús Bernardos Cano
- Re: [netext] [Fwd: I-D Action: draft-ietf-netext-… pierrick.seite
- Re: [netext] [Fwd: I-D Action: draft-ietf-netext-… Carlos Jesús Bernardos Cano
- Re: [netext] [Fwd: I-D Action: draft-ietf-netext-… Brian Haberman
- Re: [netext] [Fwd: I-D Action: draft-ietf-netext-… Rajeev Koodli
- Re: [netext] [Fwd: I-D Action: draft-ietf-netext-… Carlos Jesús Bernardos Cano