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

George Tsirtsis <tsirtsis@googlemail.com> Wed, 21 October 2009 18:27 UTC

Return-Path: <tsirtsis@googlemail.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 7F7543A69DB for <mext@core3.amsl.com>; Wed, 21 Oct 2009 11:27:39 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.677
X-Spam-Level:
X-Spam-Status: No, score=-1.677 tagged_above=-999 required=5 tests=[AWL=-0.300, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, 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 vR2MjkBxeiwL for <mext@core3.amsl.com>; Wed, 21 Oct 2009 11:27:38 -0700 (PDT)
Received: from mail-yx0-f192.google.com (mail-yx0-f192.google.com [209.85.210.192]) by core3.amsl.com (Postfix) with ESMTP id 686FC3A69DA for <mext@ietf.org>; Wed, 21 Oct 2009 11:27:38 -0700 (PDT)
Received: by yxe30 with SMTP id 30so9240085yxe.29 for <mext@ietf.org>; Wed, 21 Oct 2009 11:27:44 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=Bq1tBQhuxF5J39Vv+zyHLPztGk+MoX0YDoKo765PI/Y=; b=vQpxwQGu7CgZN2Te4ptlEq0PtkeBxcgyx5FKoTeS1Ol3Hh/xKMy48YAAOLtH6nnc7z tTSXol5nRxhs2BJOfnRlrT+P4xAkYYPxk3G0yzaisxFw9EFUdIa46/Ck8oisN2Brop2m R101z/jG/4WKbeBVCjwPEe/9sAqqH67C6y/cs=
DomainKey-Signature: a=rsa-sha1; c=nofws; d=googlemail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=UvNtnX4yMN+S8eLgbhDmurq9GgTM6iBLXbRlh6LgWFwF/2NpadD00WfkoK0Ycft1qP 2UPue/Y8NcqnfWG/abnVZRoti0I0mri5qvoYdz3oXTPXdM+q/OQjm5f6cWsaYThXJT/t yqA9smnOFFRB8MtREIBGVqrZ11y05u3CqL3hk=
MIME-Version: 1.0
Received: by 10.239.139.84 with SMTP id s20mr679986hbs.110.1256149663097; Wed, 21 Oct 2009 11:27:43 -0700 (PDT)
In-Reply-To: <4ACECC69.2080601@sg.panasonic.com>
References: <BF345F63074F8040B58C00A186FCA57F1C2655D2AA@NALASEXMB04.na.qualcomm.com> <4ACECC69.2080601@sg.panasonic.com>
Date: Wed, 21 Oct 2009 19:27:42 +0100
Message-ID: <d3886a520910211127h1a457f9cma623426673b890b2@mail.gmail.com>
From: George Tsirtsis <tsirtsis@googlemail.com>
To: Benjamin Lim <benjamin.limck@sg.panasonic.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Cc: "mext@ietf.org" <mext@ietf.org>
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: Wed, 21 Oct 2009 18:27:39 -0000

Thanks a lot Ben...all comments below resolved....but also see inline.

Geroge

On Fri, Oct 9, 2009 at 6:38 AM, Benjamin Lim
<benjamin.limck@sg.panasonic.com> wrote:
> 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
>

GT> Done.

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

GT> Yes, Dave caught that one too. I will do (b).

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

GT> Yes true. Fixed.


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

GT> I agree. done.

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

GT> done.

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

GT> done

>> identified by the FID without changing any of the other parameters
>> associated with it.
>
> Regards,
> Benjamin Lim
> _______________________________________________
> MEXT mailing list
> MEXT@ietf.org
> https://www.ietf.org/mailman/listinfo/mext
>