Softwire Mesh Framework
RFC 5565

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

(Lisa Dusseault) Yes

(Mark Townsley) Yes

(Jari Arkko) No Objection

(Ron Bonica) (was No Record, No Objection) No Objection

Comment (2009-01-27 for -)
No email
send info
You use the acronym AFBR before you define it.

(Ross Callon) No Objection

Lars Eggert No Objection

(Pasi Eronen) No Objection

(Russ Housley) No Objection

Comment (2009-01-28 for -)
No email
send info
  The Gen-ART Review by Francis Dupont that was posted on 15-Dec-2008

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

(Cullen Jennings) No Objection

(Chris Newman) No Objection

(Jon Peterson) No Objection

(Tim Polk) (was No Record, Discuss) No Objection

(Magnus Westerlund) No Objection

(Dan Romascanu) (was Discuss) Abstain

Comment (2009-03-26)
No email
send info
The OPS-DIR review by Pekka Savola posted at 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.

(David Ward) Recuse