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

[Vince Mammoliti <[e-mail]>]

Everyone, 

I am no expect, but I do recall that the original values where from IANA
numbers.  I like Ignacio¹s 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" <[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
>