Subject: [MEXT] Review of draft-ietf-mext-flow-binding-02

From: [email-masked] (Arnaud Ebalard)
Date: Tue, 05 May 2009 18:14:27 +0200

Hi,

Below is a review of draft-ietf-mext-flow-binding-02. I think the
document is in pretty good shape and provides a good framework for flow
binding feature.

The whole thing is bit difficult to read towards the end but I don't
think it's an editorial issue: the links and interactions between things
requires some attention and this is the end of the day here. In the end,
I won't state it would be difficult (or easy) to implement, but it will
clearly require to be careful.  

At the end of the reading, I wondered what will happen on a HA when it
will receive the first a BU of a MN that has just rebooted after a
crash. More precisely, I just want confirmation that there is no way for
some old flow to survive on the HA due to some specific values in the BU
(same CoA, BID, ...).

Cheers,

a+

> 2.  Introduction
>
>    Mobile IPv6 [RFC3775], DSMIPv6 [I-D.ietf-mext-nemo-v4traversal] and
>    Nemo Basic Support [RFC3963] allow a mobile node / mobile router to
>    manage its mobility using the binding update message, which binds one
>    care-of address to one home address.  The binding update message can
>    be sent to the home agent.  In Mobile IPv6, the binding update can
>    also be sent to correspondent node or to a mobility anchor point (see
>    [RFC5380]).

What about making one simple sentence from the last two sentences:

     The Binding Update message can be sent to the home agent, to a
     correspondent node or to a mobility anchor point (see [RFC5380]).

>   The semantics of the binding update are limited to  care-of address
>   changes. That is, [RFC3775], ...

Would use 'primary care-of address changes' in order for the 'That is'
in the next sentence to be logical.

> 3.  Terminology

Christian's proposal to improve that section looked fine.

> 4.  Mobile IPv6 Extensions
>
>    This section introduces extensions to Mobile IPv6 that are necessary
>    for supporting the flow binding mechanism described in this document.
>
> 4.1.  Definition Update for Binding Identifier Mobility Option
>
>    This specification updates the definition of the Binding Identifier
>    Mobility option defined in [I-D.ietf-monami6-multiplecoa], as
>    follows:
>
>                             1                   2                   3
>         0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>                                        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>                                        |   Type = TBD  |     Length    |
>        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>        |       Binding ID (BID)        |     Status    |H|   BID-PRI   |
>        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-------------------------------+
>        +                                                               +
>        :                 IPv4 or IPv6 care-of address (CoA)            :
>        +                                                               +
>        +---------------------------------------------------------------+
>
>
>
>              Figure 1: The Binding Identifier Mobility option
>
>
>
>       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, while BIDs with the same BID-PRI
>          value have equal priority.

I may be missing something, but is there any reason not to use the Value
"0"? As a reserved field in draf-ietf-monami6-multiplecoa, it is not
expected to be considered by implementations that implement only
draf-ietf-monami6-multiplecoa (i.e. do not support flow-binding).

> 4.2.1.  Binding Reference Sub-option
>
>    This section introduces the Binding Reference sub-option, which may
>    be included in the Flow identification option.  The Binding Reference
>    sub-option includes one or more BIDs defined in MCoA
>    [I-D.ietf-monami6-multiplecoa].  When this sub-option is included in
>    the Flow identification option it associates the flow described with
>    one or more registered BIDs.
>
>    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.  The Binding Reference sub-option is shown
>    below.
>
>        0                   1                   2                   3
>        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>        |Sub-opt Type   |  Sub-Opt Len  |              BID              |
>        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>        |     BID  ........
>        +-+-+-+-+-+-+-+-+-+-
>
>                 Figure 3: The Binding Reference sub-option
>
>
>       Sub-opt Type
>
>          Indicates the Sub-option type.  For the Binding Reference sub-
>          option, this field MUST be set to 1.
>
>       Sub-opt Len
>
>          Indicates the sub-option length in octets.  This field includes
>          the entire length of the sub-option including the Sub-opt Type
>          and Sub-opt-Len fields.
>
>       BID
>
>          The BID that the mobile node wants to associate with the flow
>          identification option.  One or more BID fields can be included
>          in this sub-option.  Since each BID is 2 byte long, the value
>          of the Sub-opt Len field indicates the number of BIDs present.
>          Number of BIDs = (Sub-opt Len-2)/2.
>
> 4.2.2.  Flow Description Sub-option
>
>    The Flow description sub-option(s) include the parameters used to
>    match packets for a specific flow binding.
>
>        0                   1                   2                   3
>        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>        |Sub-opt Type   |  Sub-Opt Len  |        Flow Description ...
>        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>
>                  Figure 4: The 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.
>
>       Sub-opt Len
>
>          Indicates the sub-option length in octets.  This field includes
>          the entire length of the sub-option including the Sub-opt Type
>          and Sub-opt-Len fields.
>
>       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.
>
>    The following values are reserved for the sub-option Type values are
>    defined for Flow Description:

     That sentence looks strange.

