datatracker.ietf.org
Sign in
Version 5.3.0, 2014-04-12
Report a bug

Softwire Mesh Framework
RFC 5565

No Objection
(was No Record, No Objection)
(was No Record, Discuss)
Abstain
(was Discuss)
Recuse

Note: This ballot was opened for revision 05 and is now closed.

Summary: Needs a YES. Needs 9 more YES or NO OBJECTION positions to pass.

[Dan Romascanu]

Comment (2009-03-26)

The OPS-DIR review by Pekka Savola posted at
http://www.ietf.org/mail-archive/web/softwires/current/msg00731.html on 12/17
raised a number of issues. Despite the dialog that followed the review, only
part of them were addressed with editorial proposals. Specifically I think that
the following issues from the OPS-DIR review still need clarification and I
recommend that they will be clarified if a new revision is issued in the future:

1. My main concern here is with the O&M implication of dynamically created and
used softwires, which do not run any routing protocol and there is no IETF
protocol or management framework which could be used to verify the correct
operation of these tunnels.  Essentially this seems to require that operators
deploy about N (where N is the number of connected sites) data probing hosts
which periodically test connectivity with the N-1 other probes.  Or this could
be implemented with proprietary mechanisms at AFBR routers.

Softwires do not run BGP keepalives and do not (apparently) run IGP protocol. 
As a result, it seems difficult for the network operator to notice when/if
connectivity through a softwire no longer works. (Previously, BGP or IGP
timeouts were an indicator for this.)

This is discussed in Section 10 (some further comments on this below).  They
key point there seems to be that there are ways how an operator could build
monitoring to the softwires, but the IETF protocols do not seem to provide a
protocol solution for this (while they do provide such a solution for manually
configured tunnels for example).

This seems like a significant drawback of this solution and I'd like to see O&M
aspects addressed better in the softwires framework.

--------
I did not see any proposal for clarification by text or references of this
issue.

2. In S 10:

   Examples of techniques applicable to softwire OAM include:

      o BGP/TCP timeouts between AFBRs

      o ICMP or LSP echo request and reply addressed to a particular AFBR

... BGP/TCP take a very long time, and their usage only verifies I-IP signaling
path between the endpoints, not data plane.  And what about ICMP or LSP echo --
this is not clear whether it's run over the softwire or using I-IP; I'm
assuming they are not run on top of softwire.

As a result they are not very useful from OAM perspective.  Given that no IGP
is run on top of softwires, debugging E-IP connectivity issues seems quite
painful.  This is exacerbated by the fact that forwarding decisions to softwire
are done by "policy", not by longest prefix matching.  I.e., your O&M
connectivity test procedures also need to test that this policy is working OK,
and testing needs to be done from locations accepted by the policy.  What you
probably need is to build some kind of N^2 matrix of data probes (using 1500B
packet size or like) through the core to verify that all softwires are opering
correctly.  As a result, I'm having great doubts about O&M (reliability,
debuggability, "is it working or not?" indications) aspects of this technology.

---------------

Some explanations were provided in responses by Eric Rosen but I did not see
any proposal for clarification by text or references of this issue.

3. In S 5 (this is also bordering on architectural issue):

                        This leads to the following softwires deployment
    restriction: if a BGP Capability is defined for the case in which an
    E-IP NLRI has an I-IP NH, all the AFBRs in a given transit core MUST
    advertise that capability.

... is there any way an implementation could verify if this deployment
restriction holds not not?  For example, if one of the routers doesn't happen
to support this capability, how will this be detected by the network operator?

------------

Some explanations were provided in responses by Eric Rosen but I did not see
any proposal for clarification by text or references of this issue.

4. Also, in S 4.1:

    The AFBRs handle both I-IP and E-IP. However, only I-IP is used on
    AFBR's "core facing interfaces", and E-IP is only used on its client-
    facing interfaces.

... At some point, a client might want to upgrade to dual stack.  Then,
client-interface may use both E-IP and I-IP.  This solution should be
applicable then as well (just that mesh tunnels won't be used for I-IP from a
client port).  I think it is, but this needs to be made clear.

---------------------

Eric acknowledged that depending on policy, one might or might not want to do,
e.g., v6/v6 or v4/v4 encapsulation, but considered the issue out of charter.
Pekka clarified that the issue is client behavior atupgrades from v4-only to
dual-stack, and that the issue is important from an operational point of view
and needs clarification. I did not see any proposal for clarification by text
or references.

[Ron Bonica]

Comment (2009-01-27)

You use the acronym AFBR before you define it.

[Russ Housley]

Comment (2009-01-28)

  The Gen-ART Review by Francis Dupont that was posted on 15-Dec-2008
  says:

  The document is very unpleasant to read and have some editorial nits:
  - page 1: too many authors (proposal: keep editor(s) and add a section
    with the full list of authors. It is a common problem so the solution
    should be well known)
  - Abstract page 2: too long
  - Abstract page 2: the position of softwire mesh vs general overlay is
    not explained (but as the Abstract is already too long...)
  - 3.1 page 8: figure 1 has some nits (just fix them or warn the RFC
    editor)
  - 3.2 page 10: same for figure 2 with more nits
  - 5 page 13: in the E-IP family, and -> in the E-IP family,
    (i.e., keep only the last "and")
  - 5 page 14: i.e. -> i.e.,
  - 7 page 16: core, send the packet -> core, then send the packet
  - 10.1 page 18: the [RFC4378] -> [RFC4378]
  - 10.1 page 19: trade offs -> trade-offs ?
  - 10.1 page 19: verses -> versus
  - 11.1 page 20: unbounded -> unbound ?
  - 11.2 page 23: Lan-Like -> LAN-Like (or LAN-like)
  - 14.1 page 24: playback -> replay
  - 14.3 page 28: (the only technical issue) there is no more a "main mode"
    in IKEv2. BTW the text seems to mandate preshared keys when IMHO it
    requires only automatical SA establishment (better than key distribution).
  - Authors' page 30: too many authors