Flow Bindings in Mobile IPv6 and Network Mobility (NEMO) Basic Support
draft-ietf-mext-flow-binding-11

[Ballot comment]
Section 2., paragraph 5:
>    Note that per-packet load balancing may have negative impacts on TCP
>    congestion avoidance mechanisms as it is desirable to maintain order
>    between packets belonging to the same TCP connection.  This behaviour
>    is specified in [RFC2702].  Other negative impacts are also foreseen
>    for other types of real time connections due to the potential
>    variations in round trip time between packets.  Moreover, per-packet
>    load-balancing will negatively affect traffic with anti-replay
>    protection mechanisms.  Hence, per-packet load balancing is not
>    envisioned in this specification.

  It'd be even stronger here and say that packet-based load balancing
  causes severe performance issues for almost all kinds of Internet
  transports and applications, and that this specification SHOULD NOT be
  used in this way.


Section 3., paragraph 2:
>      Flow: A flow is a sequence of packets for which the MN desires
>      special handling either by the Home Agent (HA), the Corresponding
>      Node (CN) or the (Mobility Anchor Point) MAP.

  Isn't a flow for the purposes of this specification something more
  restrictive, i.e., a sequence of packets *that can be matched by a
  common traffic selector*?


Section 3., paragraph 5:
>      Flow Identifier: A flow identifier uniquely identifies a flow
>      binding associated with a mobile node.  It is generated by a
>      mobile node and is cached in the table of flow binding entries
>      maintained by the MN, HA, CN or MAP.

  "uniquely identifies a flow" in what scope? I assume not
  Internet-wide.


Section 4.2., paragraph 9:
>          The Flow Identifier field is a 16-bit unsigned integer that
>          includes the unique identifier for the flow binding.  This
>          field is used to refer to an existing flow binding or to create
>          a new flow binding.  The value of this field is set by the
>          mobile node.  FID = 0 is reserved and MUST NOT be used.

  This means a node can have at most 64K flow bindings. It's a large
  number, but not so large that I can see it being sufficient in all
  future corner cases.


Section 5.3.3., paragraph 2:
>    and one or mobe Binding Identifier mobility options identifying

  Nit: s/mobe/more/


Section 6., paragraph 2:
>    Section 4.2.1.4.  Implementations are encouradged to keep binding

  Nit: s/encouradged/encouraged/


Section 8., paragraph 10:
>          identifiction format.

  Nit: s/identifiction/identification/

[Ballot discuss]
DISCUSS-DISCUSS: There have been several revisions since Allison
  Mankin's tsv-dir review, but it's unclear if the issues she raises
  have resulted in text changes or where otherwise dealt with (there was
  no follow-up email to the review.) Please clarify?


Section 4.2., paragraph 11:
>          This is an 8-bit unsigned priority field to indicate the
>          priority of a particular option.
...
>          FID-PRI MUST be unique to each of the flows
>          pertaining to a given MN.  In other words, two FIDs MUST NOT be
>          associated with the same FID-PRI value

  DISCUSS: I may be misunderstanding this, but if FID-PRI must be unique
  for all flows of an MN, and it's 8-bit, then there can only be 256
  flows? That's awfully little.


Section 4.2., paragraph 15:
>            1 'Discard'.  This value indicates a request to discard all
>            packets in the flow described by the option.  No BIDs are
>            associated with this Action.  Care should be taken when
>            using this Action as it will lead to disrupting applications
>            communication.  Implementations may consider notifying
>            impacted applications in mobile nodes.

  DISCUSS: This action is turning MIP into a firewall control protocol.



Section 4.2.1.4., paragraph 13:
>      A variable length field, the format and content of which is out of
>      scope for this specification.  The traffic selector defined in
>      [I-D.ietf-mext-binary-ts] is mandatory to implement.

  DISCUSS: If it's mandatory to implement, then it needs to become a
  normative reference (make this clear by s/mandatory to implement/MUST
  be implemented/). I also don't understand what the purpose of this
  specification is if this critical piece is left undefined? It can't
  really be used without this, can it?

[Ballot comment]
I support Sean's discuss issue:  The Security Considerations section should include explicit pointers to the Security Considerations sections in RFCs 3775, 3963, and 5555.

[Ballot comment]
#1) I would like the authors to consider adding the following text (from Tina Tsou's SECDIR review) to the security considerations:

