Carlos Pignataro (cpignata | 21 Apr 22:27 2015
Picon

Fwd: [Rtg-yang-coord] YANG Editing Session at IETF 93

L2tpext,

FYI.

Thanks,

— Carlos.

Begin forwarded message:

From: "BRUNGARD, DEBORAH A" <db3546 <at> att.com>
Subject: FW: [Rtg-yang-coord] Fwd: YANG Editing Session at IETF 93
Date: April 21, 2015 at 3:17:54 PM EDT

FYI – you may want to redistribute to your working groups – before folks make travel plans.

 
From: Rtg-yang-coord [mailto:rtg-yang-coord-bounces <at> ietf.org] On Behalf Of Benoit Claise
Sent: Tuesday, April 21, 2015 12:02 PM
To: Rtg-yang-coord <at> ietf.org
Subject: [Rtg-yang-coord] Fwd: YANG Editing Session at IETF 93

 

FYI.

Regards, Benoit



-------- Forwarded Message -------- 

Subject: 

YANG Editing Session at IETF 93

Date: 

Tue, 21 Apr 2015 18:01:20 +0200

From: 

Benoit Claise <bclaise <at> cisco.com>

To: 

NETMOD Working Group <netmod <at> ietf.org>

 

FYI.

http://www.ietf.org/meeting/93/tutorials/yang-session.html

 

Regards, Benoit

 

 


_______________________________________________
L2tpext mailing list
L2tpext <at> ietf.org
https://www.ietf.org/mailman/listinfo/l2tpext
Carlos Pignataro (cpignata | 14 Apr 22:51 2015
Picon

A YANG Data Model for L2TPv3 Tunnel

WG,

The following individual submission is targeting l2tpext, by defining a YAN Data Model for L2TPv3.


Please review and comment on list.

Thanks!

— Carlos.
_______________________________________________
L2tpext mailing list
L2tpext <at> ietf.org
https://www.ietf.org/mailman/listinfo/l2tpext
Carlos Pignataro (cpignata | 14 Apr 22:48 2015
Picon

Keyed IPv6 Tunnels

L2TPExt,

There are currently two active documents covering $subject. I wanted to checkpoint their progress and ask
for next actions.

1. draft-ietf-l2tpext-keyed-ipv6-tunnel-04

A new revision of this WG draft was published recently, incorporating all comments received (both in
L2TPExt as well as in the review request to 6Man). I would like to ask the WG to continue to review this
document, which seems to be maturing nicely.

2. draft-sun-l2tpext-keyed-v6-tunnel-yang-00

This is a -00 individual submission, dependent on #1, posted also recently. I’ve not seen much (any)
discussion on list yet. WG, please review!

Thanks,

— Carlos.
_______________________________________________
L2tpext mailing list
L2tpext <at> ietf.org
https://www.ietf.org/mailman/listinfo/l2tpext
Qi Sun | 10 Mar 14:07 2015
Picon

Fwd: New Version Notification for draft-sun-l2tpext-keyed-v6-tunnel-yang-00.txt

Dear WG,

We’ve submitted a YANG data model for the Keyed IPv6 tunnel. Comments are welcome. Thanks!

Cheers,
Qi

Begin forwarded message:
> -----Original Message-----
> From: internet-drafts <at> ietf.org [mailto:internet-drafts <at> ietf.org] 
> Sent: Montag, 9. März 2015 17:36
> To: Giles Heron; Sun, Qui; Farrer, Ian; Sun, Qui; Bing Liu; Giles Heron; Farrer, Ian; Bing Liu
> Subject: New Version Notification for draft-sun-l2tpext-keyed-v6-tunnel-yang-00.txt
> 
> 
> A new version of I-D, draft-sun-l2tpext-keyed-v6-tunnel-yang-00.txt
> has been successfully submitted by Qi Sun and posted to the IETF repository.
> 
> Name:		draft-sun-l2tpext-keyed-v6-tunnel-yang
> Revision:	00
> Title:		A YANG Data Model for Keyed IPv6 Tunnels
> Document date:	2015-03-09
> Group:		Individual Submission
> Pages:		13
> URL:            http://www.ietf.org/internet-drafts/draft-sun-l2tpext-keyed-v6-tunnel-yang-00.txt
> Status:         https://datatracker.ietf.org/doc/draft-sun-l2tpext-keyed-v6-tunnel-yang/
> Htmlized:       http://tools.ietf.org/html/draft-sun-l2tpext-keyed-v6-tunnel-yang-00
> 
> 
> Abstract:
>   This document defines a YANG data model for the configuration and
>   management of Keyed IPv6 tunnels.  The data model includes
>   configuration data and state data.  Due to the stateless nature of
>   keyed IPv6 tunnels, a model for NETCONF notifications is not
>   necessary.
> 
> 
> 
> 
> 
> 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.
> 
> The IETF Secretariat
> 
internet-drafts | 10 Mar 00:01 2015
Picon

I-D Action: draft-ietf-l2tpext-keyed-ipv6-tunnel-04.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-04.txt
	Pages           : 11
	Date            : 2015-03-09

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-04

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

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.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/
Brian Haberman | 9 Mar 18:14 2015
Picon

Announcement of the move of L2TPEXT, LISP, and TRILL

All,

As a part of the IESG re-organization, the IESG discussed moving some
Working Groups from the Internet Area to the Routing Area. Now that we
know we will have three RTG ADs seated from the Dallas meeting onwards,
we will go ahead with our plan to move L2TPEXT, LISP and TRILL from INT
to RTG.

This move will be effective immediately after IETF-92.

Regards,
Brian

_______________________________________________
L2tpext mailing list
L2tpext <at> ietf.org
https://www.ietf.org/mailman/listinfo/l2tpext
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.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/
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"
           |     +--rw localHighCookie       hexBinary
           |     +--rw localLowCookie        hexBinary
           +--rw remoteCookie
           |  +--rw remoteHighCookie         hexBinary
           |  +--rw remoteLowCookie          hexBinary
           +--rw mtu                                 unit16
           +--rw (oam_method)
           |  +--:(ieee8021ag!)
           |  +--:(ituy1731!)
           +--rw vccv_enabled?               boolean
//There is a separate “operational state” subtree, which isn’t shown above. 
</YANG for keyed-v6-tunnel>

I’m thinking if it’s a good idea to merge the two models (with some explanation text or a separate
section in the l2tpv3-yang-model draft), since there are some similarities. Otherwise, a separate I-D
could be written to document the keyed-v6-tunnel YANG. 

Could you, authors and the WG, share your ideas on this? Thanks a lot!

Here are a few more comments on the content of the draft, detailed as follows.
1) According to RFC3931, the L2TPv3 tunnel should support the mode of “one tunnel, multiple
sessions”. However, the current YANG model doesn’t support it. I would suggest the parameter of
Sessionid be a list, with corresponding modifications. 
2) The expression of choice-case structure in the diagram tree is not the common style used by other YANG
models. Please refer to RFC7277.
3) Typically, there is a separate operational state subtree for those “ro” parameters. Some
restructures might be helpful to make the model clearer, if you like. Also refer to RFC 7277.

