Failure Detection and Locator Pair Exploration Protocol for IPv6 Multihoming
draft-ietf-shim6-failure-detection-13

[Ballot discuss]
[This is an update to the original placeholder DISCUSS for Bernard's
tsv-dir review that rolls in my comments on the document.]


Section 3.3., paragraph 6:
> Forced Bidirectional Communication (FBD), described later in this
> specification.  In addition, implementations MAY employ the following
> additional mechanisms:

  DISCUSS: All of the MAYs below are referring to techniques that are
  basically research ideas that are neither fully specified nor
  experimentally vetted - permitting them to be used is thus not
  appropriate. (See the comments marked with "MAY" below.)


Section 4.3., paragraph 0:
> 4.3.  Exploration Order

  DISCUSS: The specification of the probing algorithm needs to be made
  more precise. It remains unclear how the various timers control the
  transmission of the probe packets across all interfaces, how backoff
  is handled and retries are scheduled. Suggest to look at the ICE or
  DHCP specs for examples.


Section 7., paragraph 2:
> Keepalive Interval                          Not specified here

  DISCUSS: Where is it specified then? It's a critical parameter.

[Ballot comment]
Section 3.3., paragraph 7:
> o  Positive feedback from upper layer protocols.  For instance, TCP
>    can indicate to the IP layer that it is making progress.  This is
>    similar to how IPv6 Neighbor Unreachability Detection can in some
>    cases be avoided when upper layers provide information about
>    bidirectional connectivity [RFC2461].

  This is a pretty large architectural change. No transport protocol had
  to indicate to the network layer "that it is making progress" in order
  to sustain connectivity. It's also unclear what "progress" is - TCP
  connections can be idle for days, with no packets going back and
  forth. This is a feature.


Section 3.3., paragraph 9:
> o  Negative feedback from upper layer protocols.  It is conceivable
>    that upper layer protocols give an indication of a problem to the
>    multihoming layer.  For instance, TCP could indicate that there's
>    either congestion or lack of connectivity in the path because it
>    is not getting ACKs.

  TCP knows how to deal with congestion or transient lack of
  connectivity internally. TCP has no notion of indicating to the
  network layer that it should do something about the connectivity, and
  it's unclear when this new option should be used rather than reacting
  to connectivity events through congestion control.


Section 3.3., paragraph 10:
> o  ICMP error messages.  Given the ease of spoofing ICMP messages,
>    one should be careful to not trust these blindly, however.  Our
>    suggestion is to use ICMP error messages only as a hint to perform
>    an explicit reachability test or move an address pair to a lower
>    place in the list of address pairs to be probed, but not as a
>    reason to disrupt ongoing communications without other indications
>    of problems.

  If I understand this correctly, this proposed that SHIM6 hijack the
  ICMP messages that are generated in response to transport sessions.
  This is problematic, because it will prevent the transport protocols
  from reacting to these ICMP messages in the currently-specified way.
  If both SHIM6 and the transport protocol act on ICMP messages, i.e.,
  if they're not intercepted but snooped, there is a potential for
  problematic interactions between the SHIM6 response mechanism to an
  ICMP message and the transport protocol response mechanism.


Section 3.5., paragraph 1:
> Efficient congestion
> control over multiple paths is a considered research at the time this
> specification is written.

  Yes, multipath congestion control is research, and because SHIM6
  prevents transports from being aware about the actual paths that are
  available or being used (because it overloads addresses), it
  effectively prevents the use of any future multipath congestion
  control transports.


Section 1., paragraph 0:
> 1.  To avoid the other side from concluding there is a reachability
>    failure, it's necessary for a host implementing the failure
>    detection mechanism to generate periodic keepalives when there is
>    no other traffic.

  Many transport protocols went to great lengths in order to not needing
  to send keepalives when there is no payload data to be exchanged.
  Introducing keepalives at the SHIM6 layer basically eliminates the
  benefits of that design choice. Why does SHIM6 exchange keepalives to
  test connectivity if the transport protocols don't have any data to
  exchange? Also, there's already the issue with battery drain caused by
  NAT keepalives (cf. the SAFE BOF); this mechanism exacerbates this
  problem.


