Re: Update required to RFC 5515 (L2TP Access Line Information AVP Extensions))
Vince Mammoliti <[email protected]> Tue, 16 Feb 2016 13:12:01 -0500
| Newsgroups | gmane.ietf.l2tpext |
|---|---|
| Message-ID | <D2E8D002.1C9015%[email protected]> |
Everyone, = I am no expect, but I do recall that the original values where from IANA numbers. I like Ignacio=B9s 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 protected]> wrote: >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=B9s 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 =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 >> >>=B3Future=B2 =3D 7+ >> >> >>0x07 UNKNOWN >> >> = >> >> >>0x08+ =B3Future=B2 >> >> = >> >> >> = >> >> >> >>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 =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, SD= SL =3D >> >> >> >> 0x06, UNKNOWN =3D 0x07). >> >> >> >> = >> >>It turns out that, for draft-ietf-ancp-protocol-13 (dated January 2011), >>=B3UNKNOWN =3D 0x07=B2 was renamed to =B3OTHER =3D 0=B2, and it was not r= ealized >>until recently that we=B9ve 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 =AD 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=B9d 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. = >>=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 =B3dsl-types=B2 to start at 8, allowing for re-alignment between >>RFCs. I=B9ve proposed this to one of the RFC 6320 authors to coordinate, >>and he=B9s 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 =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+ =B3Future=B2 >> >> >>0x08+ =B3Future=B2 = >> >> = >> = >>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 >>[email protected]://www.ietf.org/mailman/listinfo/l2tpext >