David, On 12/12/2008 8:02 PM, [email protected] said the following: > 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.
Not really: the subset is on optional AVPs, on sending (i.e., out of the RFC2661 optional AVPs, these are useful for softwire with the following usage, don't send the rest); and additional guidance on how to use the mandatory AVPs in the softwire context (i.e., for these RFC2661 mandatory AVPs, these values make sense for softwire). A full RFC2661 implementation should not choke. > > 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? I think the above + reason #1, minimize protocol changes to only when it's necessary, weights much more given that there are informational AVPs (orthogonal to softwire) that are defined for logging in a more generic way and can be used to say "softwire here". There's also an expectation that an end knows what it's trying to connect to as well. And... > > 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. ... the usage would be only for logging/debugging/troubleshooting purposes and not for protocol states/decisions. If you think it helps, and it's not redundant, we can add a paragraph saying that the use of existing informational AVPs (or more generically methods) used for logging is not prevented in the softwire context. > > (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. OK. > 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"). OK, a pointer to Section 8.1 of RFC2661 + Section 3.2 of RFC 5405, and suggest the use of PMTUD? Perhaps a new Section 5.1.4 with "Additional L2TPv2 Considerations", describing these 2 issues ((1) and (2))? Or maybe (1), if included, fits better in Section 9 (since the logging can happen outside l2tp as well)? > > The description of what is to be done about the remaining minor > items is fine with me. OK. Thanks, --Carlos. > > Thanks, > --David > > >> -----Original Message----- >> From: [email protected] >> [mailto:[email protected]] On Behalf Of Carlos Pignataro >> Sent: Friday, December 12, 2008 9:43 AM >> To: Black, David >> Cc: [email protected]; W. Mark Townsley; [email protected]; 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, [email protected] 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 of "must", "should" >>>> and "may" that are candidates for upper case (i.e., >>>> RFC 2119 usage). Please check all of these and upper case >>>> as appropriate. >> We did do this exercise already, as you can see in the doc's >> changelog: >> o Fixed some RFC2119 keywords in Section 3.1.1, Section 3.1.2, >> Section 3.1.3, Section 3.1.4, Section 3.2.1, Section 3.2.2, >> Section 3.2.3, Section 3.2.4, Section 5.1.1.3, Section >> 5.4.2, and >> Section 8.1.1. >> >> Also, there are "Considerations" sections (Section 6 though >> 9) which we >> agreed are non normative: >> <http://tools.ietf.org/html/draft-ietf-softwire-hs-framework-l > 2tpv2-10#section-1.4>. >> However, it does seem that we did miss some instances that could be >> uppercased, most importantly in sub-Sections 5.X. Thanks for >> the suggestion. >> >> We identified: 1 should not, 1 must, 4 may's, and 1 should that needed >> to be uppercased (and one should -> may). >> >> >>>> - Please expand the ULA acronym on its first use in Section >>>> 6.1.1 . >> Done (actually added the acronym between the ULA expansion >> and citation >> in the previous para in Section 6.1.1, same result). >> >> Please let us know your comments on our responses, so we post a new >> revision. >> >> 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 >>>> [email protected] Mobile: +1 (978) 394-7754 >>>> ---------------------------------------------------- >>>> >> [1] from RFC4925: >> The standards will encourage multiple, inter-operable >> vendor implementations by identifying, and extending where >> necessary, >> existing standard protocols to resolve a selected set of >> "IPv4/IPv6" >> and "IPv6/IPv4" transition problems. >> ... >> Softwire concentrator functionality will be based on existing >> standards for tunneling, prefixes, and addresses allocation, >> management. >> >> [2] from RFC5405: >> Consequently, a tunnel carrying >> IP-based traffic should already interact appropriately with other >> traffic sharing the path, and specific congestion control >> mechanisms >> for the tunnel are not necessary. >> >> >> -- >> --Carlos Pignataro. >> Escalation RTP - cisco Systems >> >> >> >> >> >> >> >> _______________________________________________ >> Gen-art mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/gen-art >> >> > -- --Carlos Pignataro. Escalation RTP - cisco Systems _______________________________________________ Softwires mailing list [email protected] https://www.ietf.org/mailman/listinfo/softwires
