Softwire Mesh Framework
Summary: Needs a YES. Needs 9 more YES or NO OBJECTION positions to pass.
Note: This ballot was opened for revision 05 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 -)
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 -)
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
( 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 for -06)
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.