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

Rajeev Koodli <rajeev.koodli@gmail.com> Mon, 14 July 2014 16:24 UTC

Return-Path: <rajeev.koodli@gmail.com>
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 6256E1A0AC4 for <netext@ietfa.amsl.com>; Mon, 14 Jul 2014 09:24:25 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=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 hX0GIutRC4DB for <netext@ietfa.amsl.com>; Mon, 14 Jul 2014 09:24:21 -0700 (PDT)
Received: from mail-wg0-x230.google.com (mail-wg0-x230.google.com [IPv6:2a00:1450:400c:c00::230]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2F7F71A0ABD for <netext@ietf.org>; Mon, 14 Jul 2014 09:24:21 -0700 (PDT)
Received: by mail-wg0-f48.google.com with SMTP id x13so4398725wgg.7 for <netext@ietf.org>; Mon, 14 Jul 2014 09:24:19 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=iAeHkPAyrizhjaBQLRjRP/CDTfG3dWgMW6YO5gHQ1tI=; b=IP63iL4rZH7oTN8Y8424Flud7pcTZwdmsBUcKznobJ5STKC0UgVWopDHtVdgEkYxlP JWTv0bdMkAoPeb7D33L79mnqSMM5q3FYyoOWevhas/ES3RYHHeqhf6HUV/LR9nd/gyKE oiEjGGum7C4HjapFoJeH6xGljiOgxvSoGDtlLNeJwjGh1H9xJ52FaNclw18+G3HldaV1 5TQzIiWbZvWuJyJ07yxYBHxv8ZS9OzUjTcN775Qo+XlCBOXOY5khJ9+SBfjY0WNGvzUL eMyvucNYvdYwNdcB5OUL8qpljqu9o0DtdKrNHsFLoic6qQZQSdkoWsb9RWDLgq6O8Ha2 ZKOA==
MIME-Version: 1.0
X-Received: by 10.194.88.199 with SMTP id bi7mr20821433wjb.79.1405355059777; Mon, 14 Jul 2014 09:24:19 -0700 (PDT)
Received: by 10.195.11.132 with HTTP; Mon, 14 Jul 2014 09:24:19 -0700 (PDT)
In-Reply-To: <1404261479.5086.15.camel@acorde.it.uc3m.es>
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>
Date: Mon, 14 Jul 2014 09:24:19 -0700
Message-ID: <CAB_pk7C72DKXi+A2kgdMwCuOLVD7TNVHgWOx9k83ZigiTswLMQ@mail.gmail.com>
From: Rajeev Koodli <rajeev.koodli@gmail.com>
To: "Carlos J. Bernardos" <cjbc@it.uc3m.es>
Content-Type: multipart/alternative; boundary=047d7bf10b121f1c0204fe29b930
Archived-At: http://mailarchive.ietf.org/arch/msg/netext/94n_lK9reaOezaG_yu_UOr19uR4
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
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: Mon, 14 Jul 2014 16:24:25 -0000

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 am supportive of adding the Flow ID mobility option.

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
>