Re: [Softwires] softwire-encaps-safi

[Carlos Pignataro <cpignata at cisco.com>]

Hi Pradosh,

Thank you for the quick responses, the updated rev -01 addresses all my 
comments.

Thanks,

--Carlos.

On 5/28/2008 11:55 AM, Pradosh Mohapatra (pmohapat) said the following:
> Hi Carlos,
> 
> Thanks for all the comments. Responses inline. The new revision (-01)
> has the changes incorporated. The draft is at
> http://www.ietf.org/internet-drafts/draft-ietf-softwire-encaps-safi-01.t
> xt
> 
> | 
> |      Tunnel Type (2 octets): It identifies the type of the tunneling
> |      technology being signaled. This document defines the 
> | following types:
> | 
> |        - L2TPv3: Tunnel Type = 1
> | 
> | L2TPv3 can be encapsulated in different ways over IP (e.g., directly
> | over IP proto 115, and over UDP). This document refers implicitly
> | (without mention) to L2TPv3 over IP (the only L2TPv3 mandatory
> | encapsulation from RFC3931), but does not explicitly clarify it. Could
> | this be disambiguated, e.g., by either: i. Renaming the 
> | Tunnel Type 1 to
> | "L2TPv3 over IP", or ii. Providing further L2TPv3 encap 
> | details (IP vs.
> | UDP, etc) in the Encapsulation sub-TLV for the L2TPv3 TLV Type?
> 
> Renamed the tunnel type to be 'L2TPv3 over IP'.
> 
> 
> |       * Session ID: a 4-octet value locally assigned by the 
> | advertising
> |         router that serves as a lookup key in the incoming packet's
> |         context.
> | 
> | Could "non-null" be added as a constrain for the Session ID? The 
> | all-zeros identifies and L2TPv3 Control Packet (instead of 
> | data packet) 
> | when running directly over IP.
> 
> Done.
> 
> 
> | ...
> |        * Cookie: an optional, variable length (encoded in 
> | octets - 0 to 8
> |          octets) value used by L2TPv3 to check the association of a
> |          received data message with the session identified by 
> | the Session
> |          ID. The Cookie value is tightly coupled with the Session ID.
> | 
> | 
> | This text defining/describing the Cookie field seems to allow for any
> | length of cookie from 0 to 8 octets; however, from RFC3931:
> | 
> |        The Assigned Cookie is a 4-octet or 8-octet random value.
> 
> Clarified that the cookie value is as per RFC 3931.
> 
> 
> | 
> | 4.2. Protocol Type sub-TLV
> | ...
> |     Note that the protocol type sub-TLV is optional, e.g. if the
> |     tunneling technology is GRE, this sub-TLV is not required.
> | 
> | Is this sub-TLV also optional for L2TPv3 tunneling, which 
> | encap (unlike 
> | GRE) does not have a PID, or is it mandatory for L2TPv3 
> | Tunnel Type? If 
> | still optional, how is the encapsulated Protocol Type 
> | (tunneled payload 
> | PID) signaled, checked, selected/validated in the dataplane?
> 
> Clarified the description to mean that protocol type 
> sub-TLV is mandatory for L2TPv3 and optional for GRE.
> 
> 
> | 6. Security Considerations
> | 
> | Shouldn't this section be augmented with the security 
> | considerations of 
> | the tunneling protocols used? e.g., for l2tpv3, source (and dest) 
> | validation (for tunneled traffic) vs. (or plus) suggested use of  the 
> | cookie, etc?
> 
> Have added the following text to this section:
> 
> "
>    Security considerations applicable to Softwires can be found in the
>    mesh framework [Softwires-Mesh-Frame-work]. In general, security
>    issues of the tunnel protocols signalled through encapsulation SAFI
>    are inherited.
> "
> 
> | References:
> | 
> | I notice this document does not reference RFC2784 + RFC2890 
> | and RFC3931. 
> | It seems it should, for example 
> | draft-ietf-softwire-encaps-ipsec (that 
> | does not concern with defining the Tunnel Types for L2TPv3 or 
> | GRE still 
> | add 2784/3931 references.
> 
> Added these references.
> 
> Rgds,
> - Pradosh
> 

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