Subject: Re: [MEXT] AD review of draft-ietf-mext-flow-binding

From: George Tsirtsis <[email-masked]>
Date: Mon, 1 Mar 2010 10:20:21 +0000

Hi Jari,

Thanks for the review and the comments, all of which I deal with below.
I am publishing the new ID immediately incorporating all of the
corrections/additions below, but let me know if there is anything else
we need to change.

George

On Fri, Feb 26, 2010 at 11:59 AM, Jari Arkko <[email-masked]> wrote:
> I have reviewed this specification. It is basically in very good shape, but
> I did detect a few small issues. Please correct them so that I can last call
> the document:
>
> Mobile nodes supporting this specification MUST use the BID option
> format defined in Section 4.1.  Mobile nodes MUST also register all
> care-of addresses using the updated BID option format, either in the
> same BU as any flow identification mobility options using them, or in
> earlier BUs.
>
>
> Can you talk about what the backwards compatibility issues with the
> additional PRI field are somewhere? I am assuming that 0 in a reserved field
> is ignored, and new nodes will treat PRI 0 as a sign that its an old format
> BID option.
>

GT> I am adding the following:
                   <t>To ensure backwards compatibility with <xref
                           target="RFC5648"/> for the purpose of this
                       specification the field BID-PRI SHOULD NOT be set to
                       zero. Receiver implementation of this specification
                       will take a BID-PRI field of value zero as an indication
                       that this is a BID option of the format defined in <xref
                           target="RFC5648"/>.</t>

> When a valid binding update is received, any registered FIDs that are
> not explicitly referred to in a flow identification mobility option
> or in a flow summary mobility option, MUST be removed from the list
> of flow binding entries for the mobile node.
>
>
> Presumably this only needs to be done if the FIDs are not used by this
> Binding Update
> or any other binding that is currently in effect.

GT> I modifying slightly to clarify:
<t> When a valid binding update is received, any registered
                       FIDs that are not explicitly referred to in a flow
                       identification mobility option or in a flow summary
                       mobility option, **in the same binding
update**, MUST be removed from the list of flow
                       binding entries for the mobile node.

GT> Note that each BU overwrites all FIDs, as clearly specified in
section 5.2 "MN Considerations"
"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 mobility option, but have
                   previously registered and need to be maintained MUST be
                   included in a flow summary mobility option."

>          3-250 unassigned and available for allocation based on STD
>          action
>
>
> Not an RFC 5226 term. Use "Standards Action" and use a reference.
>

GT> OK

>          251-255 reserved for experimental use
>
> Add some language somewhere to discuss what experimental use is appropriate.
> You can use RFC 5494 Section 4 as a template for this text.
>

GT> I ended up adding a sentence under each allocation:
             <t>2) New "Flow Identification Mobility Option Action codes"
                          ....
                           <t>255 reserved for experimental use. A single value
                               should be sufficient for experimenting with a
                               different flow identifiction format.</t>

                   <t>3) New "Flow Identification Mobility Option Status codes"
                             ...
                           <t>251-255 reserved for experimental use. This small
                               number of status codes should be sufficient for
                               experiments with currently unforeseen error
                               conditions.</t>

                    <t>4) New "Flow Identification Sub-Options"
                         ...
                         <t>251-255 reserved for experimental use.  This small
                                number of sub-option types should be
sufficient for
                                experiments with additional parameters
associated with a flow.</t>

                    <t>5) New "Traffic Selector Format" ....
                             ...
                            <t>251-255 reserved for experimental use.
This small
                                number of traffic selector format
types should be sufficient for
                                experiments with different ways of
representing a traffic selector.</t>
> STD action
>
>
> Please make all of these Standards Action or IESG Approval. The latter is
> needed as a special case to allow judgment calls to allocate for specific
> needs. E.g., experimental RFCs.
>

GT> OK

>       5) New "Traffic Selector Format" namespace for the Traffic
>       Selector sub-option.  The traffic selector format space is defined
>       by the TS Format field in Figure 5.  The following values are
>       defined in this specification:
>
>          0 Reserved
>
>          1-250 unassigned and available for allocation based on STD
>          action
>
>          251-255 reserved for experimental use
>
>    Similar to the procedures specified for Mobile IPv6 [RFC3775] number
>    spaces, future allocations from the new number spaces requires Expert
>    Review as defined i [RFC5226].
>
>
> Inconsistency. Is the rule standards action, or expert review?
>

GT> corrected...see above.

> Missing discussions: the document is silent on MTU considerations of
> constructing large filter sets. Please include a new section that talks
> about this issue, and provides practical guidance on what types of binding
> update messages are still expected to work well in practice.
>

GT> Good point, especially since we took grate care to allow MNs to
minimize BU size. Here is a new section on this issue:
        <section title="MTU Considerations">
            <t> The options and sub-options defined in this specification add to
                those defined in <xref target="RFC3775"/> and other related
                specifications, all of which potentially adds to the size of
                binding update messages. Implementations SHOULD take
care to minimize fragmentation
                by forming binding updates that are shorter than what the path
                MTU allows whenever possible.</t>
            <t>This specification offers a number of mechanisms for reducing the
                size of binding updates. The operations defined in this
                specification that require the most verbose options are those
                registering new BIDs <xref target="BIDUpdate"/> and identifying
                new flows <xref target="FDsub"/>. Implementations are
                encouradged to keep binding updates to sizes below
than that of the path's MTU by
                making full use of BID Reference <xref target="BIDRef"/> and FID
                Summary <xref target="FIDsum"/> sub-options, which allows them
                to refer to already registered care-off addresses and flows,
                while registering new ones in subsequent binding update
                messages.</t>
        </section>

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