This specification does not open up new fundamental lines of attack on communications between the MN and its correspondent nodes. However, it allows attacks of a finer granularity than those on the basic binding update. For instance, the attacker can divert or replicate flows of special interest to the attacker to an address of the attacker's choosing, if the attacker is able to impersonate the MN or modify a binding update sent by the MN. Hence it becomes doubly critical that authentication and integrity services are applied to binding updates.

[Ballot discuss]
Doesn't this document update RFC 5648?
As it says in section 4.1...
  This specification updates the definition of the Binding Identifier
  Mobility option defined in [RFC5648], as follows:

[Ballot comment]
"The receiver MUST quietly ignore and skip over the option"

I think that the authors mean silently.

The abbreviations BU, HA, CN, MN and MAP should be expanded on first use.

[Ballot discuss]
There are many instances in this document where the authors say value 0 is reserved and SHOULD NOT be used. In each case the reason appears to be backwards compatibility with the earlier version of the protocol. However SHOULD NOT gives the implementer an element of discretion that I suspect was not indended. In these cases MUST NOT would seem to be a more appropriate implementation directive.

[Ballot comment]
4.2.  Flow Identification Mobility Option

      FID

        FID = 0 is reserved and SHOULD NOT be used.

Why SHOULD and not a MUST here?

      FID-PRI

        Value '0' is reserved and SHOULD NOT be used.

Why SHOULD and not a MUST here?

(A similar question regarding "TS Format" field in Section 4.2.1.4.)

      Rsvd

        This field is unused.  It SHOULD be set to zero by the sender
        and ignored by the receiver.

I think the requirement on receivers compliant with this spec should be a MUST.
(Similar comment for the "Reserved" field in Section 4.2.1.4.)


5.3.2.2.  Handling known FIDs

  Since this flow identification mobility option is designed to update
  an existing entry it may not include a traffic selector sub-option.

I might be confused here, but what is the exact meaning of "may not"
above, considering that the second choice below shows exactly what to do:

      If a traffic selector sub-option is not included in the flow
      identification mobility option, then the traffic selector already
      associated with entry MUST be maintained,

      otherwise the traffic selector in the entry MUST be replaced by
      the traffic selector in the sub-option.

?

A similar question on the following text in the same section:

  Unlike Section 5.3.2.1, however, if the Action field in the flow
  identification mobility option is set to 'Forward', and since this
  flow identification mobility option is designed to update an existing
  entry, it may not include a binding reference sub-option.

      If a binding reference sub-option is not included in the flow
      identification mobility option, then the BIDs already associated
      with entry MUST be maintained,

      otherwise the BIDs in the entry MUST be replaced by the BIDs in
      the sub-option.

[Ballot discuss]
[Updated:]
This is a fine document and I was about to vote "No Objections" when I noticed the following:

5.2.2.1.  New Flow Bindings

  Since this flow identification mobility option is requesting the
  addition of a new flow binding in the list of flow bindings
  maintained by the receiver, the mobile node MUST include exactly one
  Traffic Selector sub-option (see Section 4.2.1.4) describing the flow
  associated with the new flow binding.  The TS Format field of the
  Traffic Selector sub-option MUST be set to the non-zero value of the
  format used by the mobile node.

The document doesn't define any traffic selection formats, even though it creates a new IANA registry for them.
Without any traffic selection option defined I can't see how an implementation can possibly comply with this document.

One of the authors pointed me to
http://datatracker.ietf.org/doc/draft-ietf-mext-binary-ts/
which is already in the RFC Editor queue. I think this should be at least referenced informatively.

There is also a question on whether any traffic selector should be "mandatory to implement".

[Ballot comment]
4.2.  Flow Identification Mobility Option

      FID

        FID = 0 is reserved and SHOULD NOT be used.

Why SHOULD and not a MUST here?

      FID-PRI

        Value '0' is reserved and SHOULD NOT be used.

Why SHOULD and not a MUST here?

(A similar question regarding "TS Format" field in Section 4.2.1.4.)

      Rsvd

        This field is unused.  It SHOULD be set to zero by the sender
        and ignored by the receiver.

I think the requirement on receivers compliant with this spec should be a MUST.
(Similar comment for the "Reserved" field in Section 4.2.1.4.)


5.3.2.2.  Handling known FIDs

  Since this flow identification mobility option is designed to update
  an existing entry it may not include a traffic selector sub-option.

I might be confused here, but what is the exact meaning of "may not"
above, considering that the second choice below shows exactly what to do:

      If a traffic selector sub-option is not included in the flow
      identification mobility option, then the traffic selector already
      associated with entry MUST be maintained,

      otherwise the traffic selector in the entry MUST be replaced by
      the traffic selector in the sub-option.

