Re: [MEXT] about draft-ietf-mext-flow-binding-02.txt

[Hesham Soliman <[e-mail]>]

Thanks for the detailed review. Some answers inline


On 16/05/09 9:46 AM, "marcelo bagnulo braun" <[e-mail]> wrote:

> Hi,
> 
> Please find my comments about draft-ietf-mext-flow-binding-02.txt.
> 
> 
> 
>       Flow binding: An entry in the list of flow binding associated with
>       a given mobile node.
> 
> circular definition, please rephrase.

=> ok.

> 
>       BID-PRI
> 
>          This is a 7-bit field placing each BID to a relative priority
>          with other registered BIDs.  Value "0" is reserved for
>          implementation of [I-D.ietf-monami6-multiplecoa] that do not
>          support this specification.  A higher number in this field
>          indicates lower priority,
> 
> Why is that? Is there a reason for having the higher value of a field
> called BID PRI to mean _lower_ priority or are we just trying hard to be
> counter intuitive?

=> I think George added this in a way to be consistent with the PRI field,
which you comment on below. Why is the PRI field that way? I don't know :) I
guess I did that one day when I was feeling counter intuitive. We can
reverse this

> 
> same comment applies to:
> 
>       FID-PRI
> 
>          This is an 8-bit priority field to indicate the priority of a
>          particular option.  This field is needed in cases where two
>          different flow descriptions in two different options overlap.
>          The priority field decides which policy should be in those
>          cases.  A lower number in this field indicates a higher
>          priority.
> 
> Later the drafts reads:
> 
>    The following values are reserved for the PRO field in this option:
> 
>       0 Add a flow binding
> 
>       1 Modify a flow binding
> 
> I haven't read the whole draft yet, but wouldn't make sense to avoid
> this option. I mean, if the FID is new, then we create a new binding and
> if the FID already exists, then it is a modification. I mean, the
> problem with doing the approach described is that it has the potential
> of creating contradictory situations... for instance what happens if we
> receive an option with a value of 0 in the PRO field but there is no
> existing binding with the BID?

=> I think you mean 1 not 0. It would be an error, which illustrates the
advantage of this, i.e. It catches any mismatch between the MN and HA.

(I mean, i understand that the flow
> binding messages are atomic i.e. that each time w new one is received it
> not an incremental change from the previous one, but it contains the
> complete information about the binding, correct? If that is the case, we
> better simply create a new one, even if the sender thinks this is a
> modifciation, since the msg actually provides all the information for
> the creation of the flow binding, correct?)

=> It can be done this way if we don't care about catching mismatches. This
orginally contained explicit deletes as well, which we removed. I know that
it now seems redundant with only those two operations.

> 
> 
> later on the draft reads:
> 
>       1 Forward.  This value indicates a request to forward a flow to
>       the address indicated in the Binding Reference sub-option.  A
>       single BID MUST be associated with this Action.
> ...
> 
>       3 n-cast.  This value indicates a request to replicate the flow to
>       several addresses indicated in the Binding Reference sub-option.
>       One or more BIDs MUST be associated with this Action.
> 
> 
> What is the difference between a n-cast value with a single BID and a
> Forward option? couldn't we just live with the n-cast option? (if it has
> only one BID, it has the same behaviour as the forward option?

=> Yes we could.

> 
> LAter on it reads:
> 
>    It should be noted that per-packet load balancing may have negative
>    impacts on TCP congestion avoidance mechanisms as it is desirable to
>    maintain order between packets belonging to the same TCP connection.
>    This behaviour is specified in RFC2702 [RFC2702].  Other negative
>    impacts are also foreseen for other types of real time connections
>    due to the potential variations in RTT between packets.  Hence per-
>    packet load balancing is not currently supported in this extension.
> 
> I fully agree with this, but i fail to see why this is the correct place
> to mention this. It probably belongs to somewhere else. Probably, we
> should make even a stronger statement, i.e. the flow bindings separating
> the packets of a TCP connection SHOULD NOT be used.

=> Ok about placement. SHOULD NOT? I think this is a MUST NOT. Also, it
affects any secure traffic with replay attack prevention. So it's not just
TCP. That's why the entire option is not allowed in the draft.