>       17-32 reserved for Flow Description formats.

> 4.3.  Flow Identification Summary Mobility Option
>
>    TBD
>
>        0                   1                   2                   3
>        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>        | Option Type   |  Option Len   |              FID              |
>        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>        |     FID  ........
>        +-+-+-+-+-+-+-+-+-+-
>
>              Figure 5: The Flow Identification Summary Option
>
>       Option Type
>
>          Indicates the Sub-option type.  For the Binding Reference sub-
>          option, this field MUST be set to 1.
>
>       Option Length
>
>          Indicates the sub-option length in octets.  This field includes
>          the entire length of the sub-option including the Sub-opt Type
>          and Sub-opt-Len fields.
>
>       FID
>
>          A registered FID.  One or more FID fields can be included in
>          this option.  Since each FID is 2 bytes long, the value of the
>          Option Len field indicates the number of FIDs present.  Number
>          of FIDs = (Sub-opt Len-2)/2.

This section looks like a copy of 4.2.1.

> 4.4.  Flow Bindings entries list and its relationship to Binding Cache
>
>    The conceptual mobile IPv6 binding cache was defined in [RFC3775] to
>    identify the mobile IP state maintained by the mobile node, home
>    agent, and corresponding node.  The binding cache includes, between

                                                         s/between/among/      

>    others, the mobile node's home address, the registered care-of
>    address, and the lifetime of the binding.  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).
>
>    This specification does not change modify the mobile IPv6 binding

                                 ^^^^^^^^^^^^^
>    cache any further.
>
>    Flow bindings can be thought of as a conceptual list of entries that
>    is separate from the binding cache.  The flow bindings list contains
>    an entry for each of the registered flow binding.  Flow binding
>    entries can point to an entry in the binding cache by means of the
>    BID.  Each flow binding entry include the following parameters :

                                   includes

> 5.  Protocol operations
>
> 5.1.  General
>
>    This specification introduces a flow bindings list of entries and an
>    ordered list of binding identifiers, allowing mobile nodes to
>    associate flow binding policies with the registered care-of
>    addresses.
>
>    The flow identification option defines how the mobile node can
>    control a set of flow binding entries maintained in a home agent,
>    correspondent node, or mobility anchor points, on its behalf.  The
>    fields of the flow identification option are necessary for ordering
>    flow identification options, indicating the sort of action that
>    should be undertaken to the recipient's flow binding list of entries
>    or for carrying the results of such a petition.
>
>    This specification allows mobile nodes to direct flows to a
>    particular care-of address.  The granularity of what constitutes a
>    flow depends on the flow descriptor used.  As indicated earlier the
>    flow description itself is defined in another document.

     As indicated earlier, various flow descriptions are specified in
     external documents. 

> 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.  This section details the
>    mobile node operations necessary to implement this specification.
>
>    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.  Each flow binding update can add, modify,
>    refresh, or delete a given binding.  More than one flow
>    identification options MAY be included in the same binding update but
>    each of them MUST include a different FID.  In other words, two flow
>    identification options in the same message can not be about the same
>    flow binding.
>
>    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

                               been registered

