internet-drafts | 15 Apr 21:02 2016
Picon

I-D Action: draft-ietf-l2tpext-sbfd-discriminator-05.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 of the IETF.

        Title           : Advertising Seamless Bidirectional Forwarding Detection (S-BFD) Discriminators in Layer Two
Tunneling Protocol, Version 3 (L2TPv3)
        Authors         : Vengada Prasad Govindan
                          Carlos Pignataro
	Filename        : draft-ietf-l2tpext-sbfd-discriminator-05.txt
	Pages           : 6
	Date            : 2016-04-15

Abstract:
   This document defines a new Attribute Value Pair (AVP) that allows
   L2TP Control Connection Endpoints (LCCEs) to advertise one or more
   Seamless Bidirectional Forwarding Detection (S-BFD) Discriminator
   values using the Layer Two Tunneling Protocol, Version 3 (L2TPv3).

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-l2tpext-sbfd-discriminator/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-l2tpext-sbfd-discriminator-05

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-l2tpext-sbfd-discriminator-05

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)

internet-drafts | 15 Apr 19:38 2016
Picon

I-D Action: draft-ietf-l2tpext-sbfd-discriminator-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 of the IETF.

        Title           : Advertising Seamless Bidirectional Forwarding Detection (S-BFD) Discriminators in Layer 2
Tunneling Protocol, Version 3 (L2TPv3)
        Authors         : Vengada Prasad Govindan
                          Carlos Pignataro
	Filename        : draft-ietf-l2tpext-sbfd-discriminator-04.txt
	Pages           : 6
	Date            : 2016-04-15

Abstract:
   This document defines a new Attribute Value Pair (AVP) that allows
   L2TP Control Connection Endpoints (LCCEs) to advertise one or more
   Seamless Bidirectional Forwarding Detection (S-BFD) Discriminator
   values using the Layer 2 Tunneling Protocol, Version 3 (L2TPv3).

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-l2tpext-sbfd-discriminator/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-l2tpext-sbfd-discriminator-04

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-l2tpext-sbfd-discriminator-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.

(Continue reading)

The IESG | 22 Mar 22:45 2016
Picon

Last Call: <draft-ietf-l2tpext-sbfd-discriminator-03.txt> (Advertising S-BFD Discriminators in L2TPv3) to Proposed Standard


The IESG has received a request from the Layer Two Tunneling Protocol
Extensions WG (l2tpext) to consider the following document:
- 'Advertising S-BFD Discriminators in L2TPv3'
  <draft-ietf-l2tpext-sbfd-discriminator-03.txt> as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf <at> ietf.org mailing lists by 2016-04-05. Exceptionally, comments may be
sent to iesg <at> ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract

   This document defines a new AVP that allows L2TP Control Connection
   Endpoints (LCCEs) to advertise one or more Seamless BFD (S-BFD)
   Discriminator values using L2TPv3.

The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-l2tpext-sbfd-discriminator/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-l2tpext-sbfd-discriminator/ballot/

No IPR declarations have been submitted directly on this I-D.
internet-drafts | 21 Mar 20:34 2016
Picon

I-D Action: draft-ietf-l2tpext-keyed-v6-tunnel-yang-01.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 of the IETF.

        Title           : A YANG Data Model for Keyed IPv6 Tunnels
        Authors         : Qi Sun
                          Ian Farrer
                          Bing Liu
                          Giles Heron
	Filename        : draft-ietf-l2tpext-keyed-v6-tunnel-yang-01.txt
	Pages           : 14
	Date            : 2016-03-21

Abstract:
   This document defines a YANG data model for the configuration and
   management of Keyed IPv6 tunnels.  The data model includes both
   configuration and state data.  Due to the stateless nature of keyed
   IPv6 tunnels, a model for NETCONF notifications is not necessary.

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

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-l2tpext-keyed-v6-tunnel-yang-01

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-l2tpext-keyed-v6-tunnel-yang-01

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)

internet-drafts | 21 Mar 20:30 2016
Picon

I-D Action: draft-ietf-l2tpext-keyed-ipv6-tunnel-06.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 of the IETF.

        Title           : Keyed IPv6 Tunnel
        Authors         : Maciek Konstantynowicz
                          Giles Heron
                          Rainer Schatzmayr
                          Wim Henderickx
	Filename        : draft-ietf-l2tpext-keyed-ipv6-tunnel-06.txt
	Pages           : 12
	Date            : 2016-03-21

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:
https://tools.ietf.org/html/draft-ietf-l2tpext-keyed-ipv6-tunnel-06

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

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)

internet-drafts | 18 Mar 14:08 2016
Picon

I-D Action: draft-ietf-l2tpext-sbfd-discriminator-03.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 of the IETF.

        Title           : Advertising S-BFD Discriminators in L2TPv3
        Authors         : Vengada Prasad Govindan
                          Carlos Pignataro
	Filename        : draft-ietf-l2tpext-sbfd-discriminator-03.txt
	Pages           : 5
	Date            : 2016-03-18

