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

[<[e-mail]>]

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