internet-drafts | 18 Feb 20:23 2015
Picon

I-D Action: draft-ietf-l2tpext-keyed-ipv6-tunnel-02.txt


A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Layer Two Tunneling Protocol Extensions Working Group of the IETF.

        Title           : Keyed IPv6 Tunnel
        Authors         : Maciek Konstantynowicz
                          Giles Heron
                          Rainer Schatzmayr
                          Wim Henderickx
	Filename        : draft-ietf-l2tpext-keyed-ipv6-tunnel-02.txt
	Pages           : 10
	Date            : 2015-02-18

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

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-l2tpext-keyed-ipv6-tunnel/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-l2tpext-keyed-ipv6-tunnel-02

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-l2tpext-keyed-ipv6-tunnel-02

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.
(Continue reading)

Qi Sun | 19 Jan 14:50 2015
Picon

Comments on l2tpv3-yang-model: Covering keyed-v6-tunnel?

Dear authors, 

I have read draft-shen-l2tpext-l2tpv3-yang-model-00, which provides the configuration and
management of l2tpv3 tunnels. A few comments below.

The most significant one is that, this YANG model is about managing RFC3931 in general, which does not cover
the requirements from draft-ietf-l2tpext-keyed-ipv6-tunnel. Since the essence of
draft-ietf-l2tpext-keyed-ipv6-tunnel (as I see) is to simplify L2TPv3 tunnel by taking some parts from
RFC3931, the YANG model for L2TPv3 should also be able to cover the YANG model for keyed-v6-tunnel. 

I’ve worked out a YANG diagram tree for keyed-v6-tunnel (and a YANG model). The YANG model makes use of
some parts from the l2tpv3-yang-model (especially the “static” case), and also adds some
parameters for its own. Since the length of Cookie should always be 64 bits, the following YANG model
doesn’t include it as a parameter to configure.

<YANG for keyed-v6-tunnel>
module: keyed-v6-l2tpv3
  +--rw keyed-v6-l2tpv3
     +--rw enabled?                          boolean
     +--rw l2tpv3TunnelInstances   
        +--rw l2tpv3TunnelInstance* [tunnelName]
           +--rw tunnelName                  string 
           +--rw srcIfName                     if:interface-ref // *unique*
           +--rw srcIPv6                         inet:ipv6-address  /* unique *
           +--rw dstIPv6                         inet:ipv6-address   *        */
           +--rw localSessionId?             uint32 
           +--rw remoteSessionId?         uint32 
           +--rw localCookies
           |  +--rw localCookie* [cookieName]
           |     +--rw cookieName            enumeration // "new"/"old"
(Continue reading)

Qi Sun | 14 Jan 17:12 2015
Picon

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
(Continue reading)

RFC Errata System | 12 Jan 12:48 2015

[Editorial Errata Reported] RFC4719 (4231)

The following errata report has been submitted for RFC4719,
"Transport of Ethernet Frames over Layer 2 Tunneling Protocol Version 3 (L2TPv3)".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=4719&eid=4231

--------------------------------------
Type: Editorial
Reported by: Karsten Thomann <karsten_thomann <at> linfre.de>

Section: 3.1

Original Text
-------------
The entire Ethernet frame, without the preamble or frame check
sequence (FCS), is encapsulated in L2TPv3 and is sent as a single
packet by the ingress LCCE.

Corrected Text
--------------
The entire Ethernet frame, without the preamble and frame check
sequence (FCS), is encapsulated in L2TPv3 and is sent as a single
packet by the ingress LCCE.

Notes
-----
The LCCE should remove the preamble AND FCS

Instructions:
(Continue reading)

RFC Errata System | 12 Jan 14:23 2015

[Errata Rejected] RFC4719 (4231)

The following errata report has been rejected for RFC4719,
"Transport of Ethernet Frames over Layer 2 Tunneling Protocol Version 3 (L2TPv3)".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=4719&eid=4231

--------------------------------------
Status: Rejected
Type: Editorial

Reported by: Karsten Thomann <karsten_thomann <at> linfre.de>
Date Reported: 2015-01-12
Rejected by: Brian Haberman (IESG)

Section: 3.1

Original Text
-------------
The entire Ethernet frame, without the preamble or frame check
sequence (FCS), is encapsulated in L2TPv3 and is sent as a single
packet by the ingress LCCE.

Corrected Text
--------------
The entire Ethernet frame, without the preamble and frame check
sequence (FCS), is encapsulated in L2TPv3 and is sent as a single
packet by the ingress LCCE.

Notes
(Continue reading)

