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

["Carlos Pignataro (cpignata)" <[e-mail]>]

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 <[e-mail]> 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'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 = 00x00 OTHER
>> 
>> 
>> ADSL1 = 1
>> 
>> 0x01 ADSL1
>> 
>> 
>> ADSL2 = 2
>> 
>> 
>> 
>> 0x02 ADSL2
>> 
>> 
>> 
>> ADSL2+ = 3
>> 
>> 
>> 
>> 0x03 ADSL2+
>> 
>> 
>> 
>> VDSL1 = 4
>> 
>> 
>> 
>> 0x04 VDSL1
>> 
>> 
>> 
>> VDSL2 = 5
>> 
>> 
>> 
>> 0x05 VDSL2
>> 
>> 
>> 
>> SDSL = 6
>> 
>> 
>> 
>> 0x06 SDSLUNKNOWN = 7
>> 
>> 
>> 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?
>> 
>> Many thanks for your guidance.
>> 
>> 
>> Regards,
>> 
>> John Gibbons
>> Juniper Networks
>> 
>> _______________________________________________
>> L2tpext mailing list
>> [e-mail]://www.ietf.org/mailman/listinfo/l2tpext
>