[L2tpext] Review of Keyed IPv6 Tunnel [draft-mkonstan-keyed-ipv6-tunnel-00]

["Carlos Pignataro (cpignata)" <[e-mail]>]

Hi, Rainer, Giles, Maciek, Mark,

After the presentation of this draft in Berlin at the PWE3 meeting (with thanks to the PWE3 chairs!) available at http://tools.ietf.org/agenda/87/slides/slides-87-pwe3-2.pdf, I wanted to provide some review comments with the chair hat off. 

I hope these are useful and clear, they are prefaced with "CMP"


http://tools.ietf.org/html/draft-mkonstan-keyed-ipv6-tunnel-00

Network Working Group                                      R. Schatzmayr
Internet-Draft                                       Deutsche Telekom AG
Intended status: Informational                             G. Heron, Ed.

CMP: I do not think that the intended status of this document should be Informational, as you are proposing protocol changes.


Abstract

   This document describes a simple L2 Ethernet over IPv6 tunnel
   encapsulation with mandatory 64-bit authentication key for connecting
   L2 Ethernet attachment circuits identified by IPv6 addresses.  The
   encapsulation is based on L2TPv3 over IP.

and 

3.  64-bit Authentication Key

   All packets MUST carry a 64-bit authentication key in the L2TPv3

CMP: a cookie does not provide an authentication key. It is a simple context lookup check.

1.  Introduction

CMP: It might be useful to mention in the introduction that there is precedence with proposals to do away with the session id lookup when considered redundant, as for example with draft-ietf-l2tpext-l2tphc.


2.  Static 1:1 Mapping Without a Control Plane

   Use of the L2TPv3 Control Plane is optional.  When the control plane
   is not used, local configuration creates a one-to-one mapping between
   the access-side L2 attachment circuit and the IP address used in the
   network-side IPv6 encapsulation.

CMP: I am not sure I understand how it would work *with* the L2TPv3 Control Plane. Instead of saying that it is optional, I would say that it is out of scope or similar, and this behavior is specified for static sessions only. Optional means it can be used, and they you would have to say "how" (which new AVPs, etc).

   Further, circuit monitoring is
   performed using Ethernet OAM mechanisms (802.1ag and/or Y.1731).

CMP: Why Ethernet OAM and not L2TPv3/PW OAM? e.g., [RFC 5085].

   In the event that an IPv6 address used in L2TPv3 does not directly
   correspond to one and only one attachment circuit on both sides of
   the L2TPv3 tunnel, the Session ID may be used for additional
   granularity.  This allows for other addressing schemes that may
   require additional bits beyond those which can fit in the IPv6 header
   address field.

CMP: Assuming there are some gains in processing the session context from the IPv6 address instead of the session id, which could be described, is that lost with this last paragraph? Why have both?


4.  Encapsulation

   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.

CMP: Could you add that it is non-zero?

8.2.  Informative References



   [RFC1700]  Reynolds, J. and J. Postel, "Assigned Numbers", RFC 1700,
              October 1994.

CMP: THis reference is not cited in the doc, please remove.


Thanks,

-- Carlos.