Re: [MEXT] [WGLC] draft-ietf-mext-flow-binding-03

[Hesham Soliman <[e-mail]>]

Hi Raj, 

Thanks for the comments. Until the draft is updated (we discussed the
comments so far and George is going to propose text and do the new rev),
I'll give a quick overview comment in response.

You have two main comments that manifest themselves in various forms below:
1. Questioning the need for PRI
2. Questioning the need to include existing bindings in the BU to refresh
them. 

Answers:
1. We have to have a PRI for the HA to work out the priosirities of
bindings. IFF two PRI values are the same then the HA will select one of
them based on means out of our scope. Removing the PRI is essentially asking
the MN to "hope" that the HA arranges them properly.

2. MIPv6 basically allows one BU to completely overwrite the previous BU.
This makes the implementation simple. Hence, if you don't include something
in a BU it is removed. You could argue for a different approach but I think
you'll find that it's more complex and likely more BW consuming. This way
it's fairly easy to keep things in sync between the MN and HA.

Regarding how the HA knows if it's an "add" or "modify" operation, it
doesn't need to, when it receives an FID it checks if it already exists, if
yes then it overwrites it with the new one, if no then it creates a new one.
Simple! 


George will respond to your comments about inactive bindings.

Hesham

On 10/10/09 8:36 AM, "[e-mail]" <[e-mail]>
wrote:

