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 =?ISO-8859-1?Q?Jes=FAs?= 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>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
>         > >
>         > >
>         > >
>         > >
>         >
>         
>         
>         _______________________________________________
>         netext mailing list
>         netext@ietf.org
>         https://www.ietf.org/mailman/listinfo/netext
>         
> 
>