Re: [L2tpext] draft-mkonstan-keyed-ipv6-tunnel-00

Ok thx this covers it

From: "Maciek Konstantynowicz (mkonstan)" <mkonstan@cisco.com<mailto:mkonstan@cisco.com>>
Date: Thursday 17 October 2013 00:02
To: Wim Henderickx <wim.henderickx@alcatel-lucent.com<mailto:wim.henderickx@alcatel-lucent.com>>
Cc: "maciek@cisco.com<mailto:maciek@cisco.com>" <maciek@cisco.com<mailto:maciek@cisco.com>>, "l2tpext@ietf.org<mailto:l2tpext@ietf.org>" <l2tpext@ietf.org<mailto:l2tpext@ietf.org>>
Subject: Re: [L2tpext] draft-mkonstan-keyed-ipv6-tunnel-00

Wim,

Sorry, took a while to get back to you..

Many thanks for your comments. See inline.

On 16 Aug 2013, at 09:25, Henderickx, Wim (Wim) wrote:

Some review comments:

1) I am not sure the use of explaining port-level/single-stack/multi-stack is sensible or relevant, they should eb used as examples. It's enough to say that each logical interface (whatever it may be) is uniquely identified by an ipv6 address.

Agree. Proposed text replacing current description in section 2 :

The IPv6 L2TPv3 tunnel encapsulating device uniquely identifies each Ethernet L2 attachment connection by a port ID or a combination of port ID and VLAN ID(s) on the access side, and by an IPv6 address on the network side.
Any VLAN identifiers, S-VID, C-VID or tuple ( S-VID, C-VID ) are treated with local significance within the Ethernet L2 port and are not forwarded over the IPv6 L2TPv3 tunnel. IPv6 address is treated as the IPv6 L2TPv3 tunnel endpoint.

2) "The L2TPv3 encapsulating router identifies each L2TPv3 tunnel endpoint by a distinct /128 address" -> we should also describe the any cast behaviour and the fact the tunnel is identified by a unique src/dst address combination

Agree. Proposed additional text :

Certain deployment scenarios may require using a single IPv6 address to identify a tunnel endpoint for many IPv6 L2TPv3 tunnels. For such cases the tunnel encapsulating device identifies each tunnel by a unique combination of tunnel source and destination IPv6 addresses.

3) General:
There's no mention of fragmentation and reassembly requirements;

IMV recommendation should be avoided :)

Adding new section, with proposed text as follows :

X. Fragmentation and Reassembly

Using an encapsulation, Ethernet L2 in IPv6 in this case, will reduce the effective MTU of the datagram.

The recommended solution to deal with this problem is for the network operator to  increase the MTU size of all the links between the devices acting as IPv6 L2TPv3 tunnel endpoints to accommodate both the IPv6 L2TPv3 encapsulation header and the Ethernet L2datagram without fragmenting the IPv6 packet.

If it is impossible to increase the link MTU across the network, the IPv6 L2TPv3 encapsulating device MUST perform fragmentation and reassembly if the outgoing link MTU cannot accommodate the extra IPv6 L2TPv3 header for specific Ethernet L2 payload. Fragmentation MUST happen after the encapsulation of the IPv6 L2TPv3 packet.  Reassembly MUST happen before the decapsulation of the IPv6 L2TPv3 packet.

The proposed approach is in line with the DS-Lite specification [RFC6333].

OAM should be described better with reference to the OAM draft in L2VPN

Yes we need to add a section on the OAM. Proposed approach is to rely on Ethernet OAM for connectivity verification to keep things simple.
Wim, would you be available to work with us on this section ?

Thanks,
Maciek.

_______________________________________________
L2tpext mailing list
L2tpext@ietf.org<mailto:L2tpext@ietf.org>
https://www.ietf.org/mailman/listinfo/l2tpext