Abstract:
   This document defines a new AVP that allows L2TP Control Connection
   Endpoints (LCCEs) to advertise one or more Seamless BFD (S-BFD)
   Discriminator values using L2TPv3.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-l2tpext-sbfd-discriminator/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-l2tpext-sbfd-discriminator-03

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-l2tpext-sbfd-discriminator-03

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

Carlos Pignataro (cpignata | 17 Mar 23:59 2016
Picon

Interest in draft-ietf-l2tpext-keyed-ipv6-tunnel?

Hi, WG, Authors,

I would like to probe for interest on advancing this document:

https://datatracker.ietf.org/doc/draft-ietf-l2tpext-keyed-ipv6-tunnel/

Given the lack of response to the RTG-Dir review, the document was sent back to the WG.

As a refresher:
* Document sent to the IESG on 2015-07-07
* RTG-Dir review on 2015-09-11
* Document sent back to the WG due to lack of response to the RTG-Dir on 2016-02-04
* Document expired on 2016-02-05

Is there interest and energy to progress draft-ietf-l2tpext-keyed-ipv6-tunnel?

Thanks,

— Carlos.
_______________________________________________
L2tpext mailing list
L2tpext <at> ietf.org
https://www.ietf.org/mailman/listinfo/l2tpext
Carlos Pignataro (cpignata | 17 Mar 23:58 2016
Picon

Interest in draft-ietf-l2tpext-keyed-ipv6-tunnel?

Hi, WG, Authors,

I would like to probe for interest on advancing this document:

https://datatracker.ietf.org/doc/draft-ietf-l2tpext-keyed-ipv6-tunnel/

Given the lack of response to the RTG-Dir review, the document was sent back to the WG.

As a refresher:
* Document sent to the IESG on 2015-07-07
* RTG-Dir review on 2015-09-11
* Document sent back to the WG due to lack of response to the RTG-Dir on 2016-02-04
* Document expired on 2016-02-05

Is there interest and energy to progress draft-ietf-l2tpext-keyed-ipv6-tunnel?

Thanks,

— Carlos.
_______________________________________________
L2tpext mailing list
L2tpext <at> ietf.org
https://www.ietf.org/mailman/listinfo/l2tpext
Ignacio Goyret | 12 Feb 04:43 2016

Re: Update required to RFC 5515 (L2TP Access Line Information AVP Extensions))

IMHO, if you want the two sets of numbers to track, they'd better be
defined by the same set of IANA numbers. If the IANA databases are
different, sooner or later, they will become different again.

I believe the best solution is to write a simple RFC that makes just
the IANA changes (merging of the two IANA sets into a single set) and
absolutely nothing else. Such an RFC can move quickly and easily.
Anything else would take time.

-Ignacio

At 14:26 2/11/2016, John Gibbons wrote:

>Hello -
> 
>There is a discrepancy between RFC 5515 and RFC 6320 with respect to an inconsistency in the values for
DSL-Type TLV (RFC 6320 section 6.5.2) and ANCP Access Line Type AVP (RFC 5515 section 5.18).  The original
intent has always been that these values are consistent, and they were up to the point 5515 became an RFC. 
RFC 6320, however, was still in draft form, and the enumerated values for the DSL-Type TLV subsequently
changed in a later version of the draft but were never reflected back into RFC 5515.  So far it’s not been a
problem as the values 1-6 match, but should new access-line types be introduced, then a translation will
always have to be performed when conveying the ANCP-sourced value to this L2TP AVP.  
> 
>This is what we currently have:
> 
>RFC 6320 DSL-Type AVP
>RFC 5515 ANCP Access-Line Type AVP
> 
> 
>
(Continue reading)

John Gibbons | 11 Feb 23:26 2016
Picon

Update required to RFC 5515 (L2TP Access Line Information AVP Extensions))

Hello -

 

There is a discrepancy between RFC 5515 and RFC 6320 with respect to an inconsistency in the values for DSL-Type TLV (RFC 6320 section 6.5.2) and ANCP Access Line Type AVP (RFC 5515 section 5.18).  The original intent has always been that these values are consistent, and they were up to the point 5515 became an RFC.  RFC 6320, however, was still in draft form, and the enumerated values for the DSL-Type TLV subsequently changed in a later version of the draft but were never reflected back into RFC 5515.  So far it’s not been a problem as the values 1-6 match, but should new access-line types be introduced, then a translation will always have to be performed when conveying the ANCP-sourced value to this L2TP AVP. 

 

This is what we currently have:

 

RFC 6320 DSL-Type AVP

RFC 5515 ANCP Access-Line Type AVP

 

 

OTHER = 0

 

ADSL1 = 1

0x01 ADSL1

ADSL2 = 2

0x02 ADSL2

ADSL2+ = 3

0x03 ADSL2+

VDSL1 = 4

0x04 VDSL1

VDSL2 = 5

0x05 VDSL2

SDSL = 6

