[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



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 at 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 at ietf.org
> https://www.ietf.org/mailman/listinfo/mext
>