> 
> Hello,
> 
> The document needs at least another revision before it would be ready
> to be sent to the IESG.
> 
> Below is a review of the Flow bindings I-D
> <draft-ietf-mext-flow-binding-03>:
> 
> - Update reference DSMIPv6 [I-D.ietf-mext-nemo-v4traversal] to RFC5555
> 
> - Update reference [I-D.ietf-monami6-multiplecoa] to RFC5648
> 
>>   In this document, a flow is defined as a set of IP packets matching a
>>   flow descriptor.
> 
> The definition in the terminology section is better suited to describe
> a flow. A flow can be identified by a flow descriptor but that is not
> the definition of what a flow is.
> 
>>   This specification, however, does not define flow
>>   descriptors and it is assumed that one or more ways of defining flow
>>   descriptors are going to be defined in other specifications.
> 
> The specification now exists and hence should be referenced, i.e I-D:
> draft-ietf-mext-binary-ts
> 
> 
>>     Flow Identifier: An unsigned integer.
> 
> This definition really does not explain what a Flow ID is. Suggested
> text: "A flow identifier uniquely identifies a flow associated with an
> MN. It is generated by the MN and is cached in the flow binding list
> maintained by the MN, HA, CN or MAP."
> 
>>     BID-PRI
>> 
>>         This is a 7-bit unsigned integer placing each BID to a relative
>>         priority with other registered BIDs.  Value "0" is reserved.  A
>>         lower number in this field indicates higher priority, while
>>         BIDs with the same BID-PRI value have equal priority.  This is
>>         consistent with current practice in packet classifiers.
> 
> I dont see the value in having a priority associated with the
> BID. This I-D proposes the creation of an ordered BID list. The reason
> for having an ordered list is to process the packet with the BID which
> has the highest priority in case there is no match for any Flow
> ID. This is not required. The HA can decide to forward it to any CoA
> based on some default binding cache entry or policy that it has.
> I would suggest not modifying the Binding Identifier mobility option
> as specified in RFC5648.
> 
>>      FID-PRI
>> 
>>         This is an unsigned 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.
> 
> I guess multiple FIDs can have the same priority, right? Is there a
> default value in case no priority is assigned by the MN? Or because
> you are creating an ordered list of FIDs, the priority for each FID is
> unique? Also it would be good to reserve priority 0 for future use.
> Some additional text to clarify this might be useful.
> 
>>      Action
>> 
>>         This field specifies the action that needs to be taken by the
>>         receiver of the binding update containing the flow
>>         identification option.  The details of these requests are
>>         discussed below.
> 
> - s/This field specifies/This 8 bit unsigned integer field specifies
> - Can you include the values defined for the actions further below in
>   the section immediately below the Action field definition? Makes
>   reading easier.
> - a/Action value 0 is reserved.
> - In the example of Flow binding entries shown in Sec 4.4, the action
>   field also includes Forward (in addition to discard and
>   n-cast). Does this imply that not indicating anything in the Action
>   field equates to Forwarding? Or should there be a separate value
>   reserved for forwarding as well? Why not be explicit and just assign
>   a value for forwarding as well.
> 
>> Rsvd
>> Status
> 
> Specify these are 8 bit unsigned integer fields just to be explicit.
> 
>>   A number of sub-options can follow the option defined in this
>>   section.
> 
> Rephrase as : A number of sub-options can follow the Flow
> Identification mobility option defined in this section.
> 
>> 4.2.1.  Binding Reference Sub-option
>>  This section introduces the Binding Reference sub-option, which may
>>   be included in the Flow identification option.
> 
> Is it really a MAY? If the MN is adding a new flow ID, the binding
> reference sub-option is mandatory especially if the action is set to
> Forward. From the processing rules defined in Sec 5.3.2.1 it seems
> that the binding reference sub-option MUST be included and SHOULD have
> a valid BID.
> 
> Adding a flow ID that does not have a valid matching BID in the BC
> does not make much sense.
> 
> s/which may be included in the Flow identification option./which MUST
> be included in the Flow identification mobility option.
> 
>> 4.2.2.  Flow Description Sub-option
>>      Sub-opt Type
>> 
>>         Indicates the Sub-option type.  For the flow description sub-
>>         option, this field SHOULD be set to one of the FD types defined
>>         below.
> 
> - Move the text defining the suboptions to follow the definition of the
>   suboption.
> - s/Indicates the/8 bit unsigned integer which indicates the
> - What is really implied by: "17-32 reserved for Flow Description
>   formats"?
>   Do these values have any predefined flow descriptions? Or does it
>   imply that these values cannot be used by the MN?
> 
>>      Flow Description
>> 
>>         The flow description corresponding to the type indicated by the
>>         Sub-opt Type field.  Flow description is out of scope of this
>>         document.
> 
> In I-D: draft-ietf-mext-binary-ts-00 Sec 3 says "
>    [I-D.ietf-mext-flow-binding] defines the format for the traffic
>    selector sub-option."
> 
> There is no traffic selector sub-option defined in the flow-binding
> ID. The closest match I guess is the flow description field in the
> flow-description sub-option. Revise the flow description text and also
> check to see if the format of the traffic selector options fit into
> the flow description field.
> 
>> 4.3.  Flow Identification Summary Mobility Option
> 
> Is this option really required? The only reason I can gather from the
> I-D is that every BU MUST include a list of all the FIDs that have
> been added otheriwse they will be deleted. And hence the summary
> option is an optimized way of sending a list of all the FIDs.
> 
>>   The Flow Identification Summary Mobility option includes one or more
>>   flow identifiers (FIDs) for the purpose of refresing their state
> 
> Why do you need to refresh the state of the FIDs? They do not have a
> lifetime. If a BU sent to the HA for example were to deprecate a BID
> (interface/CoA no longer being available), the BU could also include
> the FID options to modify the FIDs which use that BID. If an MN is
> simply sending a BU to refresh its lifetime associated with one or
> more CoAs, there is no reason to include the FID summary mobility
> option.
> 
>>   The binding cache was then
>>   extended by [I-D.ietf-monami6-multiplecoa] to include more than one
>>   care-of addresses and to associate each of them with a Binding
>>   Identifier (BID).
> 
> s/The binding cache was then/The binding cache has been
> Also reference the MCoA RFC instead.
> 
>>      *  Active/Inactive flag: This flag indicates whether the entry is
>>         active or inactive.
> 
> What does it mean when the entry is set as Inactive? Does it imply
> that the BID is invalid? In the example shown in this section what
> does the 3rd entry which is inactive imply? The MN does not specify in
> the FID option sent in the BU whether a flow binding is active or
> inactive. So how is this flag set and under what conditions?
> 
>>   If all of the
>>   BIDs pointed to by a given entry are not valid BIDs in the binding
>>   cache, the flow binding entry becomes "inactive", in other words it
>>   does not affect data traffic.
> 
> If a BID is not valid, then the entry in the flow binding list should
> be deprecated. Why would you have an entry in the flow binding list
> when there is no valid BID in the BC?
> Invalid BIDs should be treated as an error case. In the protocol
> operations section the ID says that the HA will reject the addition of
> a FID if the BID specified in it is invalid.
> 
>>  The third entry is marked as Inactive since the BID 4 does not exist
>>   in the ordered list of BID entries below.  Inactive entries do not
>>   affect traffic, i.e., packets are not matched against them.
> 
> See above reasoning. No reason to have such an entry. Should be viewed
> as an error case.
> 
>> Ordered BID Entries
> 
> As stated earlier as well, there is really no need to order the
> BIDs. Assigning a priority to the BIDs by modifying the BID Mbility
> option is not required. Flow mobility works without assigning
> priorities to BIDs.
> 
>>   Finally any remaining packets that do not match any of the entries
>>   above will be simply forwarded to the care-of address indicated by
>>   the highest order BID in the table below.
> 
> For the case where there is no matching FID, the HA/CN/MAP can handle
> it based on policy or forward to a default CoA.
> 
>>   As indicated earlier the
>>   flow description itself is defined in another document.
> 
> Reference draft-ietf-mext-binary-ts
> 
>> 5.1.1.  Preferred Care-of address
>> 
>>   Any node that supports this specification MUST maintain an ordered
>>   list of care-of addresses for each mobile node it maintains a list of
>>   flow bindings for.  The ordered list of care-of addresses is built
>>   based on the BID-PRI field of the Binding Identifier option (see
>>   Section 4.1).
>> 
>>   The ordered list of BIDs is used to determine how to forward a packet
>>   to a given mobile node when the packet does not match any of the flow
>>   binding entries defined in Section 4.4.  A packet that does not match
>>   any of the flow binding entries SHOULD be forwarded to the care-of
>>   address identified by the BID with the highest priority i.e., lowest
>>   BID-PRI value.
> 
> See reasons above why BID-PRI is not needed and how packets which do
> not match any FIDs can be handled in a more simpler/implementation
> specific manner.
> 
>>   In other words, two flow
>>   identification options in the same message can not be about the same
>>   flow binding.
> 
> s/can not be/MUST not be
> 
>>   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.
> 
> This is suboptimal. Why do you need to include the FID options in
> every BU. The MN may be sending a BU to refresh the lifetime of a CoA
> or adding a new CoA etc. Requiring that FID options be carried in
> every BU even when the FID option does not have any implication is
> simply an overhead. Additionally there is no reason to keep refreshing
> FIDs.
> 
>>   When the mobile node sends a binding update it MUST refresh all flow
>>   bindings it wants to maintain even if it does not want to change any
>>   of their parameters.
> 
> Why?
> 
>> 5.2.4.  Removing flow bindings
>> 
>>   Removal of flow binging entries is performed implicitly by omission
>>   of a given FID from a binding update.
> 
> It would be better to have an explicit flag in the Flow ID mobility
> option whether the operation is an add/modify/delete rather than this
> implicit mechanism. Also you would avoid having to send the flow
> summary option as a means to deprecate FIDs.
> 
>>   When all the BIDs associated with a flow binding are removed, the
>>   flow binding MUST be marked as inactive in the list of flow binding
>>   entries as shown in Section 4.4.
> 
> If all BIDs are removed and the rule is other than discard, the flow
> binding itself should be deprecated. Why keep such a flow binding?
> 
>>   If the FID field of the flow identification option is already present
>>   in the list of flow binding entries for this 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 135
>>   (FID already in use).
> 
> Why? It could be a modify operation for an existing FID? How do you
> specify whether an operation is add or modify?
> An HA which receives a BU with a FID which already exists for that MN
> is simply viewed as a modify operation, right?
> 
>>   A de-registration binding
>>   update (with a zero lifetime) would result in deleting all bindings
>>   regardless of the presence of the Flow summary option.
> 
> It would be useful to include a section which explains what happens
> when the MN returns to its home link and deregisters.
> 
>>  If the value of the FID field is present in the mobile nodes list of
>>   slow binding entries the, home agent SHOULD refresh the binding entry
>>   identified by the FID without changing any of the other parameters
>>   associated with it.
> 
> slow binding entries? ;)
> 
>>   If, however, the action
>>   indicated in an entry of the list of flow bindings is "n-cast", the
>>   entry must indicated a BID.
> 
> s/the entry must indicated a BID/the entry must indicate more than one
> valid BID.
> 
>>   If none of the
>>   BIDs pointed to in a flow binding entry is valid then the entry is
>>   considered to be inactive (as defined in Section 4.4) and is skipped.
>>   In other words packets should not be matched against that entry.
> 
> Should that Flow binding be deprecated?
> 
> -Raj
> 
> 
> 
> On 10/6/09 6:30 PM, "ext Laganier, Julien" <[e-mail]> wrote:
> 
>> Folks,
>> 
>> Hereby we're starting a two weeks WGLC on our "Flow Bindings in Mobile IPv6
>> and NEMO Basic Support" document, available at the following URL:
>> 
>> <http://tools.ietf.org/html/draft-ietf-mext-flow-binding-03>
>> 
>> Please review the specification, post your comments to the mailing list, and
>> state whether or not you think the document is ready to be forwarded to IESG
>> before 2009-10-20 6:00PM PST.
>> 
>> Thank you for your support.
>> 
>> --julien & marcelo, MEXT chairs
>> _______________________________________________
>> MEXT mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/mext
> 
> _______________________________________________
> MEXT mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mext