Subject: WG: [ANCP] ANCP Versioning

From: "Busser, M" <[email-masked]>
Date: Thu, 1 Feb 2007 11:15:24 +0100

Hi Wojciech

Please see inline.

Best regards

Thomas & Michael

________________________________

	Von: Wojciech Dec (wdec) [mailto:[email-masked]] 
	Gesendet: Dienstag, 23. Januar 2007 18:45
	An: [email-masked]
	Betreff: [ANCP] ANCP Versioning

	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. 

	Taking this into account, from my perspective:
	 - we in fact already have an ANCP protocol version number
(located in the GSMP-Header, being set to 3.1)
	 - we might change this number, if the draft becomes a RFC

	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. 

	Declaring a TLV as depricated and assigning a new set of
TLV-numbers will solve the interworking problem only, if   the
depricated TLV's will still be supported. Nevertheless "old" depreciated
TLVs have to be supported for all future version to keep interability.
	Otherwise we will end up with the same problems again and again,
don't we?

	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. 

	Just leaving the DSL-Type at 0x90 and moving the
Access-Loop-Encapsulation to 0x91 will solve the problem without the
need of marking something as depricated.
	Is there any reason not to do so?  

	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

---

From: "Romascanu, Dan \(Dan\)" <[email-masked]>
Date: Thu, 1 Feb 2007 14:21:02 +0200

_____  

	From: Busser, M [mailto:[email-masked]] 

		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. 

		Otherwise we will end up with the same problems again
and again, don't we?

		[DR] Not really IMO. Interoperability of a specific
function is tested at the level of a given version. The problem is to
avoid conflicting TLVs for the same function. Although continuing for a
while to support deprecated TLVs is a good migration tactics, I do not
believe that this is required from an interoperability point of view. 

		Dan