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

Rajeev Koodli <rajeev.koodli@gmail.com> Mon, 23 June 2014 19:37 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 6877F1A037F for <netext@ietfa.amsl.com>; Mon, 23 Jun 2014 12:37:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.9
X-Spam-Level:
X-Spam-Status: No, score=0.9 tagged_above=-999 required=5 tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FREEMAIL_REPLY=1, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=no
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 zlG4A0sTvZ01 for <netext@ietfa.amsl.com>; Mon, 23 Jun 2014 12:37:38 -0700 (PDT)
Received: from mail-wi0-x232.google.com (mail-wi0-x232.google.com [IPv6:2a00:1450:400c:c05::232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 7C5DA1A02A3 for <netext@ietf.org>; Mon, 23 Jun 2014 12:37:37 -0700 (PDT)
Received: by mail-wi0-f178.google.com with SMTP id n15so4724209wiw.5 for <netext@ietf.org>; Mon, 23 Jun 2014 12:37:36 -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=eOgFxObdXWLgaSLLZys2Fl7nDwYoo87DOuiOpeNS1v8=; b=fJdKc/wxfvukUbzxd8QwuvB+Mbzx4TLnnq9QCSERI//Hbf7scP54woUJIJXSt9kzyH KHgKeiVVmmY3Cf1bBuiOK0vAgp9rPaQVV3up5nKMMQi5o40JsbIEzuB+TrMs0QJrqAdi 08/SxudNdlwGMg3vwYas4Fkr9fU076UoF9amnpERSb1ygPAqwFxWbs2HjQ935JgU9bA+ AVxmD4RWufl1WG4odSk4koFa0maq+bLE34xw07caiMHNvxbHmw//Prq6qIqLcQISWJW8 xO/SEIpERz2DeNvW6udzt6g/a65u1/JBfxzomPi+sJN8Xbn3u7OtAEBVemD7B14wwf8t Ouog==
MIME-Version: 1.0
X-Received: by 10.194.88.199 with SMTP id bi7mr30879722wjb.79.1403552256062; Mon, 23 Jun 2014 12:37:36 -0700 (PDT)
Received: by 10.195.11.132 with HTTP; Mon, 23 Jun 2014 12:37:36 -0700 (PDT)
In-Reply-To: <CFC83699.13F9B1%sgundave@cisco.com>
References: <12960_1403166742_53A2A016_12960_14955_1_81C77F07008CA24F9783A98CFD706F711425DBD6@PEXCVZYM12.corporate.adroot.infra.ftgroup> <CFC83699.13F9B1%sgundave@cisco.com>
Date: Mon, 23 Jun 2014 12:37:36 -0700
Message-ID: <CAB_pk7DkSvxs3aDc8gV8M90qVsUf7vU_3E9fX9fXFZ8egamK1Q@mail.gmail.com>
From: Rajeev Koodli <rajeev.koodli@gmail.com>
To: "Sri Gundavelli (sgundave)" <sgundave@cisco.com>
Content-Type: multipart/alternative; boundary=047d7bf10b12a5799404fc85f970
Archived-At: http://mailarchive.ietf.org/arch/msg/netext/lqUvmpgpCMzVtFHViEx2IpY77Hs
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, 23 Jun 2014 19:37:40 -0000

Yes, but just to be clear: The Flow Mobility ID defines FMI/FMA messages
which use the same format as UPN with the new Code values.

-Rajeev



On Thu, Jun 19, 2014 at 6:46 AM, Sri Gundavelli (sgundave) <
sgundave@cisco.com> wrote:

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