?

A similar question on the following text in the same section:

  Unlike Section 5.3.2.1, however, if the Action field in the flow
  identification mobility option is set to 'Forward', and since this
  flow identification mobility option is designed to update an existing
  entry, it may not include a binding reference sub-option.

      If a binding reference sub-option is not included in the flow
      identification mobility option, then the BIDs already associated
      with entry MUST be maintained,

      otherwise the BIDs in the entry MUST be replaced by the BIDs in
      the sub-option.

[Ballot discuss]
This is a fine document and I was about to vote "No Objections" when I noticed the following:

5.2.2.1.  New Flow Bindings

  Since this flow identification mobility option is requesting the
  addition of a new flow binding in the list of flow bindings
  maintained by the receiver, the mobile node MUST include exactly one
  Traffic Selector sub-option (see Section 4.2.1.4) describing the flow
  associated with the new flow binding.  The TS Format field of the
  Traffic Selector sub-option MUST be set to the non-zero value of the
  format used by the mobile node.

The document doesn't define any traffic selection formats, even though it creates a new IANA registry for them.
Without any traffic selection option defined I can't see how an implementation can possibly comply with this document. Are there some documents in works that define possible traffic selection options for use here?

[Ballot comment]
4.2.  Flow Identification Mobility Option

      FID

        FID = 0 is reserved and SHOULD NOT be used.

Why SHOULD and not a MUST here?

      FID-PRI

        Value '0' is reserved and SHOULD NOT be used.

Why SHOULD and not a MUST here?

(A similar question regarding "TS Format" field in Section 4.2.1.4.)

      Rsvd

        This field is unused.  It SHOULD be set to zero by the sender
        and ignored by the receiver.

I think the requirement on receivers compliant with this spec should be a MUST.
(Similar comment for the "Reserved" field in Section 4.2.1.4.)


5.3.2.2.  Handling known FIDs

  Since this flow identification mobility option is designed to update
  an existing entry it may not include a traffic selector sub-option.

I might be confused here, but what is the exact meaning of "may not"
above, considering that the second choice below shows exactly what to do:

      If a traffic selector sub-option is not included in the flow
      identification mobility option, then the traffic selector already
      associated with entry MUST be maintained,

      otherwise the traffic selector in the entry MUST be replaced by
      the traffic selector in the sub-option.

?

A similar question on the following text in the same section:

  Unlike Section 5.3.2.1, however, if the Action field in the flow
  identification mobility option is set to 'Forward', and since this
  flow identification mobility option is designed to update an existing
  entry, it may not include a binding reference sub-option.

      If a binding reference sub-option is not included in the flow
      identification mobility option, then the BIDs already associated
      with entry MUST be maintained,

      otherwise the BIDs in the entry MUST be replaced by the BIDs in
      the sub-option.

IANA questions/comments:

ACTION 1:

make the following assignments in the "Mobility Options" registry at
http://www.iana.org/assignments/mobility-parameters/mobility-parameters.xhtml

Value Description Reference
----- ------------------- ---------
TBD Flow Identification [RFC-mext-flow-binding-06]
TBD Flow Summary [RFC-mext-flow-binding-06]


ACTION 2:

Create a new sub-registry at
http://www.iana.org/assignments/mobility-parameters/mobility-parameters.xhtml

Registry Name: Flow Identification Mobility Option Action codes
Registration Procedures: Standards Action or IESG Approval
Reference: [RFC-mext-flow-binding-06]

Initial Content

Value Description Reference
----- ------------ ---------
0 Reserved [RFC-mext-flow-binding-06]
1 Discard [RFC-mext-flow-binding-06]
2 Forward [RFC-mext-flow-binding-06]
3-254 Unassigned [RFC-mext-flow-binding-06]
255 Experimental [RFC-mext-flow-binding-06]


ACTION 3:

Create a new registry at
http://www.iana.org/assignments/mobility-parameters/mobility-parameters.xhtml

Registry Name: Flow Identification Mobility Option Status codes
Registration Procedures:
0-127: Standards Action
127-250: Standards Action or IESG Approval

Reference: [RFC-mext-flow-binding-06]
Value range: 8bit unsigned integer

Initial Content:

