Comments on draft-ietf-l2tpext-keyed-ipv6-tunnel-01

Dear WG & authors,

I have reviewed this draft and I think it's very useful, as it greatly simplifies the l2tpv3 tunnels by taking parts from l2tpv3. 

Also I have some comments about it. The tricky one would be the intended status of this document. Currently it’s an Informational document, which means it doesn’t change RFC3931. However, there are a number of normative language, which might be confusing. 

I’ve made a list of features of the keyed IPv6 tunnel, with some comparison to RFC3931. Please correct me if anything is wrong. 
1) Not use L2TPv3 Control Plane defined in RFC3931.
2) A mapping table of v6 address and the port ID.
3) One session per tunnel.
4) The Session ID field is there, but it may be processed. (This is a “MUST" in RFC3931.)
5) Cookie length MUST be 64 (which can be 32-/64-bit in RFC3931).
6) The cookie can be randomly selected, or all ones. (It MUST be configured or signalled with a random value in RFC3931.)
7) Local and remote endpoints SHOULD send different cookie values.  The value of the cookie MUST be able to be changed at any time. The receiver must be willing to accept both "old" and "new" cookie values. Cookie values SHOULD be changed periodically. 

I think item 4) ~ 7) potentially change the behaviour of LCCE when processing a l2tpv3 (i.e. keyed-v6-tunnel) packet. 

Could the wg shed some light on why this document is Informational instead of Standard Track? Thanks!

The other comments are mainly about the technical/editorial content of the draft, detailed as follows.
<comments>
1. Sec 2, para 3
  IPv6 address is treated as the IPv6 L2TPv3 tunnel endpoint.

[Qi] How about “… IPv6 address is treated as the identifier of the IPv6 L2TPv3 tunnel endpoint”?

2. Sec 2, para 4
   Certain deployment scenarios may require using a single IPv6 address
  to identify a tunnel endpoint for many IPv6 L2TPv3 tunnels.
[Qi] s/many/multiple/

3. In Sec 3, the last sentence of this section misses the period at the end.

4. Sec 4
  The s-tag (or in the multi-stack access case the s-tag and c-tag)
  SHOULD be removed before the packet is encapsulated.
[Qi] Maybe a reference related to “s-tag” and “c-tag” would be helpful here.

5. Sec 4, Session ID
   o  Session ID.  In the "Static 1:1 mapping" case described in
      Section 2, the IPv6 address resolves to an L2TPv3 session
      immediately, thus the Session ID may be ignored upon receipt.  For
      compatibility with other tunnel termination platforms supporting
      only 2-stage resolution (IPv6 Address + Session ID), this
      specification recommends supporting explicit configuration of
      Session ID to any value other than zero.  For cases where both
      tunnel endpoints support one-stage resolution (IPv6 Address only),
      this specification recommends setting the Session ID to all ones
      for easy identification in case of troubleshooting.  The Session
      ID of zero MUST NOT be used, as it is reserved for use by L2TP
      control messages RFC3931 [RFC3931].
[Qi] 
1) Could the authors give the definitions of “2-stage resolution” and “one-stage” resolution?
2) The session ID can be explicitly configured to any value other than zero, or all ones, right? Is there a 3rd type of session ID configuration?
3) The text is a little confused to me. I think that ignoring the Session ID is the behaviour of the receiving device, and setting Session ID is the behaviour of the sending device, right? I would expect it to be explicitly described here.
4) In section 3, it says:
  "The cookie MUST be 64-bits
  long in order to provide sufficient protection against spoofing and
  brute force blind insertion attacks."
However, the text in this section recommends setting the Session ID to all ones. Can the all-ones cookie provide sufficient protection?

6. Sec 6, paragraph 3
  …, this document recommends that Ethernet OAM as defined in IEEE
  802.1ag [IEEE802.1ag] and/or ITU Y.1731 [Y.1731] is enabled for keyed
  IP tunnels.
[Qi]
1) Is the Ethernet OAM method configured per tunnel, or per device?
2) s/this document recommends/ it is RECOMMENDED in this document/ ??

7. Sec 8, para 3
[Qi] This paragraph is taken from the L2TPv3 RFC3931, with the reference to RFC1750 changed to RFC4086 (Note: RFC4086 obsoletes RFC1750).
Should there be a reference to the related section of RFC3931 besides taking text from it?

8. Sec 8, the last para
  The L2TPv3 64-bit cookie must not be regarded as a substitute for
  security such as that provided by IPsec when operating over an open
  or untrusted network where packets may be sniffed, decoded, and
  correlated for use in a coordinated attack.
[Qi] s/must not/MUST NOT/ ??
</comments>

Hope that helps.

Best Regards,
Qi Sun