Re: [Gen-art] [Softwires] Gen-ART review of draft-ietf-softwire-hs-framework-l2tpv2-10
After a lengthy private discussion with Carlos, and some serious quality time spent with RFC 2661 ;-), here's where I think the two major issues from my Gen-ART review of this draft stand: (1) AVP for softwire profile of L2TPv2. I'm no longer convinced that a new AVP is needed, but the specification of the profile needs significant clarification and cleanup. For example, what happens if a softwire implementation of L2TPv2 happens to receive an OCRQ message? This has also turned up a topic that needs to be covered in the Security Considerations section - a brief discussion of the security consequences of the recommendation not to hide AVPs. (2) RFC 5405 and UDP. In addition to referencing RFC 5405, a recommendation for L2TPv2 use of PMTUD will be added. Thanks, --David David L. Black, Distinguished Engineer EMC Corporation, 176 South St., Hopkinton, MA 01748 +1 (508) 293-7953 FAX: +1 (508) 293-7786 black_da...@emc.comMobile: +1 (978) 394-7754 ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
Re: [Gen-art] [Softwires] Gen-ART review of draft-ietf-softwire-hs-framework-l2tpv2-10
Carlos Pignataro wrote: WG, On 12/22/2008 7:49 PM, black_da...@emc.com said the following: After a lengthy private discussion with Carlos, and some serious quality time spent with RFC 2661 ;-), here's where I think the two major issues from my Gen-ART review of this draft stand: (1) AVP for softwire profile of L2TPv2. I'm no longer convinced that a new AVP is needed, but the specification of the profile needs significant clarification and cleanup. For completeness, I do not think that significant cleanup is needed, but rather that some localized editorial clarifications of context might help the reader. In any case, one of the big decisions in this discussion is that there's no new softwire AVP, and some fall out is that S5.1.1.X can use more specific descriptions. For example, what happens if a softwire implementation of L2TPv2 happens to receive an OCRQ message? For example, draft-ietf-softwire-hs-framework-l2tpv2 specifies that: in the Softwire context, the voluntary tunneling model applies ... Since L2TPv2 compulsory tunneling model does not apply to Softwires, it should not be requested or honored. ... In the Softwire Hub and Spoke model, the Softwire Initiator (SI) assumes the role of the LAC Client And more notably: No outgoing or analog calls are permitted. So, if a softwire implementation of L2TPv2 happens to receive an OCRQ message, it needs to CDN it (as strongly hinted though not explicitly spelled out; for a versatile and variation-rich protocol as L2TP a this seems a self-evident exception protocol paths for softwire). The fall-through protocol definition lies in RFC2661 (the doc says as defined in [RFC2661]), and that scenario is the same as if a full RFC2661 implementation of L2TP not configured for outgoing calls receives an OCRQ message. That was certainly my thinking here... If OCRQ functionality is not supported, send a CDN. This has also turned up a topic that needs to be covered in the Security Considerations section - a brief discussion of the security consequences of the recommendation not to hide AVPs. Right, this is one new thing that came up, from looking into the Random Vector AVP. The document is recommending not to hide AVPs, from the very original text. But, I think, the document MAY allow AVP hiding (instead of describing the consequences of not hiding). I see no problem updating the security considerations to point out the weaknesses of the hiding mechanism with 2009 knowledge vs. the 1999 state of the art when L2TP first made it from draft to RFC. - Mark (2) RFC 5405 and UDP. In addition to referencing RFC 5405, a recommendation for L2TPv2 use of PMTUD will be added. We will describe all the changes when we post an updated version of the document. Thanks, --Carlos. Thanks, --David David L. Black, Distinguished Engineer EMC Corporation, 176 South St., Hopkinton, MA 01748 +1 (508) 293-7953 FAX: +1 (508) 293-7786 black_da...@emc.comMobile: +1 (978) 394-7754 ___ Gen-art mailing list Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
Re: [Gen-art] [Softwires] Gen-ART review of draft-ietf-softwire-hs-framework-l2tpv2-10
Carlos, (1) AVP for softwire profile of L2TPv2. I can mostly agree with the following: 2. The softwire application does not define any requirement over RFC2661 (it does not differ, it's only a subset), and thus such signaling of the softwire profile would be solely informational. If a softwire profile implementation of L2TPv2 talks to a full RFC2661 implementation, the latter may be in for a few surprises courtesy of the subsetting. Would it be reasonable to define an informational AVP that the softwire profile implementation would send solely to inform its peer that the other end of the session is behaving according to the software profile? If the RFC2661 implementation logs that informational AVP (at least if debugging is turned on), that might be helpful to someone trying to figure out what's going on if a softwire profile implementation of L2TPv2 tries to talk to a full RFC2661 implementation. (2) RFC 5405 and UDP. We don't have strong feelings here one way of another, what do others think? Maybe the middle ground is to cite RFC 5405 as an Informational reference, just saying what you said (that Section 3.1.3 of RFC 5405 specifies that for this case no additional congestion control is required followed (maybe) by , and other considerations may apply - not MAY apply)? The version of that text with other considerations may apply for me. The one other possibly relevant topic that immediately comes to mind is the MTU. Section 5.2.1 of your draft already covers the MTU reduction effects of the tunnel headers, and that's probably enough. Section 3.2 of RFC 5405 (on Message Size) would apply to UDP over an IP softwire, not the UDP encapsulation within the softwire (the latter manifests as the IP MTU of the softwire link). The description of what is to be done about the remaining minor items is fine with me. Thanks, --David -Original Message- From: gen-art-boun...@ietf.org [mailto:gen-art-boun...@ietf.org] On Behalf Of Carlos Pignataro Sent: Friday, December 12, 2008 9:43 AM To: Black, David Cc: softwi...@ietf.org; W. Mark Townsley; gen-art@ietf.org; Jari Arkko Subject: Re: [Gen-art] [Softwires] Gen-ART reviewof draft-ietf-softwire-hs-framework-l2tpv2-10 Alain, Mark, We are planning on posting a new revision -11 when we close on these. David, Thanks again for the review, please see inline. On 12/10/2008 2:03 PM, Carlos Pignataro said the following: David, Thanks much for taking the time to read the draft and for providing this feedback! This is an Ack, we'll reply later, with answers/text to address these open issues. Thanks, --Carlos. On 12/10/2008 11:47 AM, black_da...@emc.com said the following: I have been selected as the General Area Review Team (Gen-ART) reviewer for this draft (for background on Gen-ART, please see http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html). Please resolve these comments along with any other Last Call comments you may receive. Document: draft-ietf-softwire-hs-framework-l2tpv2-10 Reviewer: David L. Black Review Date: December 10, 2008 IETF LC End Date: December 15, 2008 Summary: This draft is on the right track, but has open issues, described in the review. Comments: The draft is well-written, with a lot of details that will be valuable to implementers. I have two open issues: (1) Section 5.1 of this draft is clearly defining a softwire profile of L2TPv2 in that it states extensive requirements on AVP usage (and AVP contents in some cases) for softwires. Use of this profile is not explicitly signaled - the expectation is that both the SI and SC will be implemented in accordance with this draft, and won't try to communicate with L2TPv2 implementations that aren't using this profile. As the requirements of this softwire profile appear to differ from RFC 2661, defining an AVP to signal use of this profile seems like a good idea (its use should be required). We think we shouldn't define a new Softwire Profile AVP, for a number of reasons: 1. From the Softwire Problem Statement [RFC4925], there is an emphasis in using existing protocols and extending where necessary (see [1] at the bottom). This document does not make any protocol extensions to standards L2TPv2, so this is best case from a requirements standpoint, and to change that there would need to be a significant benefit. 2. The softwire application does not define any requirement over RFC2661 (it does not differ, it's only a subset), and thus such signaling of the softwire profile would be solely informational. OTOH, if enforced, it could potentially limit interop. 3. We don;t think that an additional AVP would provide benefits in terms of interoperability. The requirement in section 5.1.1.3 to silently ignore unknown or irrelevant AVPs seems enough. That allows for interoperability of different versions of
Re: [Gen-art] [Softwires] Gen-ART review of draft-ietf-softwire-hs-framework-l2tpv2-10
Alain, Mark, We are planning on posting a new revision -11 when we close on these. David, Thanks again for the review, please see inline. On 12/10/2008 2:03 PM, Carlos Pignataro said the following: David, Thanks much for taking the time to read the draft and for providing this feedback! This is an Ack, we'll reply later, with answers/text to address these open issues. Thanks, --Carlos. On 12/10/2008 11:47 AM, black_da...@emc.com said the following: I have been selected as the General Area Review Team (Gen-ART) reviewer for this draft (for background on Gen-ART, please see http://www.alvestrand.no/ietf/gen/art/gen-art-FAQ.html). Please resolve these comments along with any other Last Call comments you may receive. Document: draft-ietf-softwire-hs-framework-l2tpv2-10 Reviewer: David L. Black Review Date: December 10, 2008 IETF LC End Date: December 15, 2008 Summary: This draft is on the right track, but has open issues, described in the review. Comments: The draft is well-written, with a lot of details that will be valuable to implementers. I have two open issues: (1) Section 5.1 of this draft is clearly defining a softwire profile of L2TPv2 in that it states extensive requirements on AVP usage (and AVP contents in some cases) for softwires. Use of this profile is not explicitly signaled - the expectation is that both the SI and SC will be implemented in accordance with this draft, and won't try to communicate with L2TPv2 implementations that aren't using this profile. As the requirements of this softwire profile appear to differ from RFC 2661, defining an AVP to signal use of this profile seems like a good idea (its use should be required). We think we shouldn't define a new Softwire Profile AVP, for a number of reasons: 1. From the Softwire Problem Statement [RFC4925], there is an emphasis in using existing protocols and extending where necessary (see [1] at the bottom). This document does not make any protocol extensions to standards L2TPv2, so this is best case from a requirements standpoint, and to change that there would need to be a significant benefit. 2. The softwire application does not define any requirement over RFC2661 (it does not differ, it's only a subset), and thus such signaling of the softwire profile would be solely informational. OTOH, if enforced, it could potentially limit interop. 3. We don;t think that an additional AVP would provide benefits in terms of interoperability. The requirement in section 5.1.1.3 to silently ignore unknown or irrelevant AVPs seems enough. That allows for interoperability of different versions of softwire that might use extra AVPs in the future. (2) This is more of a minor annoyance than an open issue, but it does need attention. This draft uses UDP as part of an IP-in-IP tunnel, so the UDP guidelines in RFC 5405 apply. Note that Section 3.1.3 of RFC 5405 indicates that no additional congestion control is required for this scenario beyond what is already done for the IP traffic carried through the tunnel. That should be noted in this draft, and RFC 5405 should be scanned for any other considerations that may apply to this draft. The softwire scenarios carry IP, and like you said, fall under the Section 3.1.3 of RFC 5405 [2], which is a noop for the softwire case from a congestion control standpoint. On one hand side, it feels odd and non-causal to add requirements (spec'd after L2TP) for a protocol used as-is from when defined in RFC2661. This draft is not defining the tunneling protocol. OTOH, those are good guidelines and would not hurt. We don't have strong feelings here one way of another, what do others think? Maybe the middle ground is to cite RFC 5405 as an Informational reference, just saying what you said (that Section 3.1.3 of RFC 5405 specifies that for this case no additional congestion control is required followed (maybe) by , and other considerations may apply - not MAY apply)? How were you suggesting we point to RFC5405, and where specifically in the text? Everything else I found is relatively minor: - Please add CPE and LNS to the abbreviations section. Done. - Most of the text after the figure in each of Sections 3.1.1 through 3.1.4 is common. Consider factoring it out into one location. Ditto for 3.2.1 to 3.2.4. It's fine to not do this if the result would be difficult to follow. The common factors are (mostly) in pairs of sections (S3.1.1 with S3.1.3, and S3.1.2 with S3.1.4). Also, there are slight variations in each sub-sub-section (e.g., router behind CPE, vs. CPE router, etc.) that fragment the common factors even more. We think if factoring portions out, the result would be harder to follow. - In Section 5.1.1.3, please clarify that the SHOULD NOT send requirement applies only to AVPs not covered in sections 5.1.1, 5.1.1.1 and 5.1.1.2 . Done. - I found a number of lower case instances