> 
> 
>    The binding identifier option, defined in
>    [I-D.ietf-monami6-multiplecoa], registering a given BID which is then
>    indicated in the Binding Reference sub-option, MUST be either defined
>    in the same or earlier BU from the one including the binding
>    reference sub-option.
> 
> I think what this sentence means, but I fail to parse it properly. I
> would suggest rephrasing

=> ok.

> 
> 4.3.  Flow Identification Summary Mobility Option
> 
>    TBD
> 
> I guess more text is needed here...
> 
> later on...
> 
>    The BIDs included in a given entry point to a corresponding entry in
>    the binding cache for the purpose of identifying a care-of address.
> 
> is there a verb missing in this sentence?

=> Yup needs rewording.

> 
> later on
> 
>    Depending on the Action parameter in a given entry a valid BID is
>    required to make the entry "active".
> 
> How is that dependent of the action paramter?
> The text tha follows, seem to imply that an entry is active or inactvie
> depending on the BID not on the actions...

=> Agreed, this is left over and erroneous.

> 
> later on...
> 
>                        BID-PRI          BID        CoA
>                       ---------         ---        ---
>                           20             1         IP1
>                           30             3         IP2
>                           30             2         IP3
> 
>                             Ordered BID Entries
> 
> I would suggest moving this table right after the table describing the
> Ordered Flow Binding Entries

=> ok.

> 
> 5.2.  Mobile Node Considerations
> 
>    This specification allows the mobile node to maintain several
>    bindings in its home agent and to direct packets to different care-of
>    addresses according to flow bindings.
> 
> I understnad that not only the HA maintains the bidnings but also the CN
> and the MAPs, so i think this should be included here.

=> Agreed.

> 
>    The home agent list of flow bindings is manipulated by the mobile
>    node, via flow identification and flow summary options included in
>    binding update messages.
> 
> similar comment here. It is not only the HA list of bindings, but also
> the CN and MAP list of bindings, right?

=> Yes.

> 
>    All flow binding state MUST be refreshed in every binding update the
>    mobile node sends.  Any previously registered flow binding that is
>    not included in a given binding update will be deleted.  So, any flow
>    bindings that are not added or modified by a flow identification
>    option, but have previously registered and need to be maintained MUST
>    be included in a flow summary option.  Only one flow summary option
>    can be included in a given binding update.
> 
> So, i really fail to see why we need the PRO bits. I mean, if every tome
> we sent a BU it will contain all the info about all the bindings, it is
> irrelevant if the binding is being created or modified in the options,
> since we are including all the information anyway.

=> Yeah, I think you have a point about this. Like I said earlier, it used
to work different and contain more actions but I think you're right.

> 
>    Note that any inactive flow bindings, i.e., flow bindings without
>    associated BIDs that are marked as Inactive in the list of flow
>    binding entries (see Section 4.4, MUST also be refreshed, or
>    modified, to be maintained.  If they are not included in a BU they
>    will be removed.
> 
> closing bracket missing
> 
> 5.2.4.  Removing flow bindings
> 
>    Removal of flow binging entries is performed implicitly by omission
>    of a given FID from a binding update.
> 
>    To remove a flow binding the MN simply sends a binding update that
>    includes flow identification and flow summary options for all the
>    FIDs that need to be refreshed, modified, or added, and simply omits
>    any FIDs that need to be removed.
> 
> what if the MN sneds a BUt wihtout the Flow binding option? are all the
> flow bidings removed?

=> Without any FIDs? Yes they're all removed.

> 
>    - if the Action indicates 'n-cast',
> 
>       If the Binding reference sub-option is not included, the home
>       agent MUST reject this flow binding add request by copying the
>       flow identification option in the BA, and setting the Status field
>       to 129 (Flow identification option poorly formed).
> 
>       If the Binding Reference sub-option is present and includes BIDs
>       that are not present in the binding cache of the mobile node the
>       home agent MUST reject this flow binding add request by copying
>       the flow identification option in the BA, and setting the Status
>       field to TBD (BID not known).
> 
>       If the Binding Reference sub-option is present and includes one or
>       more BIDs, and the BIDs exist in the mobile node's binding cache,
> 
> all the bods must exist? what if some exists and some don't?

=> What do you mean? You mean on a per FID or on aggregate?

> 
> later on...
> 
>    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 modify
>    request
> 
> is this option only carried in a modify request? I understood that also
> could be carried in an add request, correct?

=> Yes.

Hesham

>