0x06 SDSL

“Future” = 7+

0x07 UNKNOWN

 

0x08+ “Future”

 

 

From a historical timeline, RFC 5515 reached RFC status in May 2009, well before RFC 6320 and was at the time accurately tracking the draft versions (draft-ietf-ancp-protocol).  At the point of becoming an RFC, RFC 5515 was tracking to draft-ietf-ancp-protocol-05, which describes dsl-type as follows:

 

          Following sub-TLVs are currently defined :

 

          +  Type (DSL-Type = 0x91) : Defines the type of transmission

             system in use.  This is a mandatory TLV.

 

                Length : (4 bytes)

 

                Value : (Transmission system : ADSL1 = 0x01, ADSL2 =

                0x02, ADSL2+ = 0x03, VDSL1 = 0x04, VDSL2 = 0x05, SDSL =

                0x06, UNKNOWN = 0x07).

 

It turns out that, for draft-ietf-ancp-protocol-13 (dated January 2011), “UNKNOWN = 0x07” was renamed to “OTHER = 0”, and it was not realized until recently that we’ve had such a discrepancy between RFCs. 

 

This discrepancy is somewhat compounded by the fact that vendors have had to inter-operate with different versions of ANCP:

-        draft-wadhwa-gsmp-l2control-configuration.  The DSL Type field values are consistent with those defined in draft-ietf-ancp-protocol-00 through -12. 

-        draft-ietf-ancp-protocol-00 through 17.  Unfortunately all versions of this draft report the ANCP version 0x31, which implies there is no direct way to tell the change in DSL Type values that occurs at version -13 and after.

-        RFC 6320 – version 0x32

 

That said, to allow interoperability with earlier versions of ANCP and RFC 6320, anticipate future allocation of access line types, and avoid a translation by the LAC, I’d like to initiate an erratum or some form of an update to RFC 5515 (section 5.18.  ANCP Line Type AVP) as follows:

-        Add OTHER 0 for consistency with draft-ietf-ancp-protocol-13 and later versions and RFC 6320

-        Maintain UNKNOWN  0x07 for backward compatibility with draft-ietf-ancp-protocol-13 and earlier versions and draft-wadhwa-gsmp-l2control-configuration-02 and earlier versions.

·        This implies that RFC 6320 will need to be updated such that the DSL-Type value 7 (UNKNOWN) will need to be reserved (restored from the earlier drafts) for backward compatibility, requiring assignment of all new “dsl-types” to start at 8, allowing for re-alignment between RFCs.  I’ve proposed this to one of the RFC 6320 authors to coordinate, and he’s on-board with the approach (I believe he has other follow-on updates he wishes to make to 6320, so here is our chance to fix this gap).

 

With the changes to the two RFCs, we would have the following (changes in green reflect modifications):

 

RFC 6320 DSL-Type AVP

RFC 5515 ANCP Access-Line Type AVP

 

 

OTHER = 0

0x00 OTHER

ADSL1 = 1

0x01 ADSL1

ADSL2 = 2

0x02 ADSL2

ADSL2+ = 3

0x03 ADSL2+

VDSL1 = 4

0x04 VDSL1

VDSL2 = 5

0x05 VDSL2

SDSL = 6

0x06 SDSL

UNKNOWN = 7

0x07 UNKNOWN

0x08+ “Future”

0x08+ “Future”

 

 

With this background, could you offer guidance as to whether this can be covered as an erratum or will an alternate approach be required? 

 

Many thanks for your guidance.

 

 

Regards,

 

John Gibbons

Juniper Networks

 

_______________________________________________
L2tpext mailing list
L2tpext <at> ietf.org
https://www.ietf.org/mailman/listinfo/l2tpext
BRUNGARD, DEBORAH A | 5 Feb 00:15 2016
Picon

FW: ID Tracker State Update Notice: <draft-ietf-l2tpext-keyed-ipv6-tunnel-05.txt>

Hi l2tpext,

This document needs to be updated from the expert review for some time now and as it will have changes, I
recommend it should have another WG Last Call. I've sent it back to the WG.

I hope you can progress the document quickly-
Thanks-
Deborah

-----Original Message-----
From: IETF Secretariat [mailto:ietf-secretariat-reply <at> ietf.org] 
Sent: Thursday, February 04, 2016 6:09 PM
To: cpignata <at> cisco.com; draft-ietf-l2tpext-keyed-ipv6-tunnel.all <at> ietf.org;
draft-ietf-l2tpext-keyed-ipv6-tunnel <at> ietf.org; l2tpext-chairs <at> ietf.org; BRUNGARD, DEBORAH A <db3546 <at> att.com>
Subject: ID Tracker State Update Notice: <draft-ietf-l2tpext-keyed-ipv6-tunnel-05.txt>

IESG state changed to AD is watching from Expert Review
ID Tracker URL: https://datatracker.ietf.org/doc/draft-ietf-l2tpext-keyed-ipv6-tunnel/

Gmane