Section 1., paragraph 2:
>    The interval after which keepalives are sent is named Keepalive
>    Interval.  This document doesn't specify a value for Keepalive
>    Interval, but recognizes that an often used approach is sending
>    keepalives at one-half to one-third of the Keepalive Timeout
>    interval, so that multiple keepalives are generated and have time
>    to reach the correspondent before it times out.  An upper bound
>    on this interval would be (Keepalive Timeout - 2) seconds, so
>    that one keepalive has time to reach the other side, assuming a
>    maximum one-way delay of 2 seconds.

  A path that includes two GSM access links can easily have a
  propagation delay > 2 seconds. Also, if this document doesn't specify
  the intervals, which document is?


Section 6., paragraph 1:
> Section 7 provides some suggested defaults for these timeout values.
> Experience from the deployment of the SHIM6 protocol is needed in
> order to determine what values are most suitable.  The setting of
> these values is also related to various parameters in transport
> protocols, such as TCP keepalive interval.

  (From Bernard's tsv-dir review.) Negotiation of a static SHIM6
  Keepalive timeout, is allowed, if different from the default value.
  However, this relationship is not explored.  The TCP keepalive
  interval is generally kept quite large, partly out of a desire not to
  tear down idle TCP connections due to a transient failure.  The SHIM6
  keepalive interval during idle is not defined in the Failure Detection
  document, but my impression was that it could be much shorter and
  this would seem to collide with the philosophy of TCP keepalives.  So
  I'm not clear what the above sentence means.


Section 4.2., paragraph 6:
> Upon changing to a new address pair, the network path traversed most
> likely has changed, so that the ULP SHOULD be informed.  This can be
> a signal for the ULP to adapt due to the change in path so that, for
> example, TCP could initiate a slow start procedure, although it's
> likely that the circumstances that led to the selection of a new path
> already caused enough packet loss to trigger slow start.

  There is currently no clear approach for how transport protocols
  should react to connectivity change indications. Suggest to remove
  everything after and including the "for example".


Section 4.2., paragraph 7:
> Similarly, one can also envision that applications would be able to
> tell the IP or transport layer that the current connection in
> unsatisfactory and an exploration for a better one would be
> desirable.  This would require an inter-layer communication mechanism
> to be developed, however.  In any case, this is another issue that we
> treat as being outside the scope of pure address exploration.

  One can envision this, but it's completely unclear what
  "unsatisfactory" and "better" means in this regard. Also, the SHIM6
  mechanism selects *a* path, but doesn't attempt to select one
  according to a specific set of criteria. Not sure if this paragraph is
  helpful - remove?


Section 4.3., paragraph 5:
> Section 7 suggests default values for the timers associated with the
> exploration process.  The value Initial Probe Timeout (0.5 seconds)
> specifies the interval between initial attempts to send probes;
> Number of Initial Probes (4) specifies how many initial probes can be
> sent before the exponential backoff procedure needs to be employed.
> This process increases the time between every probe if there is no
> response.  Typically, each increase doubles the time but this
> specification does not mandate a particular increase.

  (From Bernard's tsv-dir review.) Interactions of SHIM6 with congestion
  control.  Section 4.3 of the Failure Detection document talks about
  exploration timeout values.  Exploration can be kicked off if no
  inbound traffic is received within Send Timeout (default = 10
  seconds). The first observation is that the Send Timeout should
  probably depend on the RTO estimate, as it does in SCTP.  Otherwise we
  could have a  network with a high RTO and SHIM6 exploration could
  commence after RTO is  backed off only a few times.  This would be
  undesirable from a congestion  control point of view. The suggested
  value of the Initial Probe Timeout (500ms) is less than RTOmin and 4
  probes can be sent before initiating exponential backoff.  This seems
  like it could violate "conservation of packets".  Why doesn't
  exponential backoff begin immediately? Instead of a static default
  Initial Probe Timeout value, might it make sense to base this on RTO
  estimates?  Again, in SCTP these issues  are handled due to
  integration with the transport layer.


Section 7., paragraph 4:
> Alternate values of the Send Timeout may be selected by a host and
> communicated to the peer in the Keepalive Timeout Option.

  Guidance is needed on appropriate and inappropriate values for the
  send timeout.

[Ballot discuss]
Section 3.3., paragraph 6:
>    Forced Bidirectional Communication (FBD), described later in this
>    specification.  In addition, implementations MAY employ the following
>    additional mechanisms:

  DISCUSS: All of the MAYs below are referring to techniques that are
  basically research ideas that are neither fully specified nor
  experimentally vetted - permitting them to be used is thus not
  appropriate. (See the comments marked with "MAY" below.)


Section 4.3., paragraph 0:
> 4.3.  Exploration Order

  DISCUSS: The specification of the probing algorithm needs to be made
  more precise. It remains unclear how the various timers control the
  transmission of the probe packets across all interfaces, how backoff
  is handled and retries are scheduled. Suggest to look at the ICE or
  DHCP specs for examples.


Section 7., paragraph 2:
> Keepalive Interval                          Not specified here

  DISCUSS: Where is it specified then? It's a critical parameter.

[Ballot comment]
It would be appropriate to include in Section 9 a recommendation that failure detections and switch-over events to a backup path be communicated via asynchronous notifications to managament systems (if available) and recorded in events logs.

[Ballot discuss]
The main SHIM6 protocol document discusses a bit about firewalls. I think this discussion is even more relevant in the context of REAP. If a firewall isn't SHIM6 and REAP compliant then you get very interesting cases, especially if you actually managed to get into SHIM6 mode. Sure, the intention is that shouldn't happen. But I am worried over the inconsistencies that are likely to occur because PROBE and keep-alive packets are not having a transport layer and the actual data packets do have. As I see it both the case of data getting through but not REAP and the  inverse may happen. I would like to have some discussion on these failure cases.

[Ballot discuss]
The semantics of the protocol and state machinery is less robust than what is defined for BFD. It is unclear why something less robust is required for this application vs reusing BFD machinery.

[Ballot comment]
From the SecDir by Steve Kent:
  >
  > This discussion does a good job of exploring the DoS concerns
  > related to use of REAP with SHIM6. However, I would like to see a
  > paragraph or two explaining why the designers of REAP chose to not
  > use a protocol like IPsec to provide security for REAP. I am not
  > saying the choice made here is bad, but rather that it would be
  > useful to capture the rationale behind the choice.
  >
  I saw a response, and there seemed to be agreement that the
  requested paragraph seems like a good thing.  Where is it?

[Ballot discuss]
I have not seen a response to the Gen-ART Review by Eric Gray.
  The rewiew deserves a response.  It can be found at:
 
    http://www.alvestrand.no/ietf/gen/reviews/
    draft-ietf-shim6-failure-detection-09-gray.txt

  I am especially concerned about this part of the review:
  >
  > I looked through RFC 2461 for some time and still am not sure I've
  > discovered what "valid in the sense of RFC 2461" actually means.
  >
  > Is it valid if it has a valid prefix, if it is within its valid
  > lifetime, both, neither?  Could you summarize, please?
  >
  > I did note that "tentative in the sense of RFC 2462" is far easier
  > to determine (the phrase "tentative address" is explicitly defined
  > there).

[Ballot discuss]
The document has no analysis or information related to the operational impact or manageability of the protocol. I would have expected as a minimum that the document includes some information about possible impact on hosts and network behavior like levels of traffic, whether any parameters on hosts running the protocol are configurable and how, observability of status and performance parameters, any alarms reporting or logging.

[Ballot comment]
Section 4.3 Exploration Order, first sentence of paragraph 2 is slightly mangled:

  Nodes first consult the RFC 3484 default address selection rules
  [RFC3484] Section 4 rules to determine what combinations of addresses
  are allowed from a local point of view, as this reduces the search
  space.

The address selection rules in RFC 3484 are specified in sections 5 and 6; section 4
is "Candidate Source Addresses".  I believe deleting "Section 4 rules" following the
[RFC3484] reference is a complete fix.

[Ballot discuss]
This is a placeholder DISCUSS until we're clear that the issues from Bernard Abobas tsv-dir review have been addressed: http://www1.ietf.org/mail-archive/web/ietf/current/msg49109.html

(I may add to this DISCUSS based on my own IESG review.)

(1.a)  Who is the Document Shepherd for this document?
 
          Geoff Huston
         
      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?
     
          Yes

(1.b) Has the document had adequate review both from key members of
      the interested community and others? 
     
        Yes, the document has been explicitly called to the attention of
the Working Group on a number of occasions, and review comments
have been incorporated into the document.
                 
      Does the Document Shepherd have any concerns about the depth or
      breadth of the reviews that have been performed?
     
        The Document Shepherd is comfortable with the level of review of
this document.

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

        The document has been revieweed extensively over the past 15
months and the Document Shepherd is comfortable with the
competence and breadth of review of this document.
       
(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 interested community has discussed those issues and has
      indicated that it still wishes to advance the document, detail
      those concerns here.
     

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

        The document has been reviewed from a range of perspectives and
has generated review comment from these perspectives. The
consensus behind this document appears to be well-founded.
       
(1.f) Has anyone threatened an appeal or otherwise indicated extreme
      discontent?  If so, please summarise 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.
       

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

There are a number of document typos. The list is:

page 8: s"rechability"reachability"
page 12: s"to to"to"
page 16: s"options.The"options. The"
page 19: s"messsage"message"
page 20: s"recommeded"recommended"
page 23: s"and and"and"
page 32: s"draft-ietf-dna-protocol-05"draft-ietf-dna-protocol-06"
page 32: s"draft-ietf-shim6-locator-pair-selection-01"draft-ietf-shim6-locator-pair-selection-02"

        The Document Shepherd is of the view that the reference:
       
        [I-D.ietf-shim6-proto]
              Bagnulo, M. and E. Nordmark, "Shim6: Level 3 Multihoming
              Shim Protocol for IPv6", draft-ietf-shim6-proto-08 (work
              in progress), April 2007.


        should be a normative reference to the shim6 protocol document,
rather than an informative reference.
     

(1.h) Has the document split its references into normative and
      informative? 
     
        Yes
       
      Are there normative references to documents that are
      not ready for advancement or are otherwise in an unclear state?
     
        No
       
      If such normative references exist, what is the strategy for their
      completion?
     
        N/A
       
      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].
     
        No

         
(1.i) Has the Document Shepherd verified that the document IANA
      consideration section exists and is consistent with the body of
      the document? 
     
        Yes
       
      If the document specifies protocol extensions, are reservations
      requested in appropriate IANA registries?
     
        There are no IANA actions required in this document.
       
      Are the IANA registries clearly identified?
     
        N/A
       
      If the document creates a new registry, does it define the proposed
      initial contents of the registry and an allocation procedure for
      future registrations?
     
        N/A
       
      Does it suggested a reasonable name for the new registry?  See
      [I-D.narten-iana-considerations-rfc2434bis]. 
     
        N/A
       
      If the document describes an Expert Review process has Shepherd
      conferred with the Responsible Area Director so that the IESG can
      appoint the needed Expert during the IESG Evaluation?
     
        N/A
       
(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?

        N/A
       

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

      Technical Summary

        This document specifies how the level 3 multihoming shim protocol
(SHIM6) detects failures between two communicating hosts that are
using this protocol.  It also specifies an exploration protocol
for identifying a viable pair of interfaces and/or addresses
between SHIM6 hosts.

      Working Group Summary

        The document has extensively reviewed by the Working Group. The
Working Group consensus was to recommend publication of this
document as a Proposed Standard.
       
      Document Quality

        There are known implementations of this specification, and there
have been no implemtation experiences that have implied any
further revision to this specification is required.
       

Additional note:

        The document is being passed to the IESG as part of a set of three
documents that the Working Group has determined by consensus in
the WG Last Calls has requested to be published as Proposed
Standards. The Document Shepherd is aware that there have been
suggestions to publish initially as Experimental, and notes that
the Working Group Last Call specifically noted the intended
request to publish as a Proposed Standard, and this request is
based on that Working Group consensus position.
       
        The specification meets all the criteria of section 4.1.1 of RFC
2026, in that the specification is stable, has resolved design
choices, is believed to be well understood and has received
considerable community interest. The specification has no known
technical omissions.
       
        In addition, there are a number of implementations of the
        specification, but little in the way of operational
        experience, interoperability between implementations and
        interaction with application behaviour to report on at this
        stage.