Hope that helps.

Cheers,
Qi
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
  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
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:
-------------
This erratum is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party (IESG)
can log in to change the status and edit the report, if necessary. 

--------------------------------------
RFC4719 (draft-ietf-l2tpext-pwe3-ethernet-09)
--------------------------------------
Title               : Transport of Ethernet Frames over Layer 2 Tunneling Protocol Version 3 (L2TPv3)
Publication Date    : November 2006
Author(s)           : R. Aggarwal, Ed., M. Townsley, Ed., M. Dos Santos, Ed.
Category            : PROPOSED STANDARD
Source              : Layer Two Tunneling Protocol Extensions
Area                : Internet
Stream              : IETF
Verifying Party     : IESG
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
-----
The LCCE should remove the preamble AND FCS
 --VERIFIER NOTES-- 
 The without/or construct is a valid way in English to indicate that both fields are omitted during
encapsulation.  

--------------------------------------
RFC4719 (draft-ietf-l2tpext-pwe3-ethernet-09)
--------------------------------------
Title               : Transport of Ethernet Frames over Layer 2 Tunneling Protocol Version 3 (L2TPv3)
Publication Date    : November 2006
Author(s)           : R. Aggarwal, Ed., M. Townsley, Ed., M. Dos Santos, Ed.
Category            : PROPOSED STANDARD
Source              : Layer Two Tunneling Protocol Extensions
Area                : Internet
Stream              : IETF
Verifying Party     : IESG

Gmane