Re: [netext] [Fwd: I-D Action: draft-ietf-netext-pmipv6-flowmob-09.txt]
Carlos Jesús Bernardos Cano <cjbc@it.uc3m.es> Sat, 19 July 2014 09:01 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 B0ADC1A002C for <netext@ietfa.amsl.com>; Sat, 19 Jul 2014 02:01:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.003
X-Spam-Level:
X-Spam-Status: No, score=-2.003 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, 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 nibdP71hVhow for <netext@ietfa.amsl.com>; Sat, 19 Jul 2014 02:01:26 -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 9727A1A0111 for <netext@ietf.org>; Sat, 19 Jul 2014 02:01:25 -0700 (PDT)
Received: from smtp03.uc3m.es (localhost [127.0.0.1]) by localhost.uc3m.es (Postfix) with ESMTP id 5550215152E9; Sat, 19 Jul 2014 11:01:23 +0200 (CEST)
X-uc3m-safe: yes
X-uc3m-safe: yes
Received: from [172.20.10.3] (198.Red-88-29-126.staticIP.rima-tde.net [88.29.126.198]) (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 EEF409D27BC; Sat, 19 Jul 2014 11:01:22 +0200 (CEST)
Message-ID: <1405760481.4134.9.camel@acorde.it.uc3m.es>
From: Carlos Jesús Bernardos Cano <cjbc@it.uc3m.es>
To: Rajeev Koodli <rajeev.koodli@gmail.com>
Date: Sat, 19 Jul 2014 11:01:21 +0200
In-Reply-To: <CAB_pk7C72DKXi+A2kgdMwCuOLVD7TNVHgWOx9k83ZigiTswLMQ@mail.gmail.com>
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> <CAB_pk7C72DKXi+A2kgdMwCuOLVD7TNVHgWOx9k83ZigiTswLMQ@mail.gmail.com>
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-20826.006
X-TM-AS-Result: No--27.587-7.0-31-1
X-imss-scan-details: No--27.587-7.0-31-1
Archived-At: http://mailarchive.ietf.org/arch/msg/netext/iNORw_kJ92-PIvelMvTq9DbBbxc
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: Sat, 19 Jul 2014 09:01:31 -0000
Hi Rajeev, Hidetoshi, all, Please see some comments inline below. On Mon, 2014-07-14 at 09:24 -0700, Rajeev Koodli wrote: > > 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'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 > <cjbc@it.uc3m.es> wrote: > 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 > > > > > > > > > > > > > > > > > _______________________________________________ > 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