Softwire Mesh Framework
draft-ietf-softwire-mesh-framework-06

[Ballot comment]
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.

[Ballot discuss]
[My apologies for the late revision... I missed Tero's secdir review.  It also needs to be addressed.]

Julien Laganier's secdir review (posted 16 December, 2008) raised several significant
issues that have not been resolved.  Tero Kvinen's review (16 January) raised additional
issues (no more main mode, and the discussion of pre-shared keys) that needs to be fixed.

[Ballot discuss]
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, none of them was addressed with editorial proposals. Specifically I think that the following issues from the OPS-DIR review need clarification:

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. The document does not describe MTU and fragmentation/reassembly issues in the core network at all.  In this kind of service my assumption is that you need to support 1500B packets at ingress when DF-bit is set or the packet is IPv6.  Discussion in RFC4459 seems applicable here.  The operational solution to this problem is the requirement to provision the core network with larger MTUs so that all 1500B+encapsulation overhead can be supported throughout the core.  This needs to be discussed in the text.

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

This issue was acknowledged by Eric in one of his responses but I did not see any proposal for clarification by text or references.

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

6.    In the case where E-IP is IPv4 and I-IP is IPv6, it is possible to do
    this translation algorithmically.  A can translate the IPv4 S and G
    into the corresponding IPv4-mapped IPv6 addresses [RFC4291], and then
    B can translate them back.  The precise circumstances under which
    these translations are done would be a matter of policy.

... But the corresponding IPv4-mapped IPv6 address for G is not a multicast address because it does not start with FF00::/8, and I suspect as a result all implementations will treat such a G address as a unicast address.  I guess one could fix this by standardizing a  group mapping to use some multicast prefix under ff00::/8 and encode the v4 address in the bottom bits.

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

The issue was acknowledged in the response from Eric, but I did not see any proposal for clarification by text or references.

[Ballot comment]
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

draft-ietf-softwire-mesh-framework-05.txt

PROTO questionnaire for:
prepared by: Dave Ward (dward@cisco.com)

1.a) Have the chairs personally reviewed this version of the Internet
Draft (ID), and in particular, do they believe this ID is ready
to forward to the IESG for publication? Which chair is the WG
Chair Shepherd for this document?

Dave Ward

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

No.

1.d) Do you have any specific concerns/issues with this document
that
you believe the ADs and/or IESG should be aware of? For
example, perhaps you are uncomfortable with certain parts of
the
document, or have concerns whether there really is a need for
it. In any event, if your issues have been discussed in the WG
and the WG has indicated it that it still wishes to advance the
document, detail those concerns in the write-up.

No.

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?

There is strong WG consensus behind this document and no one that has
expressed concerns about its progression.

1.f) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in
separate email to the Responsible Area Director. (It should be
separate email because this questionnaire will be entered into
the tracker).
No.

1.g) Have the chairs verified that the document checks out against
all the ID nits? (see http://www.ietf.org/ID-Checklist.html).
Boilerplate checks are not enough; this check needs to be
thorough.

Yes.

1.h) Has the document split its references into normative and
informative? Are there normative references to IDs, where the
IDs are not also ready for advancement or are otherwise in an
unclear state? The RFC Editor will not publish an RFC with
normative references to IDs (will delay the publication until
all such IDs are also ready for RFC publicatioin). If the
normative references are behind, what is the strategy for their
completion? On a related matter, are there normative
references
that are downward references, as described in BCP 97, RFC 3967
RFC 3967 [RFC3967]? Listing these supports the Area
Director in
the Last Call downref procedure specified in RFC 3967.

The references are split into normative and informative.


Protocol write-up for:
by Dave Ward, dward@cisco.com

Technical Summary

The Internet needs to be able to handle both IPv4 and IPv6 packets.
However, it is expected that some constituent networks of the
Internet will be "single protocol" networks. One kind of single
protocol network can parse only IPv4 packets and can process only
IPv4 routing information; another kind can parse only IPv6 packets
and can process only IPv6 routing information. It is nevertheless
required that either kind of single protocol network be able to
provide transit service for the "other" protocol. This is done by
passing the "other kind" of routing information from one edge of the
single protocol network to the other, and by tunneling the "other
kind" of data packet from one edge to the other. The tunnels are
known as "Softwires". This framework document explains how the
routing information and the data packets of one protocol are passed
through a single protocol network of the other protocol. The
document is careful to specify when this can be done with existing
technology, and when it requires the development of new or modified
technology.


Working Group Summary

The SOFTWIRE WG supports the development and advancement of this
document.


Protocol Quality

This document was thoroughly reviewed by WG chairs and WG members,
including those with expertise in IPv4 to IPv6 transitions and
interworking.

Dave Ward is the WG chair shepherd. Mark Townsley is the
responsible Area
director.