Value Description Reference
----- --------------------------------------------- ---------
0 Flow binding successful
[RFC-mext-flow-binding-06]
1-127 Unassigned
128 Administratively prohibited
[RFC-mext-flow-binding-06]
129 Flow binding rejected, reason unspecified
[RFC-mext-flow-binding-06]
130 Flow identification mobility option malformed
[RFC-mext-flow-binding-06]
131 BID not found
[RFC-mext-flow-binding-06]
132 FID not found
[RFC-mext-flow-binding-06]
133 Traffic selector format not supported
[RFC-mext-flow-binding-06]
134 Discard function not supported
[RFC-mext-flow-binding-06]
135 Forward function not supported
[RFC-mext-flow-binding-06]
136-250 Unassigned
251-255 Experimental
[RFC-mext-flow-binding-06]

QUESTION: Document says: "126-250 unassigned and available" while
registrations are requested for 128-135. We understand that 126-250
shall instead be 136-250 (i.e. typo). Please confirm.

QUESTION: Document says: "1-127 STD action", while 128-250 are
"Standards Action or IESG Approval". Moreover, at the end of the IANA
Considerations section, text is "Similar to the procedures specified for
Mobile IPv6 [RFC3775] number spaces, future allocations from the new
number spaces requires Standards Action or IESG Approval as per
[RFC5226]." Therefore, registration procedures for 1-127 seem to be
different. Please confirm these above are the registration policy intended.


ACTION 4:

Create a new registry at
http://www.iana.org/assignments/mobility-parameters/mobility-parameters.xhtml

Registry Name: Flow Identification Sub-Options
Registration Procedures: Standards Action or IESG Approval
Reference: [RFC-mext-flow-binding-06]

Initial Content:

Value Description Reference
----- ----------------- ---------
0 Pad [RFC-mext-flow-binding-06]
1 PadN [RFC-mext-flow-binding-06]
2 BID Reference [RFC-mext-flow-binding-06]
3 Traffic Selector [RFC-mext-flow-binding-06]
4-250 Unassigned
251-255 Experimental [RFC-mext-flow-binding-06]


QUESTION: Section 4.2.1.1 defines "Pad1" Option with value type = 0,
while in the IANA Considerations section, the registration request is
for "Pad" Option. To our understanding, these two options are the same.
Therefore, please confirm the name of the option: "Pad" or "Pad1".


ACTION 5:

Create a new registry at
http://www.iana.org/assignments/mobility-parameters/mobility-parameters.xhtml

Registry Name: Traffic Selector Format
Registration Procedures: Standards Action or IESG Approval
Reference: [RFC-mext-flow-binding-06]

Initial Content:

Value Description Reference
----- ----------------- ---------
0 Reserved [RFC-mext-flow-binding-06]
1-250 Unassigned
251-255 Experimental [RFC-mext-flow-binding-06]

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.

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

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

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

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

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

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.

  (1.a)  Who is the Document Shepherd for this document?  Has the
          Document Shepherd personally reviewed this version of the
          document and, in particular, does he or she believe this
          version is ready for forwarding to the IESG for publication?

          The document shepherd is Marcelo Bagnulo.
  I have read the document and i think it is ready for
  publication.

  (1.b)  Has the document had adequate review both from key WG members
          and from key non-WG members?  Does the Document Shepherd have
          any concerns about the depth or breadth of the reviews that
          have been performed?

  The document has been reviewed thoroughly.
  I don't have any concerns about the reviews.

  (1.c)  Does the Document Shepherd have concerns that the document
          needs more review from a particular or broader perspective,
          e.g., security, operational complexity, someone familiar with
          AAA, internationalization, or XML?

  No further specific review is needed.

  (1.d)  Does the Document Shepherd have any specific concerns or
          issues with this document that the Responsible Area Director
          and/or the IESG should be aware of?  For example, perhaps he
          or she is uncomfortable with certain parts of the document, or
          has concerns whether there really is a need for it.  In any
          event, if the WG has discussed those issues and has indicated
          that it still wishes to advance the document, detail those
          concerns here.  Has an IPR disclosure related to this document
          been filed?  If so, please include a reference to the
          disclosure and summarize the WG discussion and conclusion on
          this issue.

  The document is important and should be published.
  I have no concerns with the document.
  No IPR issues have been raised.

  (1.e)  How solid is the WG consensus behind this document?  Does it
          represent the strong concurrence of a few individuals, with
          others being silent, or does the WG as a whole understand and
          agree with it?

  The consensus behind the document is strong.
  The document has been reviewed and discussed in depth in the WG.

  (1.f)  Has anyone threatened an appeal or otherwise indicated extreme
          discontent?  If so, please summarize the areas of conflict in
          separate email messages to the Responsible Area Director.  (It
          should be in a separate email because this questionnaire is
          entered into the ID Tracker.)

  No extreme discontent nor appeal threats have been received.

  (1.g)  Has the Document Shepherd personally verified that the
          document satisfies all ID nits?  (See
          http://www.ietf.org/ID-Checklist.html and
          http://tools.ietf.org/tools/idnits/.)  Boilerplate checks are
          not enough; this check needs to be thorough.  Has the document
          met all formal review criteria it needs to, such as the MIB
          Doctor, media type, and URI type reviews?  If the document
          does not already indicate its intended status at the top of
          the first page, please indicate the intended status here.

  Yes
  No additional formal review is needed for the document.

  (1.h)  Has the document split its references into normative and
          informative?  Are there normative references to documents that
          are not ready for advancement or are otherwise in an unclear
          state?  If such normative references exist, what is the
          strategy for their completion?  Are there normative references
          that are downward references, as described in [RFC3967]?  If
          so, list these downward references to support the Area
          Director in the Last Call procedure for them [RFC3967].

  The references are split into normative and informative.
  All normative references are RFCs.
  No downward references are included.

  (1.i)  Has the Document Shepherd verified that the document's IANA
          Considerations section exists and is consistent with the body
          of the document?  If the document specifies protocol
          extensions, are reservations requested in appropriate IANA
          registries?  Are the IANA registries clearly identified?  If
          the document creates a new registry, does it define the
          proposed initial contents of the registry and an allocation
          procedure for future registrations?  Does it suggest a
          reasonable name for the new registry?  See [RFC2434].  If the
          document describes an Expert Review process, has the Document
          Shepherd conferred with the Responsible Area Director so that
          the IESG can appoint the needed Expert during IESG Evaluation?

  The IANA section exists and it is consistent with the rest
  of the document. Proper reservations are defined in the
  IANA section. The corresponding registries are clearly
  identified. New registries are properly defined and initial
          allocations are included. It does suggest a new reasonable name
          for each new registry.
     

  (1.j)  Has the Document Shepherd verified that sections of the
          document that are written in a formal language, such as XML
          code, BNF rules, MIB definitions, etc., validate correctly in
          an automated checker?

  No section in formal language.

  (1.k)  The IESG approval announcement includes a Document
          Announcement Write-Up.  Please provide such a Document
          Announcement Write-Up.  Recent examples can be found in the
          "Action" announcements for approved documents.  The approval
          announcement contains the following sections:

          Technical Summary
            Relevant content can frequently be found in the abstract
            and/or introduction of the document.  If not, this may be
            an indication that there are deficiencies in the abstract
            or introduction.

  This document introduces extensions to Mobile IPv6 that allow nodes
  to bind one or more flows to a care-of address.  These extensions
  allow multihomed nodes to instruct home agents and other Mobile IPv6
  entities to direct inbound flows to specific addresses.


          Working Group Summary
            Was there anything in the WG process that is worth noting?
            For example, was there controversy about particular points
            or were there decisions where the consensus was
            particularly rough?

            The document has been discussed in depth in the WG.
            The WG feels that this is an important document
            and should be published.
            The main controversy was whether there should be one or more
            traffic selector format defined. The current spec. supports
            multiple formats, but only one is being defined at this point.
            This is issue is related to this document, but not specific to
            this document, as i stated before, this spec supports multiple
            formats.

          Document Quality
            Are there existing implementations of the protocol?  Have a
            significant number of vendors indicated their plan to
            implement the specification?  Are there any reviewers that
            merit special mention as having done a thorough review,
            e.g., one that resulted in important changes or a
            conclusion that the document had no substantive issues?  If
            there was a MIB Doctor, Media Type, or other Expert Review,
            what was its course (briefly)?  In the case of a Media Type
            Review, on what date was the request posted?

      There is at least on ongoing effort for implementing this
              specification from Qualcom

      There were many reviewers of the document, but especial
      in depth reviews were provided by Dave Craig, Benjamin Lim,
              Sundararajan Jay Kumar, Raj Patil, Conny Larson, Yuri Ismailov.

No MIB review nor media type reviews were needed.

          Personnel
            Who is the Document Shepherd for this document?  Who is the
            Responsible Area Director?  If the document requires IANA
            experts(s), insert 'The IANA Expert(s) for the registries
            in this document are .'

    The document shepherd is Marcelo Bagnulo
    Responsible INT AD is Jari Arkko