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

[Carlos Pignataro <[e-mail]>]

David,

On 12/12/2008 8:02 PM, [e-mail] 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: [e-mail] 
>> [mailto:[e-mail]] On Behalf Of Carlos Pignataro
>> Sent: Friday, December 12, 2008 9:43 AM
>> To: Black, David
>> Cc: [e-mail]; W. Mark Townsley; [e-mail]; 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, [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-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
>>>> [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
>>
>>
>>
>>
>>
>>
>>
>> _______________________________________________
>> Gen-art mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/gen-art
>>
>>
> 

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