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

In section 8.3, "values for Access Line Information AVPs",
RFC5515 says:

   The Access Line Information AVPs use the Vendor ID of 3561 for the
   ADSL Forum (now Broadband Forum).  The number spaces in these Values
   and their new allocations (e.g., enumerated values for the Access
   Line Access-Loop-Encapsulation AVP and ANCP Access Line Type AVP) are
   managed by the Broadband Forum.

Thus, the authors explicitly delegated the assignment of numbers to a
group outside of the IETF.

RFC6320 did not specify any IANA action regarding the DSL-Type TLV,
which suggests there is no registry anywhere.

At this point, if the two sets are meant to be consistent, they need
to be unified into a single IANA registry, used for both parameters.
A new RFC is required that modifies both RFCs and creates this new
IANA registry. You may also need to coordinate with the Broadband Forum
since they are the designated "owners" of the set of values, as indicated
by RFC5515.

-Ignacio




At 11:26 2/16/2016, Carlos Pignataro (cpignata) wrote:
>I agree with this perspective, with one additional comment: I do not belie=
ve the values being discussed from RFC 5515 and RFC 6320 are currently mana=
ged by IANA.
>
>Indeed, a single registry to point both to is the way to go, and a short R=
FC with IANA instructions achieves that. But how are they managed now?
>
>Thanks,
>
>=97 Carlo.s
>> On Feb 12, 2016, at 12:43 AM, Ignacio Goyret <[email protected]=
m> 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 poin=
t 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 vers=
ion 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 type=
s be introduced, then a translation will always have to be performed when c=
onveying 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
>>> =

>>> "Future" =3D 7+
>>> =

>>> =

>>> 0x07 UNKNOWN
>>> =

>>> =

>>> =

>>> =

>>> 0x08+ "Future"
>>> =

>>> =

>>> =

>>> =

>>> =

>>> =

>>> =

>>> =

>>> From a historical timeline, RFC 5515 reached RFC status in May 2009, we=
ll before RFC 6320 and was at the time accurately tracking the draft versio=
ns (draft-ietf-ancp-protocol).  At the point of becoming an RFC, RFC 5515 w=
as tracking to draft-ietf-ancp-protocol-05, which describes dsl-type as fol=
lows:
>>> =

>>> =

>>> =

>>> =

>>> =

>>> =

>>>         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)=
, "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.
>>> =

>>> This discrepancy is somewhat compounded by the fact that vendors have h=
ad 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 th=
rough -12.
>>> -        draft-ietf-ancp-protocol-00 through 17.  Unfortunately all ver=
sions 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 -1=
3 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 tr=
anslation by the LAC, I'd like to initiate an erratum or some form of an up=
date to RFC 5515 (section 5.18.  ANCP Line Type AVP) as follows:
>>> -        Add OTHER 0 for consistency with draft-ietf-ancp-protocol-13 a=
nd later versions and RFC 6320 -        Maintain UNKNOWN  0x07 for backward=
 compatibility with draft-ietf-ancp-protocol-13 and earlier versions and dr=
aft-wadhwa-gsmp-l2control-configuration-02 and earlier versions.
>>> =C2=B7        This implies that RFC 6320 will need to be updated such t=
hat 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 =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+ "Future"
>>> =

>>> =

>>> 0x08+ "Future"
>>> =

>>> =

>>> =

>>> With this background, could you offer guidance as to whether this can b=
e 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
>> =

>
>