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

WG,

On 12/22/2008 7:49 PM, Black_David@emc.com said the following:
> 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 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.

> For example, what happens if a softwire implementation of
> 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
> 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.

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

> 
> (2) RFC 5405 and UDP.  In addition to referencing RFC 5405,
> 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.

> 
> Thanks,
> --David
> ----------------------------------------------------
> David L. Black, Distinguished Engineer
> EMC Corporation, 176 South St., Hopkinton, MA  01748
> +1 (508) 293-7953             FAX: +1 (508) 293-7786
> black_david@emc.com        Mobile: +1 (978) 394-7754
> ----------------------------------------------------
> 

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