Re: [Softwires] softwire-encaps-safi

["Pradosh Mohapatra (pmohapat)" <[e-mail]>]

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