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

"Sri Gundavelli (sgundave)" <> Thu, 19 June 2014 13:46 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 398C51A0394 for <>; Thu, 19 Jun 2014 06:46:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -15.151
X-Spam-Status: No, score=-15.151 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id SJzS_fdDH9M6 for <>; Thu, 19 Jun 2014 06:46:08 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 1E8D71A01F3 for <>; Thu, 19 Jun 2014 06:46:08 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=17005; q=dns/txt; s=iport; t=1403185569; x=1404395169; h=from:to:subject:date:message-id:in-reply-to:mime-version; bh=T4xe/nVbgsgGhiSji+WFTxV5yL7UsrRlhPEn7ikVXMI=; b=IGDjGNJ0Nh8YXiQEs2gtCinyezIfuRRHujgQEsD64euQg+PhDXgMA2Ax 7fpAnHGNU5Y98InTVfB9iQdEUd3ENmXMmDretn9p39gmVR96g5j7tmoIG aWiSe8W07s3r6aUEFmDY2xC43zObUEQ/gR1U2VDFIlR9vx8jTJTD3NAJj c=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="5.01,507,1400025600"; d="scan'208,217";a="334243420"
Received: from ([]) by with ESMTP; 19 Jun 2014 13:46:08 +0000
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id s5JDk7XB023815 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 19 Jun 2014 13:46:07 GMT
Received: from ([]) by ([]) with mapi id 14.03.0123.003; Thu, 19 Jun 2014 08:46:06 -0500
From: "Sri Gundavelli (sgundave)" <>
To: "" <>, Hidetoshi Yokota <>, "" <>
Thread-Topic: [netext] [Fwd: I-D Action: draft-ietf-netext-pmipv6-flowmob-09.txt]
Thread-Index: AQHPi8TR0IEEZfjF1kSgp0XOwPNryQ==
Date: Thu, 19 Jun 2014 13:46:06 +0000
Message-ID: <>
In-Reply-To: <12960_1403166742_53A2A016_12960_14955_1_81C77F07008CA24F9783A98CFD706F711425DBD6@PEXCVZYM12.corporate.adroot.infra.ftgroup>
Accept-Language: en-US
Content-Language: en-US
user-agent: Microsoft-MacOutlook/
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_CFC8369913F9B1sgundaveciscocom_"
MIME-Version: 1.0
Subject: Re: [netext] [Fwd: I-D Action: draft-ietf-netext-pmipv6-flowmob-09.txt]
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: "Mailing list for discusion of extensions to network mobility protocol, i.e PMIP6. " <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 19 Jun 2014 13:46:11 -0000

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


From: "<>" <<>>
Date: Thursday, June 19, 2014 1:32 AM
To: Hidetoshi Yokota <<>>, "<>" <<>>
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...


De : netext [] De la part de Hidetoshi Yokota
Envoyé : jeudi 19 juin 2014 06:41
À :<>
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.



Hidetoshi Yokota

KDDI R&D Laboratories, Inc.<>

(2014/06/14 2:16), Carlos Jesús Bernardos Cano wrote:


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.




netext mailing list<>


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.