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

From: marcelo bagnulo braun <[email-masked]>
Date: Sat, 16 May 2009 01:46:20 +0200

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?

---

From: Hesham Soliman <[email-masked]>
Date: Sat, 16 May 2009 13:58:26 +1000

Thanks for the detailed review. Some answers inline

> circular definition, please rephrase.

=> ok.

> called BID PRI to mean _lower_ priority or are we just trying hard to be

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

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

> only one BID, it has the same behaviour as the forward option?

=> Yes we could.

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

> I think what this sentence means, but I fail to parse it properly. I

=> ok.

> is there a verb missing in this sentence?

=> Yup needs rewording.

> depending on the BID not on the actions...

=> Agreed, this is left over and erroneous.

>                        BID-PRI          BID        CoA

=> ok.

> and the MAPs, so i think this should be included here.

=> Agreed.

> the CN and MAP list of bindings, right?

=> Yes.

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

> what if the MN sneds a BUt wihtout the Flow binding option? are all the

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

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

> could be carried in an add request, correct?

=> Yes.

Hesham

---

From: marcelo bagnulo braun <[email-masked]>
Date: Sat, 16 May 2009 13:59:14 +0200

> guess I did that one day when I was feeling counter intuitive. We can
i would prefer that

> advantage of this, i.e. It catches any mismatch between the MN and HA.

:-)
but one would expect people implementing this are smarter than me

Anyway, i see below that you are fine with this, so

>> only one BID, it has the same behaviour as the forward option?
Again, if there is not special value in having the forward and n-cast 
separated, i would simplify it and have a single option for these, since 
it seems simpler

> => Ok about placement. SHOULD NOT? I think this is a MUST NOT.
don't have a strong opinion about this.

>  Also, it
> affects any secure traffic with replay attack prevention.
right
so we need a statement not only about TCP. how would we scope the 
statement then?
>  So it's not just
that makes sense to me, just that in the case of TCP, the performance is 
worse, so i am dubious if we need to use a MUST NOT or simply a SHOULD NOT

> to work different and contain more actions but I think you're right.
ok

> => Without any FIDs? Yes they're all removed.
ok, it may be useful to state this (if nto already there and i missed it)

> => What do you mean? You mean on a per FID or on aggregate?
I mean i the last paragraph quoted above, it reads:

What if some BID exist and  some other BIDs don't, how is the option 
processed?

Regards, marcelo