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

[[e-mail]]

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: [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
> 
> 
_______________________________________________
Softwires mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/softwires