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

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

Hesham Soliman escribió:
> 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
>
>   
i would prefer that

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

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

Anyway, i see below that you are fine with this, so
> (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.
>
>   
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

>> 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.
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
> TCP. That's why the entire option is not allowed in the draft.
>
>   
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

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

>>    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.
>
>   
ok, it may be useful to state this (if nto already there and i missed it)

>>    - 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?
>
>   
I mean i the last paragraph quoted above, it reads:

      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,


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

Regards, marcelo

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