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

[marcelo bagnulo braun <[e-mail]>]

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.

      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?

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


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?

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.


   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

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?

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

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

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.

   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?

   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.

   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?

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

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?