Subject: [ANCP] ANCP Versioning

From: "Wojciech Dec \(wdec\)" <[email-masked]>
Date: Tue, 23 Jan 2007 18:45:28 +0100

> Dear All,
> 
> Recently the WG has seen a fair bit of discussion regarding ANCP
> protocol versioning including several calls for a change in the
> version number. Following consultations with our IETF directorate and
> technical advisors we now feel ready to present to you the ANCP
> versioning strategy that we're proposing for adoption
> 
> A brief summary of the problems.
> ------------------------------------------------
> *	During work on the protocol spec
> draft-wadhwa-gsmp-l2control-configuration, that has now been approved
> as a WG ID, a couple of changes have been made with respect to TLV and
> sub-TLV numbering.. These changes resulted in the possibility that
> ANCP implementations based on previous versions of the draft could
> misinterpret information sent by implementations based on the latest
> draft. The problem has been spotted and a relatively simple fix is
> available, at least for one of the problems, which prevents currently
> deployed implementations from falling foul of this problem. 
> *	The current ANCP implementations and WG protocol spec follow
> GSMP's draft-ietf-gsmp-v3-base-spec-06 and later revisions. This
> base-spec draft actually introduced a change to the basic GSMP
> Message's version field format in comparison to the one defined in
> GSMPv3 (rfc3292): The base-spec takes the version field to be composed
> out of two nibbles, version & sub version, being set to 3 and 1
> respectively. RFC 3292 defines the version field as a single byte
> value, and in section 11.1 sets it to 3. 
> *	Going forward, it is likely that the protocol will introduce
> modifications to the base protocol, which may render backward
> compatibility difficult.
> *	ANCP is currently not compatible with GSMPv3 and it does not
> appear that there is the desire to make a device implementing ANCP be
> able to form an adjacency with a device running an RFC3292 compliant
> version of GSMPv3.
> *	ANCP currently uses GSMP's TCP port number 6068 and this may
> change given potential work on a new transport protocol, and/or a
> shift from GSMP.
> 
> 
> 
> ANCP Versioning strategy.
> ----------------------------------------
> 
> The conclusion that we reached is that any protocol version or
> sub-version change are to be done primarily to address substantial
> protocol changes that will render previous versions incompatible -
> this is best practice, besides common sense that is used throughout
> the IETF community. It will be for the WG group, backed by technical
> advice when required, to decide when this stage is actually reached. 
> In view of our WG's chartered work, such a stage may actually come
> towards the end of the protocol specification where we could, for
> example decide to use a modified protocol state-machine, protocol
> transport, and/or transport port.
> 
> The following list is deemed to not qualify as substantial protocol
> changes, and thus will not be considered as sufficient ground for
> changing/revising the ANCP version, or sub-version number:
> i) a new revision of the protocol spec*
> ii) a conflicting TLV or sub-TLVs
> iii) incompatibilities arising from implementations of pre-RFC drafts.
> iv) new negotiable protocol capabilities (eg Bulk message
> capability)**
> 
> * Unless the revised draft diverges so far in protocol compatibility
> from its origin as to render it incompatible, for example a new
> protocol RFC
> ** The current capabilities negotiation mechanism leaves a few things
> to be desired - this will be discussed in a follow on mail.
> 
If and when the WG agrees that substantial changes have been made to the
protocol, a new protocol version will require an IANA version registry
change.

> With respect to protocol version negotiation, it is not seen as a
> desirable feature of the protocol due to its complexity and potential
> for introducing several more problems than it actually would solve -
> the capabilities negotiation feature is intended precisely to remove
> the need for such a feature, and thus a version negotiation capability
> is not required.
> 
> With all this said, the above points do reflect real world problems
> that the WG will need to deal with. Thus, to resolve the current
> TLV/sub-TLV issue, and potential future ones, we would like to propose
> that whenever a conflict arising out of different draft versions is
> noted, the TLVs in question will be set as being depreciated/reserved
> and a new set assigned - all done though rough consensus in the WG
> naturally. Only when absolutely necessary  would an appendix be
> introduced to the protocol spec to shed some light on the deprecated
> values.
> 
> TLV 0x90 conclusion and TLV work for the WG
> -------------------------------------------------------------
> 
> With the above strategy outlined we can arrive at some conclusions
> with respect to the recent WG "Protocol version nummer for ANCP"
> thread:
> - The problem identified does not warrant a protocol version revision,
> or the introduction of a version negotiation capability.
> - The following is a list of TLVs that are of have been affected by
> conflicts and are thus candidates for depreciation:
> 
> 1. PORT-UP TLV Type 0x02. Should have a new TLV for
> (Access-Loop-Remote-Id) which is currently using 0x02. A new TLV 0x06
> has already been assigned for (Access-Aggregation-Circuit-ID-Binary)
> that was conflicting
> 2. PORT-UP TLV 0x04 sub-TLV 0x90. Should have a new sub-TLV for
> (Access Loop Encapsulation) which is currently set to 0x90. An new TLV
> 0x91 already been assigned for (DSL-Type) that was conflicting.
> 
> Given the above, let's now please commence the discussion on
> depreciating the above two, admittedly important TLVs, and introducing
> new ones. Exiting implementations are known to be able to handle the
> conflict so far, thus the changes will not immediately produce
> problems, however implementers and early adopters should make plans
> towards moving to any agreed new values.
> 
> Kind Regards,
> Woj.
> 
_______________________________________________
ANCP mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ancp