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

From: [email-masked]
Date: Wed, 10 Dec 2008 11:47:20 -0500

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

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

Everything else I found is relatively minor:
- Please add CPE and LNS to the abbreviations section.
- 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.
- 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 .
- 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.
- Please expand the ULA acronym on its first use in Section
	6.1.1 .

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-masked]        Mobile: +1 (978) 394-7754
----------------------------------------------------
_______________________________________________
Softwires mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/softwires

---

From: Carlos Pignataro <[email-masked]>
Date: Wed, 10 Dec 2008 14:03:53 -0500

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.

-- 
--Carlos Pignataro.
Escalation RTP - cisco Systems
_______________________________________________
Softwires mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/softwires

---

From: Carlos Pignataro <[email-masked]>
Date: Fri, 12 Dec 2008 09:42:57 -0500

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.

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

>> should be scanned for any other considerations that may apply

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?

>> - Please add CPE and LNS to the abbreviations section.

Done.

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

>> 	5.1.1, 5.1.1.1 and 5.1.1.2 .

Done.

>>  	RFC 2119 usage).  Please check all of these and upper case

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

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.

>> --David

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

---

From: Carlos Pignataro <[email-masked]>
Date: Fri, 12 Dec 2008 20:49:27 -0500

David,

On 12/12/2008 8:02 PM, [email-masked] said the following:
> Carlos,
> 
> (1) AVP for softwire profile of L2TPv2.
> 
> I can mostly agree with the following:
> 
>>    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.
> 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-masked] 
>> [mailto:[email-masked]] On Behalf Of Carlos Pignataro
>> Sent: Friday, December 12, 2008 9:43 AM
>> To: Black, David
>> Cc: [email-masked]; W. Mark Townsley; [email-masked]; Jari Arkko
>> Subject: Re: [Gen-art] [Softwires] Gen-ART reviewof 
>> draft-ietf-softwire-hs-framework-l2tpv2-10
>>
>> Alain, Mark,
>>
>> Gen-art mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/gen-art
>>
>>
>

---

From: [email-masked]
Date: Fri, 12 Dec 2008 20:02:22 -0500

Carlos,

(2) RFC 5405 and UDP.

that's probably enough.  Section 3.2 of RFC 5405 (on Message Size)

Thanks,
--David

---

From: [email-masked]
Date: Mon, 22 Dec 2008 19:49:20 -0500

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

---

From: Carlos Pignataro <[email-masked]>
Date: Mon, 22 Dec 2008 22:01:17 -0500

WG,

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

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

> This has also

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

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

-- 
--Carlos Pignataro, DSE, CISCO.
_______________________________________________
Softwires mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/softwires

---

From: Mark Townsley <[email-masked]>
Date: Tue, 23 Dec 2008 04:13:33 +0100

> receives an OCRQ message".
That was certainly my thinking here... If OCRQ functionality is not 
supported, send a CDN.
> (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