Re: [Softwires] Gen-ART review of draft-ietf-softwire-hs-framework-l2tpv2-10

[Carlos Pignataro <[e-mail]>]

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, [e-mail] 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-l2tpv2-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
>> [phone]             FAX: [phone]
>> [e-mail]        Mobile: [phone]
>> ----------------------------------------------------
>>
> 

[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







_______________________________________________
Softwires mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/softwires