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

Hidetoshi Yokota <yokota@kddilabs.jp> Thu, 19 June 2014 04:41 UTC

Return-Path: <yokota@kddilabs.jp>
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 6411C1A020F for <netext@ietfa.amsl.com>; Wed, 18 Jun 2014 21:41:20 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -0.042
X-Spam-Level:
X-Spam-Status: No, score=-0.042 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.651, 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 5uvPjhn95hnW for <netext@ietfa.amsl.com>; Wed, 18 Jun 2014 21:41:18 -0700 (PDT)
Received: from mandala.kddilabs.jp (mandala.kddilabs.jp [IPv6:2001:200:601:12::16]) by ietfa.amsl.com (Postfix) with ESMTP id 099A21A01E5 for <netext@ietf.org>; Wed, 18 Jun 2014 21:41:17 -0700 (PDT)
Received: from localhost (mandala.kddilabs.jp [127.0.0.1]) by mandala.kddilabs.jp (Postfix) with ESMTP id 6CC151748161 for <netext@ietf.org>; Thu, 19 Jun 2014 13:41:13 +0900 (JST)
X-Virus-Scanned: amavisd-new at kddilabs.jp
Received: from mandala.kddilabs.jp ([127.0.0.1]) by localhost (mandala.kddilabs.jp [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BgEvA1C0dA6a for <netext@ietf.org>; Thu, 19 Jun 2014 13:41:11 +0900 (JST)
Received: from ultra.mip.kddilabs.jp (ultra.mip.kddilabs.jp [172.19.90.145]) by mandala.kddilabs.jp (Postfix) with ESMTP id 312661748169 for <netext@ietf.org>; Thu, 19 Jun 2014 13:41:00 +0900 (JST)
Received: from [127.0.0.1] (dhcp197.west-4f.cn.kddilabs.jp [172.19.124.197]) by ultra.mip.kddilabs.jp (Postfix) with ESMTP id 7D2B41BAAA for <netext@ietf.org>; Thu, 19 Jun 2014 13:25:58 +0900 (JST)
Message-ID: <53A269DB.6050504@kddilabs.jp>
Date: Thu, 19 Jun 2014 13:40:59 +0900
From: Hidetoshi Yokota <yokota@kddilabs.jp>
User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: "netext@ietf.org" <netext@ietf.org>
References: <1402679783.4063.11.camel@acorde.it.uc3m.es>
In-Reply-To: <1402679783.4063.11.camel@acorde.it.uc3m.es>
Content-Type: multipart/alternative; boundary="------------040605050105090205040705"
Archived-At: http://mailarchive.ietf.org/arch/msg/netext/B-ugL8-NJ4aE8t71Gr5sCEnpOJ4
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: Thu, 19 Jun 2014 04:41:20 -0000

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