Subject: [L2tpext] Update required to RFC 5515 (L2TP Access Line Information AVP Extensions))

From: John Gibbons <[email-masked]>
Date: Thu, 11 Feb 2016 22:26:49 +0000

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

---

From: Ignacio Goyret <[email-masked]>
Date: Thu, 11 Feb 2016 19:43:20 -0800

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.  
> 
>“Future” = 7+
>0x08+ “Future”
>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.  
> 
>-        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).
> 
>OTHER = 00x00 OTHER
>0x06 SDSLUNKNOWN = 7
>0x07 UNKNOWN0x08+ “Future”
>
>
>0x08+ “Future” 
>
> 
> 
>_______________________________________________
>L2tpext mailing list
>[email-masked]://www.ietf.org/mailman/listinfo/l2tpext

---

From: Vince Mammoliti <[email-masked]>
Date: Tue, 16 Feb 2016 13:12:01 -0500

Everyone, 

I am no expect, but I do recall that the original values where from IANA
numbers.  I like Ignacio¹s suggestion and understand what John is
attempting.

Again, I am not the expert and welcome more seasoned individuals
suggestions. 

Vince

On 2016-02-11, 10:43 PM, "Ignacio Goyret" <[email-masked]>
wrote:

>>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.  
>> 
>>³Future² = 7+
>>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:
>>
>>
>> 
>>
>>
>>
>>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).
>> 
>>0x07 UNKNOWN0x08+ ³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?
>>

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Tue, 16 Feb 2016 19:26:39 +0000

I agree with this perspective, with one additional comment: I do not believe the values being discussed from RFC 5515 and RFC 6320 are currently managed by IANA.

Indeed, a single registry to point both to is the way to go, and a short RFC with IANA instructions achieves that. But how are they managed now?

Thanks,

— Carlo.s

> On Feb 12, 2016, at 12:43 AM, Ignacio Goyret <[email-masked]> wrote:
> 
>> ·        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).
>> 
>> 0x07 UNKNOWN0x08+ "Future"
>> 
>> 
>> 0x08+ "Future"
>> 
>> 
>>

---

From: Ignacio Goyret <[email-masked]>
Date: Tue, 16 Feb 2016 12:26:48 -0800

In section 8.3, "values for Access Line Information AVPs",
RFC5515 says:

   The Access Line Information AVPs use the Vendor ID of 3561 for the
   ADSL Forum (now Broadband Forum).  The number spaces in these Values
   and their new allocations (e.g., enumerated values for the Access
   Line Access-Loop-Encapsulation AVP and ANCP Access Line Type AVP) are
   managed by the Broadband Forum.

Thus, the authors explicitly delegated the assignment of numbers to a
group outside of the IETF.

RFC6320 did not specify any IANA action regarding the DSL-Type TLV,
which suggests there is no registry anywhere.

At this point, if the two sets are meant to be consistent, they need
to be unified into a single IANA registry, used for both parameters.
A new RFC is required that modifies both RFCs and creates this new
IANA registry. You may also need to coordinate with the Broadband Forum
since they are the designated "owners" of the set of values, as indicated
by RFC5515.

-Ignacio

At 11:26 2/16/2016, Carlos Pignataro (cpignata) wrote:
>>> Â·        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).
>>>