Liubing (Leo | 27 Oct 03:43 2014

L2TPv3 YANG Model draft-//FW: New Version Notification for draft-shen-l2tpext-l2tpv3-yang-model-00.txt

Hi Dear all in l2tpext,

We've uploaded a new 00 draft of the L2TPv3 YANG model.
Please have a review. And comments would be appreciated very much.

Best regards,
Bing (on behalf of the co-authors)

-----Original Message-----
From: internet-drafts <at> ietf.org [mailto:internet-drafts <at> ietf.org] 
Sent: Monday, October 27, 2014 10:39 AM
To: Shenhaoxing; David Bannister; Liubing (Leo); Mikael Abrahamsson; David Bannister; Mikael
Abrahamsson; Liubing (Leo); Shenhaoxing
Subject: New Version Notification for draft-shen-l2tpext-l2tpv3-yang-model-00.txt

A new version of I-D, draft-shen-l2tpext-l2tpv3-yang-model-00.txt
has been successfully submitted by Bing Liu and posted to the IETF repository.

Name:		draft-shen-l2tpext-l2tpv3-yang-model
Revision:	00
Title:		A YANG Data Model for L2TPv3 Tunnel
Document date:	2014-10-27
Group:		Individual Submission
Pages:		12
URL:            http://www.ietf.org/internet-drafts/draft-shen-l2tpext-l2tpv3-yang-model-00.txt
Status:         https://datatracker.ietf.org/doc/draft-shen-l2tpext-l2tpv3-yang-model/
Htmlized:       http://tools.ietf.org/html/draft-shen-l2tpext-l2tpv3-yang-model-00

Abstract:
   This document defines a YANG data model for managing L2TPv3 tunnels.
(Continue reading)

Xialiang (Frank | 10 Apr 05:37 2014

Re: New Version Notification for draft-fan-l2tp-vp-01.txt

Hi folks,
We have updated the L2TP-VP version -01 draft. 
In the new version draft, we add the motivation of this draft and modification to the format of L2TP-VP header.
Welcome your comments and suggestions!

B.R.
Frank

> -----Original Message-----
> From: internet-drafts <at> ietf.org [mailto:internet-drafts <at> ietf.org]
> Sent: Thursday, April 10, 2014 11:22 AM
> To: Xialiang (Frank); Zhen Cao; Fanduoliang; Zehn Cao; Namgon Kim; Namgon
> Kim; Fanduoliang; Xialiang (Frank)
> Subject: New Version Notification for draft-fan-l2tp-vp-01.txt
> 
> 
> A new version of I-D, draft-fan-l2tp-vp-01.txt has been successfully submitted
> by Liang Xia and posted to the IETF repository.
> 
> Name:		draft-fan-l2tp-vp
> Revision:	01
> Title:		L2TP-VP: Layer Two Tunneling Protocol - Virtualization Profile
> Document date:	2014-04-10
> Group:		Individual Submission
> Pages:		9
> URL:
> http://www.ietf.org/internet-drafts/draft-fan-l2tp-vp-01.txt
> Status:         https://datatracker.ietf.org/doc/draft-fan-l2tp-vp/
> Htmlized:       http://tools.ietf.org/html/draft-fan-l2tp-vp-01
> Diff:           http://www.ietf.org/rfcdiff?url2=draft-fan-l2tp-vp-01
(Continue reading)

ian.farrer | 14 Mar 09:28 2014
Picon

Re: WG Adoption of Keyed IPv6 Tunnel [draft-mkonstan-l2tpext-keyed-ipv6-tunnel]

Support, as an operator planning to deploy.

Ian

Begin forwarded message:

> From: "Carlos Pignataro (cpignata)" <
cpignata <at> cisco.com>
> Subject: [L2tpext] WG Adoption of Keyed IPv6 Tunnel [draft-mkonstan-l2tpext-keyed-ipv6-tunnel]
> Date: 3 March 2014 20:33:28 GMT
> To: "
l2tpext <at> ietf.org" <l2tpext <at> ietf.org>
> Cc: "
draft-mkonstan-l2tpext-keyed-ipv6-tunnel <at> tools.ietf.org" <draft-mkonstan-l2tpext-keyed-ipv6-tunnel <at> tools.ietf.org>
>
> WG,
>
> The authors of 'Keyed IPv6 Tunnel' have requested that L2TPEXT adopts this draft as a WG document.
The draft received discussion and comments on the list, and was updated twice based on list feedback.
>
> http://tools.ietf.org/html/draft-mkonstan-l2tpext-keyed-ipv6-tunnel-00
>
> This message starts a three-week Call for WG Adoption for draft-mkonstan-l2tpext-keyed-ipv6-tunnel-00. Given that IETF89 is going on right now, we are adding an extra week to this adoption call. The call for adoption will end on Monday, March 24th.
>
> Please share your thoughts on this adoption call on the list -- we will not be taking silence as support. Bonus points supporting a yes/no email with a technical explanation as to why.
>
> Thanks!
>
> Carlos.
> _______________________________________________
> L2tpext mailing list
> L2tpext <at> ietf.org
> https://www.ietf.org/mailman/listinfo/l2tpext

_______________________________________________
L2tpext mailing list
L2tpext <at> ietf.org
https://www.ietf.org/mailman/listinfo/l2tpext
Carlos Pignataro (cpignata | 3 Mar 21:33 2014
Picon

WG Adoption of Keyed IPv6 Tunnel [draft-mkonstan-l2tpext-keyed-ipv6-tunnel]

WG,

The authors of 'Keyed IPv6 Tunnel' have requested that L2TPEXT adopts this draft as a WG document. The draft
received discussion and comments on the list, and was updated twice based on list feedback.

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

This message starts a three-week Call for WG Adoption for
draft-mkonstan-l2tpext-keyed-ipv6-tunnel-00. Given that IETF89 is going on right now, we are adding
an extra week to this adoption call. The call for adoption will end on Monday, March 24th.

Please share your thoughts on this adoption call on the list -- we will not be taking silence as support.
Bonus points supporting a yes/no email with a technical explanation as to why.

Thanks!

Carlos.
_______________________________________________
L2tpext mailing list
L2tpext <at> ietf.org
https://www.ietf.org/mailman/listinfo/l2tpext
Xialiang (Frank | 17 Dec 04:19 2013

FW: comments about draft-mkonstan-l2tpext-keyed-ipv6-tunnel

Hi authors,

I have sent this email of comments for a period of time, but don’t get response.

So I try to send it again and hope for getting your kindly feedback.

Thanks!

 

B.R.

Frank

 

From: L2tpext [mailto:l2tpext-bounces <at> ietf.org] On Behalf Of Xialiang (Frank)
Sent: Friday, December 06, 2013 3:35 PM
To: maciek <at> cisco.com; Giles Heron (giheron); rainer.schatzmayr <at> telekom.de; wim.henderickx <at> alcatel-lucent.com
Cc: l2tpext <at> ietf.org
Subject: [L2tpext] comments about draft-mkonstan-l2tpext-keyed-ipv6-tunnel

 

Hi authors,

I have reviewed this draft, and consider it a useful draft for giving a concrete use case of using mature L2TPv3 protocol as a data plane overlay technology. I also have several comments below:

1.       You use a source+des IP pair to identify a L2TP tunnel without tenant id carried on the wire. It increases the complexity when identifying tenant network’s traffic using the mapping between tenant network and a large number of source+des IP pairs, especially when tenant network are highly distributed in the real network. While, using tenant id carried on the wire can reduce the complexity largely;

2.       Would you consider more general use cases, e.g., supporting IPv4 underlay network, and different types of services overlaid on it (e.g., Ethernet, PPP, IPv4, IPv6 ,etc)?

3.       I cannot find contents in the draft describing how to implement the multipoint VPN in detail. If you don’t use control plane, then data plane flooding or manage plane provision should be supported. Do you follow this way?

 

B.R.

Frank

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

_______________________________________________
L2tpext mailing list
L2tpext <at> ietf.org
https://www.ietf.org/mailman/listinfo/l2tpext
Xialiang (Frank | 6 Dec 08:34 2013

comments about draft-mkonstan-l2tpext-keyed-ipv6-tunnel

Hi authors,

I have reviewed this draft, and consider it a useful draft for giving a concrete use case of using mature L2TPv3 protocol as a data plane overlay technology. I also have several comments below:

1.       You use a source+des IP pair to identify a L2TP tunnel without tenant id carried on the wire. It increases the complexity when identifying tenant network’s traffic using the mapping between tenant network and a large number of source+des IP pairs, especially when tenant network are highly distributed in the real network. While, using tenant id carried on the wire can reduce the complexity largely;

2.       Would you consider more general use cases, e.g., supporting IPv4 underlay network, and different types of services overlaid on it (e.g., Ethernet, PPP, IPv4, IPv6 ,etc)?

3.       I cannot find contents in the draft describing how to implement the multipoint VPN in detail. If you don’t use control plane, then data plane flooding or manage plane provision should be supported. Do you follow this way?

 

B.R.

Frank

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

Gmane