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

Carlos Jesús Bernardos Cano <cjbc@it.uc3m.es> Wed, 02 July 2014 13:52 UTC

Return-Path: <cjbc@it.uc3m.es>
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 6969E1A0117 for <netext@ietfa.amsl.com>; Wed, 2 Jul 2014 06:52:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.552
X-Spam-Level:
X-Spam-Status: No, score=-4.552 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001] 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 vRck_aKJ1z4q for <netext@ietfa.amsl.com>; Wed, 2 Jul 2014 06:51:57 -0700 (PDT)
Received: from smtp03.uc3m.es (smtp03.uc3m.es [163.117.176.133]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EAB281A0102 for <netext@ietf.org>; Wed, 2 Jul 2014 06:51:56 -0700 (PDT)
Received: from smtp03.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 8EBD71239CFB; Wed, 2 Jul 2014 15:51:55 +0200 (CEST)
X-uc3m-safe: yes
X-uc3m-safe: yes
Received: from [163.117.139.72] (acorde.it.uc3m.es [163.117.139.72]) (using TLSv1 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: cjbc@smtp03.uc3m.es) by smtp03.uc3m.es (Postfix) with ESMTPSA id 7720B1204E29; Wed, 2 Jul 2014 15:51:55 +0200 (CEST)
Message-ID: <1404309115.8479.24.camel@acorde.it.uc3m.es>
From: Carlos =?ISO-8859-1?Q?Jes=FAs?= Bernardos Cano <cjbc@it.uc3m.es>
To: pierrick.seite@orange.com
Date: Wed, 02 Jul 2014 15:51:55 +0200
In-Reply-To: <6571_1404308239_53B40B0E_6571_3159_1_81C77F07008CA24F9783A98CFD706F711426CDF6@PEXCVZYM12.corporate.adroot.infra.ftgroup>
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>
Organization: Universidad Carlos III de Madrid
Content-Type: text/plain; charset="UTF-8"
X-Mailer: Evolution 3.8.5-2+b3
Mime-Version: 1.0
Content-Transfer-Encoding: 8bit
X-TM-AS-Product-Ver: IMSS-7.1.0.1224-7.5.0.1017-20792.007
X-TM-AS-Result: No--28.806-7.0-31-1
X-imss-scan-details: No--28.806-7.0-31-1
Archived-At: http://mailarchive.ietf.org/arch/msg/netext/o21iKWx2HffxquW49j0SOlm1WLI
Cc: "netext@ietf.org" <netext@ietf.org>
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
Reply-To: cjbc@it.uc3m.es
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:52:01 -0000

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.
>