> 5.2.1.  Sending BU with BID Options
>
>    This specification (see Section 4.1) updates the definition of the
>    Binding Identifier option, originally defined in
>    [I-D.ietf-monami6-multiplecoa].  According to this specification the
>    BID option includes a BID-PRI field assigning each registered care-of
>    address a priority, and thus placing them in an ordered list as also
>    described in Section 4.4.
>
>    Mobile nodes supporting this specification MUST use the BID option
>    format defined in Section 4.1.  Mobiles nodes MUST also register

                                     Mobile nodes

> 5.2.5.  Receiving Binding Acknowledgements
>
>    According to [RFC3775] all nodes are required to silently ignore
>    mobility options not understood while processing binding updates.  As
>    such a mobile node receiving a Binding Acknowledgement in response to
>    the transmission of a binding update MUST determine if the Binding
>    Acknowledgement contains a copy of every flow identification options
>    included in the binding update.  A Binding Acknowledgement without
>    flow identification option(s), in response to a Binding Update with
>    flow identification option, would indicate inability (or
>    unwillingness) on behalf of the source node to support the extensions
>    presented in this document.
>
>    If a received Binding Acknowledgement contains a copy of of each flow

                                                          s/of of/of/

> 5.3.2.  Receiving BU with Flow Identification Options
>
>    When the home agent receives a binding update which includes at least
>    one Flow Identification option, it first performs the operation
>    described in section 10.3.1 of RFC3775.
>
>    Home agents that do not support this specification will ignore the
>    flow identification options and all their suboption, having no effect
>    on the operation of the rest of the protocol.
>
>    If the binding update is accepted, and the home agent is willing to
>    support flow bindings for this MN, the home agent checks the flow
>    identification options.
>
>    If more than one flow identification option in the same BU, has the

                                                  s/same BU,/same BU/

Cheers,

a+

---

From: George Tsirtsis <[email-masked]>
Date: Tue, 5 May 2009 21:26:18 +0100

Hi Arnaud,

Thanks for the review. I will look at your comments in more detail
tomorrow when i will have more time but I wanted to respond to one
thing below...see inline.

> some old flow to survive on the HA due to some specific values in the BU

GT> I am not sure section 5.2 (last para) and 5.2.3 can be any clearer on this.
According to these the MN MUST include all FIDs it wants to maintain
in every BU, either as FID options or as part of an FIDSummary option.
An MN that just rebooted will start from scratch and will not remember
any of the FIDs it established earlier. A BU without any flow binding
options will remove all FID state from the HA. Also note that RFC3775
discusses various issues WRT reboots and while RFC3775 is not specific
about it, it does indicate that a combination of the seq.num and IPSEC
state can be used to detect such cases.
In any case for the purpose of this draft we are being very clear. If
an MN "forgets" its FID state for any reason it will fail to refresh
it appropriately and so it will be removed from the HA/CN.

I hope this makes sense
George

> _______________________________________________
> MEXT mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mext
>

---

From: [email-masked] (Arnaud Ebalard)
Date: Tue, 05 May 2009 23:16:05 +0200

Hi George,

> thing below...see inline.

Ack. 

> options will remove all FID state from the HA.

I was more thinking about a MN rebooting on the same network, with high
probability to send its first BU with the same kind of content as the
one he sent before dying.

> Also note that RFC3775 discusses various issues WRT reboots and while
> RFC3775 is not specific about it, it does indicate that a combination
> of the seq.num and IPSEC state can be used to detect such cases.

Well, IPsec will not help. Nothing prevents a MN to rekey at some
point. The HA will not act upon that kind of stimulus. It will possibly
not even be warned.

As for the sequence number, if I am not mistaken, the HA is expected to
warn the MN about that using a BA with status code 135 (seq num out of
window). In the end, the MN will not have to reconsider the content of
its first BU when receiving that BA (say create a new one w/ the correct
sequence number *and* that flushes everything just in case): it can
*safely* resend previous one w/ an updated sequence number, without
bothering about cleaning previous states. 

The anwser below clarified that: BU will delete old states either by
overwriting things (Add) or not specifying existing ones that the HA
has. In the end, this will work because the MN is not expected to send
Modify in its first BU (only Add).

> it appropriately and so it will be removed from the HA/CN.

This is what I thought from my reading but I wanted to be sure I did not
miss something.

Thanks for your answer.

Cheers,

a+