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

[George Tsirtsis <[e-mail]>]

Hi Raj,

Thanks for the very detailed review, it is appreciated.
I have taken on board most of your comments.

See also inline.


On Fri, Oct 9, 2009 at 11:36 PM,  <[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
>

GT> done

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

GT> will do

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

GT> nice, thanks.

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

GT> I think Hesham responded to this but the bottom line is that it is
not reasonable for the MN to be able to route any specific flow as it
wants, but not being able to indicate what the default CoA should be.

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

GT> I have already dealt with this in another e-mail, but each flow
binding has a unique FID-PRI. I will reserve value 0 as you suggest.

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

GT> ok

> - Can you include the values defined for the actions further below in
>  the section immediately below the Action field definition? Makes
>  reading easier.

GT> Yes, done.

> - a/Action value 0 is reserved.

GT> done

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

GT> Yes, caught by others too...as I said before it s remnant from an
older version. which I have now fixed.

>> Rsvd
>> Status
>
> Specify these are 8 bit unsigned integer fields just to be explicit.
>

GT> A bit extreme for the reserved bits but will do for Status

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

GT> done

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

GT> It does when Action=Discard.

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

GT> OK

> - s/Indicates the/8 bit unsigned integer which indicates the

GT> OK

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

GT> This is the by product of splitting Traffic Selector (ex. Flow
Description) definitions out of the Flow Bindings draft. It simply
reserves some Sub-Type values for use by Traffic Selectors.
draft-ietf-mext-binary-ts will for example use some of these values.
Another way would be to define the TS sub-types for binary TSs only
for now...which would probably make things clearer. In this case only
the body of these TSs would be defined in a separate draft.

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

GT> Yes, we renamed Flow Description to Traffic Selector after the
publication of v03 of the draft. Next version will use the term
Traffic Selector, instead of Flow Description.

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

GT> Hesham dealt with this point.

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

GT> OK

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

GT> A BID is becoming invalid when it is deregistered. in other words,
if an MN creates a Flow Binding and points it to BID1, but then some
time later it deregisters BID1, then we say that the flow binding
pointing to BID1 (assuming it only points to BID1) becomes
inactive....which means that the HA keeps the flow binding state but
does not use it to match packets with This is done in anticipation of
the fact that CoAs might come and go, and we would like to avoid
having the M N to have to keep reregistering flow bindings (with
length TSs)  just because a BID had to be removed and be replaced by a
new one a few seconds later.


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

GT> See above

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

GT> Its not an error case, see above.

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

GT> I think we have answered this.

>>   As indicated earlier the
>>   flow description itself is defined in another document.
>
> Reference draft-ietf-mext-binary-ts
>

GT> OK

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

GT> See above

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

GT> There is already a "MUST" about this in the previous sentence.
"More than one flow identification options MAY be
                    included in the same binding update but each of them MUST
                    include a different FID.".
The sentence you quoted is just further explanation.


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

GT> Hesham dealt with this point too.

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

GT> See Hesham's e-mail

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

GT> This is how it was earlier and the authors and WG decided to
change it. The current mechanism is actually more natural to the
normal MIPv6 operations. Beleive me we went through the exercise with
add/modify/delete and it got rather complex without any benefit. See
also below when I summarize the current technique which I think is
very simple.

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

GT> As I said so that the MN does not have to keep sending a Traffic
Selector for flows (especially think long term ones) just because a
BID was temporarily removed.

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

GT> This is a bug so I am correcting the text. The mechanism is very
simple and straightforward. When a BU is received the HA looks at the
list of FIDs.
- If for a given FID the HA already has state, the flow binding in the
BU replaces the flow binding in the HA (i.e., this is a Modify).
- If for a given FID the HA does not have state, then the flow binding
is added to the HA (i.e., this is an addition),
- If the HA has flow bindings with FIDs that are not included in a BU,
the flow bindings are removed from the HA (i.e., this is a delete)

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

GT> Good idea. I will add text explaining that returning home is
performed as per RFC3775 and RFC5648...something like the following:.

                <section title="Returning Home">
                    <t>This specification is compatible to the home registration
                        procedures defined in <xref target="RFC3775"/> and <xref
                            target="RFC5648"/>. More specifically, if the mobile
                        node performes an <xref target="RFC3775"/> style
                        deregistration, all of its bindings, including flow
                        bindings are deleted. If the mobile node, however,
                        performs an <xref target="RFC5648"/> style home
                        registration, then the home link is associated with a
                        specific BID and so, as far as this specification is
                        concerned, it is treated as any other link associated
                        with a given BID.</t>
                </section>

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

GT> yes...very slow ;-)

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

GT> ok

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

GT> it just become inactive as explained above.

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