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

[John Gibbons <[e-mail]>]

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