Re: [MEXT] [WGLC] draft-ietf-mext-flow-binding-03

Benjamin Lim <benjamin.limck@sg.panasonic.com> Fri, 09 October 2009 05:40 UTC

Return-Path: <Benjamin.Limck@sg.panasonic.com>
X-Original-To: mext@core3.amsl.com
Delivered-To: mext@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 04AB13A6817 for <mext@core3.amsl.com>; Thu, 8 Oct 2009 22:40:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 2.369
X-Spam-Level: **
X-Spam-Status: No, score=2.369 tagged_above=-999 required=5 tests=[BAYES_20=-0.74, HELO_EQ_JP=1.244, HOST_EQ_JP=1.265, J_CHICKENPOX_73=0.6]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PlZU5Z1YxKHF for <mext@core3.amsl.com>; Thu, 8 Oct 2009 22:40:34 -0700 (PDT)
Received: from smtp.mei.co.jp (smtp.mei.co.jp [133.183.100.20]) by core3.amsl.com (Postfix) with ESMTP id 5F1BF3A67AC for <mext@ietf.org>; Thu, 8 Oct 2009 22:40:34 -0700 (PDT)
Received: from mail-gw.jp.panasonic.com ([157.8.1.145]) by smtp.mei.co.jp (8.12.11.20060614/3.7W/kc-maile13) with ESMTP id n995gHaR025821 for <mext@ietf.org>; Fri, 9 Oct 2009 14:42:17 +0900 (JST)
Received: from pslexc01.psl.local (localhost [127.0.0.1]) by mail.jp.panasonic.com (8.11.6p2/3.7W/kc-maili04) with ESMTP id n995gEG20088 for <mext@ietf.org>; Fri, 9 Oct 2009 14:42:15 +0900 (JST)
Received: from [10.81.113.115] ([10.81.113.115]) by pslexc01.psl.local with Microsoft SMTPSVC(6.0.3790.3959); Fri, 9 Oct 2009 13:38:04 +0800
Message-ID: <4ACECC69.2080601@sg.panasonic.com>
Date: Fri, 09 Oct 2009 13:38:49 +0800
From: Benjamin Lim <benjamin.limck@sg.panasonic.com>
User-Agent: Thunderbird 2.0.0.22 (Windows/20090605)
MIME-Version: 1.0
To: "mext@ietf.org" <mext@ietf.org>
References: <BF345F63074F8040B58C00A186FCA57F1C2655D2AA@NALASEXMB04.na.qualcomm.com>
In-Reply-To: <BF345F63074F8040B58C00A186FCA57F1C2655D2AA@NALASEXMB04.na.qualcomm.com>
X-Enigmail-Version: 0.96.0
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
X-OriginalArrivalTime: 09 Oct 2009 05:38:04.0640 (UTC) FILETIME=[AC516E00:01CA48A2]
Subject: Re: [MEXT] [WGLC] draft-ietf-mext-flow-binding-03
X-BeenThere: mext@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: Mobile IPv6 EXTensions WG <mext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/mext>, <mailto:mext-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mext>
List-Post: <mailto:mext@ietf.org>
List-Help: <mailto:mext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mext>, <mailto:mext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 09 Oct 2009 05:40:36 -0000

Hi,

I have reviewed the draft and it seems to be in good shape. Some
comments below.

Comment 1
--------------
Reference updates for
I-D.ietf-mext-nemo-v4traversal --> RFC 5555
I-D.ietf-monami6-multiplecoa --> RFC 5648

Comment 2
--------------
In section 4.4, it states
"A valid BID is required to make the entry "active".  If all of the BIDs
pointed to by a given entry are not valid BIDs in the binding cache, the
flow binding entry becomes "inactive", in other words it does not affect
data traffic."

FID-PRI     FID    Flow Description    BIDs    Action       A/I
    -------     ---    ----------------         ----      -------     ------
       10        4           TCP                 2      Forward     Active
       20        3       srcAddr=IPx       N/A     Discard     Active
       30        2       srcAddr=IPy        4      Forward     Inactive
       40        5           UDP               1,3     N-Cast      Active

                       Ordered Flow Binding Entries

However, for the above figure, in the second entry, N/A mean no BID
specified. If so, how can this be an active entry as there is no "valid
BID"? I find this confusing. There are two ways to approach this,

a) associate a BID with the discard action. This means that the
definition of discard action in 4.2 needs to be updated.
b) add more text in 4.4 to say that for discard action even if there is
no BID associated to it, that entry is treated as valid.

Comment 3
--------------
In section 5.3.2.1, the forward action is not defined in 4.2. From my
reading of 4.2, my understanding is that using n-cast and specifying a
single BID can be implied as the forward action.

<snip for 4.2>
> 2 n-cast.  This value indicates a request to send the flow to one or
> more addresses indicated in the Binding Reference sub-option. One or
> more BIDs MUST be associated with this Action.  If only one BID is
> associated with this action then it is essentially a request to
> forward packets to that CoA.  Care should be taken when the n-cast
> action is used as some transport layers may not be able to handle
> packet duplication and this can affect their performance.
</snip>

There are two ways to approach this,
a) define action forward
b) drop the text for action forward in 5.3.2.1.

I prefer b) as I feel n-cast covers the forward action.

Comment 4
--------------
In section 5.3.3, propose to reword the second paragraph to

<old  text>
> If the value of any of the FID fields included in the flow summary 
> option is not present in the list of flow binding entries for this 
> mobile node, the home agent MUST reject this flow binding refresh by 
> including a flow identification option in the BA, and setting the FID
>  field in the value of the FID that is not found and the Status field
>  to 135 (FID not found).
</old text>

<new text>
If the value of any of the FID fields included in the flow summary
option is not present in the list of flow binding entries for this
mobile node, the home agent MUST reject this flow binding refresh by
including a flow identification option in the BA for each FID that is
not found, and setting the FID field with the value of the FID and the
Status field to 135 (FID not found).
</new text>

Comment 5
--------------
In section 5.3.3, in the third paragraph

> If the value of the FID field is present in the mobile nodes list of 
> slow binding entries the, home agent SHOULD refresh the binding entry
> 
s/ slow/ flow

> identified by the FID without changing any of the other parameters 
> associated with it.

Regards,
Benjamin Lim