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

--===============0801449556922031178==
Content-Language: en-US
Content-Type: multipart/signed;
 boundary="Apple-Mail=_C6A311CF-573A-4EE9-9719-2756780278A5";
 protocol="application/pgp-signature"; micalg=pgp-sha256

--Apple-Mail=_C6A311CF-573A-4EE9-9719-2756780278A5
Content-Transfer-Encoding: quoted-printable
Content-Type: text/plain;
	charset=utf-8

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,

=E2=80=94 Carlo.s

> On Feb 12, 2016, at 12:43 AM, Ignacio Goyret =
<[email protected]> wrote:
>=20
> 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.
>=20
> 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.
>=20
> -Ignacio
>=20
>=20
> At 14:26 2/11/2016, John Gibbons wrote:
>=20
>> Hello -
>>=20
>> 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.
>>=20
>> This is what we currently have:
>>=20
>> RFC 6320 DSL-Type AVP
>> RFC 5515 ANCP Access-Line Type AVP
>>=20
>>=20
>>=20
>>=20
>> OTHER =3D 0
>>=20
>>=20
>>=20
>>=20
>> ADSL1 =3D 1
>>=20
>> 0x01 ADSL1
>>=20
>>=20
>> ADSL2 =3D 2
>>=20
>>=20
>>=20
>> 0x02 ADSL2
>>=20
>>=20
>>=20
>> ADSL2+ =3D 3
>>=20
>>=20
>>=20
>> 0x03 ADSL2+
>>=20
>>=20
>>=20
>> VDSL1 =3D 4
>>=20
>>=20
>>=20
>> 0x04 VDSL1
>>=20
>>=20
>>=20
>> VDSL2 =3D 5
>>=20
>>=20
>>=20
>> 0x05 VDSL2
>>=20
>>=20
>>=20
>> SDSL =3D 6
>>=20
>>=20
>>=20
>> 0x06 SDSL
>>=20
>> "Future" =3D 7+
>>=20
>>=20
>> 0x07 UNKNOWN
>>=20
>>=20
>>=20
>>=20
>> 0x08+ "Future"
>>=20
>>=20
>>=20
>>=20
>>=20
>>=20
>>=20
>>=20
>> =46rom 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:
>>=20
>>=20
>>=20
>>=20
>>=20
>>=20
>>         Following sub-TLVs are currently defined :
>>=20
>>=20
>>=20
>>=20
>>=20
>>=20
>>=20
>>         +  Type (DSL-Type =3D 0x91) : Defines the type of =
transmission
>>=20
>>=20
>>=20
>>            system in use.  This is a mandatory TLV.
>>=20
>>=20
>>=20
>>=20
>>=20
>>=20
>>=20
>>               Length : (4 bytes)
>>=20
>>=20
>>=20
>>=20
>>=20
>>=20
>>=20
>>               Value : (Transmission system : ADSL1 =3D 0x01, ADSL2 =3D
>>=20
>>=20
>>=20
>>               0x02, ADSL2+ =3D 0x03, VDSL1 =3D 0x04, VDSL2 =3D 0x05, =
SDSL =3D
>>=20
>>=20
>>=20
>>               0x06, UNKNOWN =3D 0x07).
>>=20
>>=20
>>=20
>>=20
>>=20
>> It turns out that, for draft-ietf-ancp-protocol-13 (dated January =
2011), "UNKNOWN =3D 0x07" was renamed to "OTHER =3D 0", and it was not =
realized until recently that we've had such a discrepancy between RFCs.
>>=20
>> 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
>>=20
>> 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.
>> =C2=B7        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).
>>=20
>> With the changes to the two RFCs, we would have the following =
(changes in green reflect modifications):
>>=20
>> RFC 6320 DSL-Type AVP
>> RFC 5515 ANCP Access-Line Type AVP
>>=20
>>=20
>>=20
>>=20
>> OTHER =3D 00x00 OTHER
>>=20
>>=20
>> ADSL1 =3D 1
>>=20
>> 0x01 ADSL1
>>=20
>>=20
>> ADSL2 =3D 2
>>=20
>>=20
>>=20
>> 0x02 ADSL2
>>=20
>>=20
>>=20
>> ADSL2+ =3D 3
>>=20
>>=20
>>=20
>> 0x03 ADSL2+
>>=20
>>=20
>>=20
>> VDSL1 =3D 4
>>=20
>>=20
>>=20
>> 0x04 VDSL1
>>=20
>>=20
>>=20
>> VDSL2 =3D 5
>>=20
>>=20
>>=20
>> 0x05 VDSL2
>>=20
>>=20
>>=20
>> SDSL =3D 6
>>=20
>>=20
>>=20
>> 0x06 SDSLUNKNOWN =3D 7
>>=20
>>=20
>> 0x07 UNKNOWN0x08+ "Future"
>>=20
>>=20
>> 0x08+ "Future"
>>=20
>>=20
>>=20
>> With this background, could you offer guidance as to whether this can =
be covered as an erratum or will an alternate approach be required?
>>=20
>> Many thanks for your guidance.
>>=20
>>=20
>> Regards,
>>=20
>> John Gibbons
>> Juniper Networks
>>=20
>> _______________________________________________
>> L2tpext mailing list
>> [email protected]://www.ietf.org/mailman/listinfo/l2tpext
>=20


--Apple-Mail=_C6A311CF-573A-4EE9-9719-2756780278A5
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename="signature.asc"
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Message signed with OpenPGP using GPGMail

-----BEGIN PGP SIGNATURE-----
Comment: GPGTools - http://gpgtools.org

iQIcBAEBCAAGBQJWw3frAAoJEIXgpQGOZny91rEP/1N0g2sM7w8bqudWaQ2ZfJr6
NU4kBHRnnvzroNikxOu2DEY+htA3VIMS9T/loE4sl4iZsLPepgadEzg775XfRQpB
UE86NN6dXf4w4WpVfc2NGBoYyCNf20l1di641ofivt+aQ4QI9fCmP0JmBQw6r6sB
OWjS3b30IM9nolmFkG1Gaidag1+BxnAocegaEk7IqK3S6xAqX21xyVSN72kokr1C
2DpWPWzIKFEU4BdHSWpaTPdp60YQEnvPd/fx//k4xtLHYA1W1nIH49Payi0HB0Aj
qXQK6EbA7t7BD4W+6EKieCbQ9I5/hCudw6zGUnpVq9IxmqJMTb0TJ0tGNcppWqFp
lgY6Syvs1Sn4moTte1je96XOoX/hqlV4R/LsnqOvsjsCULvim8sfU+tMObew+NuG
SE0/3p0gWf82s/mxVAkXI+Y3RxX+xjO1naL0dFlfMoK2x1MPX2h7NpDqrNKSv5cc
ExKTsqsHoJ3To2W14Pef9bFOlFrzc5HpALJTaGSzvisv530I31l4FBJADvzRkQDL
iv5FAIV6EkD92kIW9Uvp9vx9ZM/cxHOr2kI+jZa+jvrq0nuZfifLRngb+/12xCS6
E7bHZpOuQbT2CwiGV/hRK0O6TRwX9y83k8yTtYkrs8jtexJ+9oIG6YvmGHMNGG94
3+BzTfMGmPtl6LkkTjeE
=zwF5
-----END PGP SIGNATURE-----

--Apple-Mail=_C6A311CF-573A-4EE9-9719-2756780278A5--


--===============0801449556922031178==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

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

--===============0801449556922031178==--