Subject: Re: [MEXT] flow binding draft 2

From: Christian Kaas-Petersen <[email-masked]>
Date: Fri, 1 May 2009 14:02:51 +0000 (GMT)

The explanations are fine.  I hope they in one form or another will
find a way into the document.

When reading the first two entries of chapter 3, it appears to me
the term "flow" references "flow description", and "flow description"
relies on "flow" for its definition.  I should like to suggest the
following definitions, where flow description is defined without
reference to flow.  The following is input to the editing process.

  flow description: A rule which can be applied to an IP packet.
        The rule may compare for example source address,
        destination port, protocol number, DSCP value, or other
        information from the packet with predefined values.
        The result of applying the rule is MATCH or NO-MATCH.

  flow: A subset of IP packets from the total set of IP packet
        handled by a node; the subset is identified by applying
        a flow description to each IP packet.

  flow identifier: A number (16-bit unsigned integer).

  flow binding: A three-tuple consisting of a flow identifier, a
        flow description, and an action.  An IP packet for which
        the rule of the flow description gives the result MATCH, will
        be processed according to the action.

Christian

--- Den fre 1/5/09 skrev George Tsirtsis <[email-masked]>:

Fra: George Tsirtsis <[email-masked]>
Emne: Re: [MEXT] flow binding draft 2
Til: "Christian Kaas-Petersen" <[email-masked]>
Cc: [email-masked]
Dato: fredag 1. maj 2009 14.04

Hi Christian,

Wow, very quick turnaround, and a good review, thanks!

Marcelo, are you counting? :-)

See comments inline...

On Fri, May 1, 2009 at 12:39 PM, Christian Kaas-Petersen
<[email-masked]> wrote:
>
> Having read draft-ietf-mext-flow-binding-02, I should like to be
> informed about two design rationales.
>
> The first is related to the PRO field in the Flow Identification Mobility
> Option.  The mobile node must explicitly inform if it is an Add or a
> Modify operation; the mobile node does implicitly inform if it is a
> delete operation.  In principle there is no need for the PRO field.
> There are three cases.
>
> (a) If a FID-value is absent in BU and
>    present in Flow Binding List        => remove
> (b) If a FID-value is present in BU and
>    absent in Flow Binding List         => add
> (c) If a FID-value is present in BU and
>    present in Flow Binding List        => modify
>
> With these cases PRO field can be removed.  Alternatively, one could take
> the other extreme, also explicitly naming the FID-values to be removed.
>

GT> You are right that instead of ADD/MOFIDY we can always overwrite
existing FID with new FIDs when they already exists and add them when
the do not exists.  The reason, however, we left the ADD/MODIFY is to
make it easier for the MN and HA to catch errors e.g., cases where the
MN things its adding something new but the FID actually already
exists. Or the case where the MN thinks its modifying something but
the HA has no record of that.
Unlike ADD and MODIFY, the REMOVE value is creating more trouble than
it is worth. Given the soft-state nature of the protocol it is
important to refresh all FIDs in all BUs, so if an FID is not included
in a BU it MUST be removed. The PRO=REMOVE, then creates two ways of
doing the same thing (remove FID by not including it in BU, or by
setting PRO=REMOVE), which is something we wanted to avoid

GT>> Again, I think your proposal to drop PRO is not unreasonable, it
is just that RPO field provides an error detection functions which we
think could be useful.

> The document has made an in-between choice.  I'm not suggesing a change,
> I'm looking for an explanation.
>

GT> I hope the above satisfies you?

> The other item relates to what in section 4.4 is denoted a "valid BID".
> When a BU wants to insert a FID-entry, and this FID-entry refers to one
> or more BID-values, all of those BID values must be found in the
> BID Entries List, and thus an entry will always achieve the Active state.
> However, at later times BID-entries may be removed, and so a state may
> change to Inactive.  What is reason for a state not being allowed
> Inactive to start with?  Again, I'm just looking for an explanation.
>

GT> It is not clear why the MN would create an entry that is inactive
to begin with. It seems to me that the entry can always be created
when the MN actually needs it. The reason Inactive FIDs are defined in
the draft is to handle the case where BIDs are subsequently removed.
Without the inactive FID concept this would mean an implicit removal
of FIDs pointing to the removed BID. That again could cause confusion
since it would create two ways of removing an FID entries (remove FID
by not including it in BU, or by removing all of the BIDs associated
with it)

GT> So, we could allow the MN to add an inactive FID entry, but the
added complication does not seem to provide useful flexibility.

> A few minor points.

GT> All of your minor points are welcome and will be corrected in the
next version of the draft.

>  * Abstract: uses the word "peer" as a short term for correspondent node,
>   home agent, and mobility anchor point.  In general, a mobile node's
>   peers are all the nodes with which it has TCP/UDP sessions.  I think
>   the term "peer" has a too wide interpretation.
>
>  * Section 4.1, in the description of BID-PRI field, the words "a higher
>   number" assumes reading the 7-bit field as an unsigned integer.
>
>  * Section 4.2, in FID description, 8-bit should be 16-bit.
>
>  * Section 4.2, in 1 Forward, a forward reference for Binding Reference
>   sub-option would be helpful when reading this document first time.
>
>  * Section 4.3, in Option Type, I think a copy from the section 4.2.1.
>
>  * Section 4.4, para 2, one of the words "change" or "modify" should be
>   enough.
>
>  * Section 4.4, Action bullet: "PRO field" to be replaced with
>   "Action field".
>
>  * Section 4.4, para just above Ordered Flow Binding Entries, "three flow
>   bindings" to become "four flow bindings".
>
> Christian

      Trænger du til at se det store billede? Kelkoo giver dig gode tilbud på LCD TV! Se her http://dk.yahoo.com/r/pat/lcd

---

From: Hesham Soliman <[email-masked]>
Date: Sat, 02 May 2009 00:19:56 +1000

It's always good to remove circular definitions. I'm fine with that.

Hesham

On 2/05/09 12:02 AM, "Christian Kaas-Petersen" <[email-masked]>
wrote:

>       Trænger du til at se det store billede? Kelkoo giver dig gode tilbud på
> LCD TV! Se her http://dk.yahoo.com/r/pat/lcd
> _______________________________________________
> MEXT mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mext

---

From: George Tsirtsis <[email-masked]>
Date: Fri, 1 May 2009 15:38:51 +0100

yes, sounds good. Thanks Christian.
George