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 in=
consistency in the values for DSL-Type TLV (RFC 6320 section 6.5.2) and ANC=
P Access Line Type AVP (RFC 5515 section 5.18).  The original intent has al=
ways been that these values are consistent, and they were up to the point 5=
515 became an RFC.  RFC 6320, however, was still in draft form, and the enu=
merated 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=92s n=
ot 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 co=
nveying 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 =3D 0
>
> =

>
>
>ADSL1 =3D 1
>
>0x01 ADSL1
>
>
>ADSL2 =3D 2
>
>
>
>0x02 ADSL2
>
>
>
>ADSL2+ =3D 3
>
>
>
>0x03 ADSL2+
>
>
>
>VDSL1 =3D 4
>
>
>
>0x04 VDSL1
>
>
>
>VDSL2 =3D 5
>
>
>
>0x05 VDSL2
>
>
>
>SDSL =3D 6
>
>
>
>0x06 SDSL
>
>=93Future=94 =3D 7+
>
>
>0x07 UNKNOWN
>
> =

>
>
>0x08+ =93Future=94
>
> =

>
>
> =

>
>
>
>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 follow=
s:
>
>
> =

>
>
>
>          Following sub-TLVs are currently defined :
>
>
>
> =

>
>
>
>          +  Type (DSL-Type =3D 0x91) : Defines the type of transmission
>
>
>
>             system in use.  This is a mandatory TLV.
>
>
>
> =

>
>
>
>                Length : (4 bytes)
>
>
>
> =

>
>
>
>                Value : (Transmission system : ADSL1 =3D 0x01, ADSL2 =3D
>
>
>
>                0x02, ADSL2+ =3D 0x03, VDSL1 =3D 0x04, VDSL2 =3D 0x05, SDS=
L =3D
>
>
>
>                0x06, UNKNOWN =3D 0x07).
>
>
>
> =

>
>It turns out that, for draft-ietf-ancp-protocol-13 (dated January 2011), =
=93UNKNOWN =3D 0x07=94 was renamed to =93OTHER =3D 0=94, and it was not rea=
lized until recently that we=92ve 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 va=
lues are consistent with those defined in draft-ietf-ancp-protocol-00 throu=
gh -12.  =

>-        draft-ietf-ancp-protocol-00 through 17.  Unfortunately all versio=
ns of this draft report the ANCP version 0x31, which implies there is no di=
rect way to tell the change in DSL Type values that occurs at version -13 a=
nd after.
>-        RFC 6320 =96 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 trans=
lation by the LAC, I=92d like to initiate an erratum or some form of an upd=
ate 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 co=
mpatibility with draft-ietf-ancp-protocol-13 and earlier versions and draft=
-wadhwa-gsmp-l2control-configuration-02 and earlier versions. =

>=B7        This implies that RFC 6320 will need to be updated such that th=
e DSL-Type value 7 (UNKNOWN) will need to be reserved (restored from the ea=
rlier drafts) for backward compatibility, requiring assignment of all new =
=93dsl-types=94 to start at 8, allowing for re-alignment between RFCs.  I=
=92ve proposed this to one of the RFC 6320 authors to coordinate, and he=92=
s on-board with the approach (I believe he has other follow-on updates he w=
ishes 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 =3D 00x00 OTHER
>
>
>ADSL1 =3D 1
>
>0x01 ADSL1
>
>
>ADSL2 =3D 2
>
>
>
>0x02 ADSL2
>
>
>
>ADSL2+ =3D 3
>
>
>
>0x03 ADSL2+
>
>
>
>VDSL1 =3D 4
>
>
>
>0x04 VDSL1
>
>
>
>VDSL2 =3D 5
>
>
>
>0x05 VDSL2
>
>
>
>SDSL =3D 6
>
>
>
>0x06 SDSLUNKNOWN =3D 7
>
>
>0x07 UNKNOWN0x08+ =93Future=94
>
>
>0x08+ =93Future=94 =

>
> =

> =

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

> =

>Many thanks for your guidance.
> =

> =

>Regards,
> =

>John Gibbons
>Juniper Networks
> =

>_______________________________________________
>L2tpext mailing list
>[email protected]://www.ietf.org/mailman/listinfo/l2tpext