Subject: [ANCP] ANCP Protocol Versioning

From: "Wojciech Dec (wdec)" <[email-masked]>
Date: Tue, 28 Jul 2009 11:30:06 +0200

Hi All,

During yesterday's ANCP WG meeting at IET75 we discussed the topic of
ANCP versioning and in the room arrived at the following conclusion:
The Pre-RFC version of ANC will continue to be 3.1 as per
draft-ietf-ancp-protocol, however an RFC Editor's note will be
introduced to change version from 3.1 to 3.2 upon publication of the
RFC. This will clearly de-lineate any pre-RFC implementations with
post-RFC ones and alleviate the operators'' problems presented
(http://www3.ietf.org/proceedings/75/slides/ancp-3.ppt)

Going beyond the publication of the RFC, the introduction of new
capabilities or TLVs is expected to be handled by the capability
negotiation mechanism (and new capabilities) or possibly by generalizing
the notion of sub-capability currently in place for the
multicast-control use-cases.

We would like to get feedback from the wider WG on the above, especially
in terms of anyone who was not able to voice their opinion at the
meeting. Based on the received feedback, we'll make a call regarding the
WG consensus on this matter.

Regards,
Woj.

---

From: "Alan Kavanagh" <[email-masked]>
Date: Tue, 28 Jul 2009 13:28:11 -0400

Hi Woj et.al
 
So are we agreeing that option 1 as noted on slide 15 in the Thomas's
presentation is what was agreed on at yesterdays meeting?
 
BR
Alan K

________________________________

From: [email-masked] [mailto:[email-masked]] On Behalf Of
Wojciech Dec (wdec)
Sent: July 28, 2009 5:30 AM
To: [email-masked]
Subject: [ANCP] ANCP Protocol Versioning

Hi All, 

The Pre-RFC version of ANC will continue to be 3.1 as per
draft-ietf-ancp-protocol, however an RFC Editor's note will be
introduced to change version from 3.1 to 3.2 upon publication of the
RFC. This will clearly de-lineate any pre-RFC implementations with
post-RFC ones and alleviate the operators'' problems presented
(http://www3.ietf.org/proceedings/75/slides/ancp-3.ppt
<http://www3.ietf.org/proceedings/75/slides/ancp-3.ppt> )

Regards, 
Woj.

---

From: "Wojciech Dec (wdec)" <[email-masked]>
Date: Wed, 29 Jul 2009 09:33:01 +0200

Not entirely. ANCP already has a versioning field, hence nothing new is
being defined. Also strictly speaking there is no distinction between
version and sub-version, so the choice of 3.2 is purely based on custom
(it can equally well have been 4.0).
Of course this will mean that all "pre-rfc" implementations will
automatically be 100% incompatible with the rfc.
 
-Woj.

	From: Alan Kavanagh [mailto:[email-masked]] 
	Sent: 28 July 2009 19:28
	To: Wojciech Dec (wdec); [email-masked]
	Subject: RE: [ANCP] ANCP Protocol Versioning

	Hi Woj et.al
	 
	So are we agreeing that option 1 as noted on slide 15 in the
Thomas's presentation is what was agreed on at yesterdays meeting?
	 
	BR
	Alan K

	From: [email-masked] [mailto:[email-masked]] On
Behalf Of Wojciech Dec (wdec)
	Sent: July 28, 2009 5:30 AM
	To: [email-masked]
	Subject: [ANCP] ANCP Protocol Versioning

	Hi All, 

	During yesterday's ANCP WG meeting at IET75 we discussed the
topic of ANCP versioning and in the room arrived at the following
conclusion:

	We would like to get feedback from the wider WG on the above,
especially in terms of anyone who was not able to voice their opinion at
the meeting. Based on the received feedback, we'll make a call regarding
the WG consensus on this matter.

	Regards, 
	Woj.

---

From: "Alan Kavanagh" <[email-masked]>
Date: Wed, 29 Jul 2009 09:30:19 -0400

Cheers Woj
 
The only point i would note (excuse if it was already raised on Monday
as i did not attend) is "backward compatibility" between the different
versions of 3.1, 3.2 and future versions if/when/as needed. this should
be noted in the draft.
 
Alan

From: Wojciech Dec (wdec) [mailto:[email-masked]] 
Sent: July 29, 2009 3:33 AM
To: Alan Kavanagh; [email-masked]
Subject: RE: [ANCP] ANCP Protocol Versioning

-Woj.

	Hi Woj et.al

	BR
	Alan K

	Hi All, 

	Regards, 
	Woj.

---

From: "Wojciech Dec (wdec)" <[email-masked]>
Date: Wed, 29 Jul 2009 15:36:54 +0200

Not sure I fully understand your note. Are you proposing that the rfc
editors note the version 3.2 rfc should refer to version 3.1 and call
the two as "incompatible"? Seems rather obvious. If on the other hand
the note should imply that 3.2 is  fully backwards compatible to 3.1,
then there really seems to be no need to have 3.2. Besides this, it's an
implementation choice whether a node will recognise v3.1 (which
interesting enough will not be defined anywhere by then) and 3.2.
 
-Woj.

	Sent: 29 July 2009 15:30

	Cheers Woj
	 
	The only point i would note (excuse if it was already raised on
Monday as i did not attend) is "backward compatibility" between the
different versions of 3.1, 3.2 and future versions if/when/as needed.
this should be noted in the draft.
	 
	Alan

	Not entirely. ANCP already has a versioning field, hence nothing
new is being defined. Also strictly speaking there is no distinction
between version and sub-version, so the choice of 3.2 is purely based on
custom (it can equally well have been 4.0).
	Of course this will mean that all "pre-rfc" implementations will
automatically be 100% incompatible with the rfc.
	 
	-Woj.

		Hi Woj et.al
		 
		So are we agreeing that option 1 as noted on slide 15 in
the Thomas's presentation is what was agreed on at yesterdays meeting?
		 
		BR
		Alan K

		From: [email-masked]
[mailto:[email-masked]] On Behalf Of Wojciech Dec (wdec)
		Sent: July 28, 2009 5:30 AM
		To: [email-masked]
		Subject: [ANCP] ANCP Protocol Versioning

		Hi All, 

		During yesterday's ANCP WG meeting at IET75 we discussed
the topic of ANCP versioning and in the room arrived at the following
conclusion:

		The Pre-RFC version of ANC will continue to be 3.1 as
per draft-ietf-ancp-protocol, however an RFC Editor's note will be
introduced to change version from 3.1 to 3.2 upon publication of the
RFC. This will clearly de-lineate any pre-RFC implementations with
post-RFC ones and alleviate the operators'' problems presented
(http://www3.ietf.org/proceedings/75/slides/ancp-3.ppt
<http://www3.ietf.org/proceedings/75/slides/ancp-3.ppt> )

		Going beyond the publication of the RFC, the
introduction of new capabilities or TLVs is expected to be handled by
the capability negotiation mechanism (and new capabilities) or possibly
by generalizing the notion of sub-capability currently in place for the
multicast-control use-cases.

		We would like to get feedback from the wider WG on the
above, especially in terms of anyone who was not able to voice their
opinion at the meeting. Based on the received feedback, we'll make a
call regarding the WG consensus on this matter.

		Regards, 
		Woj.

---

From: "Alan Kavanagh" <[email-masked]>
Date: Wed, 29 Jul 2009 09:44:16 -0400

No, im not suggesting that Woj, on the contrary im suggesting the
opposite! 
 
It seems no one has raised this issue then, i suggest we discuss this.
IMHO it makes sense to note in the RFC that the current spec is 3.2, and
is backward compatible with 3.1. Its not about an implementation choice,
its noting that both versions are/will be deployed and where possible
3.2, but if a node such as an AN only supports 3.1 we need to have that
noted that this version of 3.1 is also supported etc. thought that was
fairly obvious, if not ill craft up some text and send it to the draft
editors.
 
Alan

From: Wojciech Dec (wdec) [mailto:[email-masked]] 
Sent: July 29, 2009 9:37 AM
To: Alan Kavanagh; [email-masked]
Subject: RE: [ANCP] ANCP Protocol Versioning

-Woj.

	Cheers Woj

	Alan

	 
	-Woj.

		Hi Woj et.al

		BR
		Alan K

		Hi All, 

		Regards, 
		Woj.

---

From: Sanjay Wadhwa <[email-masked]>
Date: Wed, 29 Jul 2009 09:48:29 -0400

In order to ease migration, it will help if BNGs are able to handle multiple peers with different versions (e.g. a 3.2 compliant BNG implementation able to work with a 3.1 AN and a 3.2 AN). Although implied by the protocol, we may want to explicitly state that version compatibility requirement is on an adjacency basis.
The draft will also need to define how the version incompatibility between BNG and AN needs to be handled.

-Sanjay
________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of Alan Kavanagh
Sent: Wednesday, July 29, 2009 9:30 AM
To: Wojciech Dec (wdec); [email-masked]
Subject: Re: [ANCP] ANCP Protocol Versioning

Cheers Woj

The only point i would note (excuse if it was already raised on Monday as i did not attend) is "backward compatibility" between the different versions of 3.1, 3.2 and future versions if/when/as needed. this should be noted in the draft.

Alan

________________________________
From: Wojciech Dec (wdec) [mailto:[email-masked]]
Sent: July 29, 2009 3:33 AM
To: Alan Kavanagh; [email-masked]
Subject: RE: [ANCP] ANCP Protocol Versioning
Not entirely. ANCP already has a versioning field, hence nothing new is being defined. Also strictly speaking there is no distinction between version and sub-version, so the choice of 3.2 is purely based on custom (it can equally well have been 4.0).
Of course this will mean that all "pre-rfc" implementations will automatically be 100% incompatible with the rfc.

-Woj.

So are we agreeing that option 1 as noted on slide 15 in the Thomas's presentation is what was agreed on at yesterdays meeting?

BR
Alan K

________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of Wojciech Dec (wdec)
Sent: July 28, 2009 5:30 AM
To: [email-masked]
Subject: [ANCP] ANCP Protocol Versioning

Hi All,

During yesterday's ANCP WG meeting at IET75 we discussed the topic of ANCP versioning and in the room arrived at the following conclusion:

The Pre-RFC version of ANC will continue to be 3.1 as per draft-ietf-ancp-protocol, however an RFC Editor's note will be introduced to change version from 3.1 to 3.2 upon publication of the RFC. This will clearly de-lineate any pre-RFC implementations with post-RFC ones and alleviate the operators'' problems presented (http://www3.ietf.org/proceedings/75/slides/ancp-3.ppt)

Going beyond the publication of the RFC, the introduction of new capabilities or TLVs is expected to be handled by the capability negotiation mechanism (and new capabilities) or possibly by generalizing the notion of sub-capability currently in place for the multicast-control use-cases.

We would like to get feedback from the wider WG on the above, especially in terms of anyone who was not able to voice their opinion at the meeting. Based on the received feedback, we'll make a call regarding the WG consensus on this matter.

Regards,
Woj.

---

From: "Alan Kavanagh" <[email-masked]>
Date: Wed, 29 Jul 2009 09:51:00 -0400

Exactly, hence we should ahve this explicitly noted in the draft.
 
Alan

From: Sanjay Wadhwa [mailto:[email-masked]] 
Sent: July 29, 2009 9:48 AM
To: Alan Kavanagh; Wojciech Dec (wdec); [email-masked]
Subject: RE: [ANCP] ANCP Protocol Versioning

In order to ease migration, it will help if BNGs are able to handle
multiple peers with different versions (e.g. a 3.2 compliant BNG
implementation able to work with a 3.1 AN and a 3.2 AN). Although
implied by the protocol, we may want to explicitly state that version
compatibility requirement is on an adjacency basis.

The draft will also need to define how the version incompatibility
between BNG and AN needs to be handled.

-Sanjay

Alan Kavanagh

Cheers Woj

Alan

-Woj.

	Hi Woj et.al

	BR

	Alan K

	Hi All, 

	Regards, 
	Woj.

---

From: "Wojciech Dec (wdec)" <[email-masked]>
Date: Wed, 29 Jul 2009 16:00:50 +0200

Sorry, but reference in a future ANCP v3.2 RFC to a version 3.1 which is
NOT defined anywhere (in any normative reference or RFC) does not seem
to be acceptable.
The (minuted) discussion did not cover the notion of how ANCP "version
incompatibility" will be handled. Given that we're not out in the WG to
create version compatibility between an ANCP standard protocol and an
ANCP non-standard based one (or GSMP for that matter), it would seem
that no new definition needs to take place. Feel free to discuss this
further on this thread...
 
-Woj.

	From: [email-masked] [mailto:[email-masked]] On
Behalf Of Alan Kavanagh
	Sent: 29 July 2009 15:51
	To: Sanjay Wadhwa; Wojciech Dec (wdec); [email-masked]
	Subject: Re: [ANCP] ANCP Protocol Versioning

	Exactly, hence we should ahve this explicitly noted in the
draft.
	 
	Alan

	In order to ease migration, it will help if BNGs are able to
handle multiple peers with different versions (e.g. a 3.2 compliant BNG
implementation able to work with a 3.1 AN and a 3.2 AN). Although
implied by the protocol, we may want to explicitly state that version
compatibility requirement is on an adjacency basis.

	The draft will also need to define how the version
incompatibility between BNG and AN needs to be handled.

	-Sanjay

Behalf Of Alan Kavanagh

	Cheers Woj

	Alan

	-Woj.

		Hi Woj et.al

		BR

		Alan K

		Hi All, 

		Regards, 
		Woj.

---

From: "Alan Kavanagh" <[email-masked]>
Date: Wed, 29 Jul 2009 13:10:43 -0400

So what are you sugegsting will happen with current deployments....!!!
Like it or not Woj, fact is it must be covered, if you dont agree then
thats just your single opinion here.
 
By the time you agree on everything we will be onto ANCP Version 4.10
!!! We are spending far too long on getting this draft out the door.

From: Wojciech Dec (wdec) [mailto:[email-masked]] 
Sent: July 29, 2009 10:01 AM
To: Alan Kavanagh; Sanjay Wadhwa; [email-masked]
Subject: RE: [ANCP] ANCP Protocol Versioning

-Woj.

	 
	Alan

	-Sanjay

	Cheers Woj

	Alan

	-Woj.

		Hi Woj et.al

		BR

		Alan K

		Hi All, 

		Regards, 
		Woj.

---

From: Tom Taylor <[email-masked]>
Date: Wed, 29 Jul 2009 20:56:17 +0200

The idea is that there will be two classes of implementation: those conforming 
to the RFC (I.e. version 3.2) and all the others. Thomas saw the problem as 
distinguishing between those two classes. That was because in his network only 
one other implementation will be deployed.

Alan Kavanagh wrote:
> ------------------------------------------------------------------------
> 
> _______________________________________________
> ANCP mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ancp

---

From: "Wojciech Dec (wdec)" <[email-masked]>
Date: Wed, 29 Jul 2009 21:21:48 +0200

Your post bears no useful or constructive input regarding the topic.
Attempting to define backwards compatibility means drawing on a
normative reference to non-standard drafts and is not reasonable (a
reading of http://tools.ietf.org/html/rfc4897 helps). Perhaps you could
be so kind as to give us advise the WG as to where ANCP version 3.1 is
defined and can be normatively referenced in a v3.2 RFC? 
If v3.2 and v3.1 are 100% compatible, except for new capabilities, then
there is hardly a reason for a version change. The only way to have a
reference to v3.1 in an rfc re v3.2 is either as a historic note,
without claims of backwards compatibility, or publish two rfcs (a v3.1
and then a v3.2). Neither of these proposals seem to be appealing.
 
In addition, you may also want to reflect on the quality of your
conclusions and comprehension of general facts...
 
-Woj.

	From: Alan Kavanagh [mailto:[email-masked]] 
	Sent: 29 July 2009 19:11
	To: Wojciech Dec (wdec); Sanjay Wadhwa; [email-masked]
	Subject: RE: [ANCP] ANCP Protocol Versioning

	So what are you sugegsting will happen with current
deployments....!!! Like it or not Woj, fact is it must be covered, if
you dont agree then thats just your single opinion here.
	 
	By the time you agree on everything we will be onto ANCP Version
4.10 !!! We are spending far too long on getting this draft out the
door.

	Sorry, but reference in a future ANCP v3.2 RFC to a version 3.1
which is NOT defined anywhere (in any normative reference or RFC) does
not seem to be acceptable.
	The (minuted) discussion did not cover the notion of how ANCP
"version incompatibility" will be handled. Given that we're not out in
the WG to create version compatibility between an ANCP standard protocol
and an ANCP non-standard based one (or GSMP for that matter), it would
seem that no new definition needs to take place. Feel free to discuss
this further on this thread...
	 
	-Woj.

		From: [email-masked]
[mailto:[email-masked]] On Behalf Of Alan Kavanagh
		Sent: 29 July 2009 15:51
		To: Sanjay Wadhwa; Wojciech Dec (wdec); [email-masked]
		Subject: Re: [ANCP] ANCP Protocol Versioning

		Exactly, hence we should ahve this explicitly noted in
the draft.
		 
		Alan

		In order to ease migration, it will help if BNGs are
able to handle multiple peers with different versions (e.g. a 3.2
compliant BNG implementation able to work with a 3.1 AN and a 3.2 AN).
Although implied by the protocol, we may want to explicitly state that
version compatibility requirement is on an adjacency basis.

		-Sanjay

[mailto:[email-masked]] On Behalf Of Alan Kavanagh

		Cheers Woj

		The only point i would note (excuse if it was already
raised on Monday as i did not attend) is "backward compatibility"
between the different versions of 3.1, 3.2 and future versions
if/when/as needed. this should be noted in the draft.

		Alan

		Not entirely. ANCP already has a versioning field, hence
nothing new is being defined. Also strictly speaking there is no
distinction between version and sub-version, so the choice of 3.2 is
purely based on custom (it can equally well have been 4.0).

		Of course this will mean that all "pre-rfc"
implementations will automatically be 100% incompatible with the rfc.

		-Woj.

			From: Alan Kavanagh
[mailto:[email-masked]] 
			Sent: 28 July 2009 19:28
			To: Wojciech Dec (wdec); [email-masked]
			Subject: RE: [ANCP] ANCP Protocol Versioning

			Hi Woj et.al

			So are we agreeing that option 1 as noted on
slide 15 in the Thomas's presentation is what was agreed on at
yesterdays meeting?

			BR

			Alan K

			Hi All, 

			During yesterday's ANCP WG meeting at IET75 we
discussed the topic of ANCP versioning and in the room arrived at the
following conclusion:

			The Pre-RFC version of ANC will continue to be
3.1 as per draft-ietf-ancp-protocol, however an RFC Editor's note will
be introduced to change version from 3.1 to 3.2 upon publication of the
RFC. This will clearly de-lineate any pre-RFC implementations with
post-RFC ones and alleviate the operators'' problems presented
(http://www3.ietf.org/proceedings/75/slides/ancp-3.ppt
<http://www3.ietf.org/proceedings/75/slides/ancp-3.ppt> )

			We would like to get feedback from the wider WG
on the above, especially in terms of anyone who was not able to voice
their opinion at the meeting. Based on the received feedback, we'll make
a call regarding the WG consensus on this matter.

			Regards, 
			Woj.

---

From: "Alan Kavanagh" <[email-masked]>
Date: Wed, 29 Jul 2009 15:33:06 -0400

What about future versions that maybe defined??? It makes perfect sense
to do that now than later. Lets agree on the facts because you just
don't seem to get it, and i didn't even attend the meeting. We are going
to make the versions and sub-version noted in the draft to 3.2, agree?
(simple yes or no).
 
If in the future we want and need new capabilities for ANCP, then
another version/sub-version would be noted in another RFC, agree (simple
yes or no). If the working group feels it would be beneficial and see's
that this may come to light, then we need also a mechanism for
negotiating this (imho) of which the we may use the Adjacency Protocol!
I will try and craft some details on this and post it to the working
group list if people find this useful and with merit.
 
Woj, i keep my comments technical and not political, you should do the
same as the ANCP Working Group Chair
 
/Alan

From: Wojciech Dec (wdec) [mailto:[email-masked]] 
Sent: July 29, 2009 3:22 PM
To: Alan Kavanagh; Sanjay Wadhwa; [email-masked]
Subject: RE: [ANCP] ANCP Protocol Versioning

Your post bears no useful or constructive input regarding the topic.
Attempting to define backwards compatibility means drawing on a
normative reference to non-standard drafts and is not reasonable (a
reading of http://tools.ietf.org/html/rfc4897
<http://tools.ietf.org/html/rfc4897>  helps). Perhaps you could be so
kind as to give us advise the WG as to where ANCP version 3.1 is defined
and can be normatively referenced in a v3.2 RFC?  
>> I wont comment because that is obvious. 

-Woj.

	 

	 
	-Woj.

		 
		Alan

		-Sanjay

		Cheers Woj

		Alan

		-Woj.

			From: Alan Kavanagh

			Hi Woj et.al

			BR

			Alan K

			Hi All, 

			Regards, 
			Woj.

---

From: Tom Taylor <[email-masked]>
Date: Wed, 29 Jul 2009 21:37:33 +0200

> to make the versions and sub-version noted in the draft to 3.2, agree?
[PTT] Yes
> yes or no). 
[PTT] No.

If the working group feels it would be beneficial and see's

---

From: Peter Arberg <[email-masked]>
Date: Wed, 29 Jul 2009 12:55:02 -0700

Hi Woj,

As I see it the problem is exactly that we do not have a normative reference in a RFC
simply because we have been too long to put anything together on the running code
which are deployed in live networks today.

We have a L2CP reference in a TR document and we have live networks.

So if we decide to go for version 3.2 in the ANCP WG, it would be very beneficial to have
a chapter in the RFC which describe migration from pre-standard ANCP to the standard
RFC.

I'm sure carriers having pre-standard ANCP running in their network will like a clear RFC
statement for how we vendors should handle a incompatibility in a defacto ANCP standard
and the "real" ANCP RFC standard.

So instead of a normative reference i will suggest that the RFC editor of the ANCP protocol
write a chapter and describe what is expected when a RFC standard ANCP ver. 3.2
implementation is getting adjancy connection request from a pre-standard ver. 3.1 ANCP
endpoint.

Too me this seems like a much too important question to simply ignore in a new protocol which
have been in the development for more than 3 years, and have had live networks in multi-vendor
deployments for a long time.

thanks,
Peter

Sent: 29. juli 2009 12:22

Your post bears no useful or constructive input regarding the topic. Attempting to define backwards compatibility means drawing on a normative reference to non-standard drafts and is not reasonable (a reading of http://tools.ietf.org/html/rfc4897 helps). Perhaps you could be so kind as to give us advise the WG as to where ANCP version 3.1 is defined and can be normatively referenced in a v3.2 RFC?
If v3.2 and v3.1 are 100% compatible, except for new capabilities, then there is hardly a reason for a version change. The only way to have a reference to v3.1 in an rfc re v3.2 is either as a historic note, without claims of backwards compatibility, or publish two rfcs (a v3.1 and then a v3.2). Neither of these proposals seem to be appealing.

In addition, you may also want to reflect on the quality of your conclusions and comprehension of general facts...

-Woj.

So what are you sugegsting will happen with current deployments....!!! Like it or not Woj, fact is it must be covered, if you dont agree then thats just your single opinion here.

By the time you agree on everything we will be onto ANCP Version 4.10 !!! We are spending far too long on getting this draft out the door.

Sorry, but reference in a future ANCP v3.2 RFC to a version 3.1 which is NOT defined anywhere (in any normative reference or RFC) does not seem to be acceptable.
The (minuted) discussion did not cover the notion of how ANCP "version incompatibility" will be handled. Given that we're not out in the WG to create version compatibility between an ANCP standard protocol and an ANCP non-standard based one (or GSMP for that matter), it would seem that no new definition needs to take place. Feel free to discuss this further on this thread...

-Woj.

Alan

-Sanjay

Cheers Woj

Alan

-Woj.

BR
Alan K

Hi All,

Regards,
Woj.

---

From: "Alan Kavanagh" <[email-masked]>
Date: Wed, 29 Jul 2009 16:47:11 -0400

Sorry on my second question Im not referring new capabilities in terms
of new TLV's but to "new message types".

So Q 2 below now reads as: If in the future we want and need new message
types (for example) for ANCP, then another version/sub-version would be
required etc.

Alan  

-----Original Message-----
From: Tom Taylor [mailto:[email-masked]] 
Sent: July 29, 2009 3:38 PM
To: Alan Kavanagh
Cc: [email-masked]
Subject: Re: [ANCP] ANCP Protocol Versioning

Alan Kavanagh wrote:
> What about future versions that maybe defined??? It makes perfect 
> sense to do that now than later. Lets agree on the facts because you 
> just don't seem to get it, and i didn't even attend the meeting. We 
> are going to make the versions and sub-version noted in the draft to
3.2, agree?
[PTT] Yes
> another version/sub-version would be noted in another RFC, agree 
> (simple yes or no).
[PTT] No.

> kind as to give us advise the WG as to where ANCP version 3.1 is 
> If v3.2 and v3.1 are 100% compatible, except for new capabilities, 
> then there is hardly a reason for a version change. The only way to 
> have a reference to v3.1 in an rfc re v3.2 is either as a historic 
> note, without claims of backwards compatibility, or publish two rfcs 
> (a v3.1 and then a v3.2). Neither of these proposals seem to be
appealing.
> conclusions and comprehension of general facts...
4.10 
> !!! We are spending far too long on getting this draft out the door.
which 
> is NOT defined anywhere (in any normative reference or RFC) does not 
> seem to be acceptable.

> the WG to create version compatibility between an ANCP standard 
> protocol and an ANCP non-standard based one (or GSMP for that matter),

> it would seem that no new definition needs to take place. Feel free to

> discuss this further on this thread...
> 	 
> 	-Woj.
> 
> 
the draft.
> 		Alan
able to handle 
> implementation able to work with a 3.1 AN and a 3.2 AN).

> 		The draft will also need to define how the version
incompatibility 
> between BNG and AN needs to be handled.
raised on 
> Monday as i did not attend) is "backward compatibility"
nothing new 
> is being defined. Also strictly speaking there is no distinction 
> between version and sub-version, so the choice of 3.2 is purely based 
> on custom (it can equally well have been 4.0).
> 
slide 15 in the 
> Thomas's presentation is what was agreed on at yesterdays meeting?
discussed the topic 
> of ANCP versioning and in the room arrived at the following 
> conclusion:
> 

> be introduced to change version from 3.1 to 3.2 upon publication of 
> the RFC. This will clearly de-lineate any pre-RFC implementations with

> 			Going beyond the publication of the RFC, the
introduction of new 
> negotiation mechanism (and new capabilities) or possibly by 
> generalizing the notion of sub-capability currently in place for the 
on the above, 
> especially in terms of anyone who was not able to voice their opinion 
> at the meeting. Based on the received feedback, we'll make a call 
> regarding the WG consensus on this matter.
> 
> 			Regards, 
> 			Woj. 
> 
> 
> 
>

---

From: "Wojciech Dec (wdec)" <[email-masked]>
Date: Thu, 30 Jul 2009 01:40:38 +0200

Hi Peter,
 
so, based on the experience with the IESG review of last call drafts,
one has reason to believe that pulling a trick like referring to a  v3.1
in anything but non normative is not going fly (nor would it be
reasonable if it happens to be exactly the same as v3.2). The time of
making it to rfc of a v3.1 has very little to do with it, since the
latest draft of the protocol spec is to our knowledge 100% compatible
with "pre-standard" implementation except for new capabilities.
Anyway, before we go off documenting all that, perhaps a step back
should be taken to evaluate the situation:
- the currently deployed protocol, based on some set of the current
drafts, has it's core functionality intact. I.e. Given that in all new
activities we've strived for backwards compatibility, with the exception
of historic tlv conflict, there doesn't seem to be much of a reason for
v3.2
- the tlv conflict is inherent to a stage of ANCP development and a v3.2
or its claims of backward compatibility to v3.1 (with conflicting tlv
set) are not going to matter; the affected tlvs will still clash,
irrespective of "backwards compatibility" of versions.
- Capability negotiation as offered by ANCP by itself provides a way to
distinguish new protocol functions. It's here that the WG has been
spending most of its time, and it's recognised as the way in which the
protocol will evolve (or via sub-capabilities)
- An operator has requested that a line be drawn to distinguish a set of
compatible pre-standard implementations (thus same pre-standard
versions)  that they are running and the actual standard which may be in
their opinion incompatible, hence v3.1 becomes to v3.2. The same
operator has not expressed a need to have an rfc for v3.1
- Migrating from v3.1 to v3.2 is an operational activity for which the
protocol does not appear to require modification (this appears to be no
different than transitioning from L2TPv2 to v3 say).
- The current protocol draft states that the version SHOULD be 3.1
(which appears to need a correction)
 
Based on the above, it seems to me that if we go at a stroke to a v3.2
when the rfc gets published we could try to navigate by having a clause
which states that pre-rfc  eg v3.1 *may* be compatible and a hint to
reflect that version number to the sender but leaving remaining
behaviour un-specified (since there is no actual guarantee of
compatibility). How does this sound?
 
Cheers,
Woj.

	From: Peter Arberg [mailto:[email-masked]] 
	Sent: 29 July 2009 21:55
	To: Wojciech Dec (wdec); Alan Kavanagh; Sanjay Wadhwa;
[email-masked]
	Subject: RE: [ANCP] ANCP Protocol Versioning

	Hi Woj,
	 
	As I see it the problem is exactly that we do not have a
normative reference in a RFC
	simply because we have been too long to put anything together on
the running code
	which are deployed in live networks today.
	 
	We have a L2CP reference in a TR document and we have live
networks.
	 
	So if we decide to go for version 3.2 in the ANCP WG, it would
be very beneficial to have
	a chapter in the RFC which describe migration from pre-standard
ANCP to the standard
	RFC.
	 
	I'm sure carriers having pre-standard ANCP running in their
network will like a clear RFC
	statement for how we vendors should handle a incompatibility in
a defacto ANCP standard
	and the "real" ANCP RFC standard.
	 
	So instead of a normative reference i will suggest that the RFC
editor of the ANCP protocol 
	write a chapter and describe what is expected when a RFC
standard ANCP ver. 3.2 
	implementation is getting adjancy connection request from a
pre-standard ver. 3.1 ANCP
	endpoint.
	 
	Too me this seems like a much too important question to simply
ignore in a new protocol which
	have been in the development for more than 3 years, and have had
live networks in multi-vendor
	deployments for a long time.
	 
	thanks,
	Peter

		Your post bears no useful or constructive input
regarding the topic. Attempting to define backwards compatibility means
drawing on a normative reference to non-standard drafts and is not
reasonable (a reading of http://tools.ietf.org/html/rfc4897 helps).
Perhaps you could be so kind as to give us advise the WG as to where
ANCP version 3.1 is defined and can be normatively referenced in a v3.2
RFC? 
		If v3.2 and v3.1 are 100% compatible, except for new
capabilities, then there is hardly a reason for a version change. The
only way to have a reference to v3.1 in an rfc re v3.2 is either as a
historic note, without claims of backwards compatibility, or publish two
rfcs (a v3.1 and then a v3.2). Neither of these proposals seem to be
appealing.
		 
		In addition, you may also want to reflect on the quality
of your conclusions and comprehension of general facts...
		 
		-Woj.

			From: Alan Kavanagh
[mailto:[email-masked]] 
			Sent: 29 July 2009 19:11
			To: Wojciech Dec (wdec); Sanjay Wadhwa;
[email-masked]
			Subject: RE: [ANCP] ANCP Protocol Versioning

			So what are you sugegsting will happen with
current deployments....!!! Like it or not Woj, fact is it must be
covered, if you dont agree then thats just your single opinion here.
			 
			By the time you agree on everything we will be
onto ANCP Version 4.10 !!! We are spending far too long on getting this
draft out the door.

			From: Wojciech Dec (wdec)
[mailto:[email-masked]] 
			Sent: July 29, 2009 10:01 AM
			To: Alan Kavanagh; Sanjay Wadhwa; [email-masked]
			Subject: RE: [ANCP] ANCP Protocol Versioning

			Sorry, but reference in a future ANCP v3.2 RFC
to a version 3.1 which is NOT defined anywhere (in any normative
reference or RFC) does not seem to be acceptable.
			The (minuted) discussion did not cover the
notion of how ANCP "version incompatibility" will be handled. Given that
we're not out in the WG to create version compatibility between an ANCP
standard protocol and an ANCP non-standard based one (or GSMP for that
matter), it would seem that no new definition needs to take place. Feel
free to discuss this further on this thread...
			 
			-Woj.

				From: [email-masked]
[mailto:[email-masked]] On Behalf Of Alan Kavanagh
				Sent: 29 July 2009 15:51
				To: Sanjay Wadhwa; Wojciech Dec (wdec);
[email-masked]
				Subject: Re: [ANCP] ANCP Protocol
Versioning

				Exactly, hence we should ahve this
explicitly noted in the draft.
				 
				Alan

				From: Sanjay Wadhwa
[mailto:[email-masked]] 
				Sent: July 29, 2009 9:48 AM
				To: Alan Kavanagh; Wojciech Dec (wdec);
[email-masked]
				Subject: RE: [ANCP] ANCP Protocol
Versioning

				In order to ease migration, it will help
if BNGs are able to handle multiple peers with different versions (e.g.
a 3.2 compliant BNG implementation able to work with a 3.1 AN and a 3.2
AN). Although implied by the protocol, we may want to explicitly state
that version compatibility requirement is on an adjacency basis.

				The draft will also need to define how
the version incompatibility between BNG and AN needs to be handled.

				-Sanjay

				Subject: Re: [ANCP] ANCP Protocol
Versioning

				Cheers Woj

				The only point i would note (excuse if
it was already raised on Monday as i did not attend) is "backward
compatibility" between the different versions of 3.1, 3.2 and future
versions if/when/as needed. this should be noted in the draft.

				Alan

				From: Wojciech Dec (wdec)
[mailto:[email-masked]] 
				Sent: July 29, 2009 3:33 AM
				To: Alan Kavanagh; [email-masked]
				Subject: RE: [ANCP] ANCP Protocol
Versioning

				Not entirely. ANCP already has a
versioning field, hence nothing new is being defined. Also strictly
speaking there is no distinction between version and sub-version, so the
choice of 3.2 is purely based on custom (it can equally well have been
4.0).

				Of course this will mean that all
"pre-rfc" implementations will automatically be 100% incompatible with
the rfc.

				-Woj.

				From: Alan Kavanagh
[mailto:[email-masked]] 
				Sent: 28 July 2009 19:28
				To: Wojciech Dec (wdec); [email-masked]
				Subject: RE: [ANCP] ANCP Protocol
Versioning

				Hi Woj et.al

				So are we agreeing that option 1 as
noted on slide 15 in the Thomas's presentation is what was agreed on at
yesterdays meeting?

				BR

				Alan K

				Hi All, 

				During yesterday's ANCP WG meeting at
IET75 we discussed the topic of ANCP versioning and in the room arrived
at the following conclusion:

				The Pre-RFC version of ANC will continue
to be 3.1 as per draft-ietf-ancp-protocol, however an RFC Editor's note
will be introduced to change version from 3.1 to 3.2 upon publication of
the RFC. This will clearly de-lineate any pre-RFC implementations with
post-RFC ones and alleviate the operators'' problems presented
(http://www3.ietf.org/proceedings/75/slides/ancp-3.ppt
<http://www3.ietf.org/proceedings/75/slides/ancp-3.ppt> )

				Going beyond the publication of the RFC,
the introduction of new capabilities or TLVs is expected to be handled
by the capability negotiation mechanism (and new capabilities) or
possibly by generalizing the notion of sub-capability currently in place
for the multicast-control use-cases.

				We would like to get feedback from the
wider WG on the above, especially in terms of anyone who was not able to
voice their opinion at the meeting. Based on the received feedback,
we'll make a call regarding the WG consensus on this matter.

				Regards, 
				Woj.

---

From: Peter Arberg <[email-masked]>
Date: Wed, 29 Jul 2009 17:37:41 -0700

Hi Woj,

I did not realize it was last-call, I must have missed that email on the mailing list.

I agree with you that also to my knowledge different implementations have been able to
keep backward compatibility to earlier drafts, and if the introduction of the new version
number 3.2 is because of fear of non compatible implementations then it is not valid, as
it is very doable to have backwards compatible to previous drafts so far.

But in my mind it still seems like a good idea to bump the version number, if for nothing
else then to mark the ANCP standards first step is complete, and to move away one more
step to the GSMP tie.

But with the reference as you show and also all the reference we still have to GSMP in the
draft document, it just seems like we are making it very difficult for any newcomers to the
ANCP work to decide what to do and what not to do.

I'm not very afraid that vendors who already have a pre-standard ANCP implementation can
figure out what to do, but why not make it more easy for everyboby by having a little more
description on this.

In the GSMP RFC which is referenced it states:
---
   GSMP contains an adjacency protocol.  The adjacency protocol is used
      to synchronise states across the link, to negotiate which version
      of the GSMP protocol to use, to discover the identity of the
      entity at the other end of a link, and to detect when it changes.
---

another place in the GSMP RFC it talks about a minimum set of messages which must be
supported for a version, so by having still GSMP reference in the ANCP draft, and yet no clear
statement on what protocol version we would expect to make an adjency seems wrong to me.

In my mind it do not have to be a long section, it can be done in a small paragraph to describe
that the ANCP version of 3.2 should be able to change it's version to a lower pre-standard 3.1
version if it supports earlier drafts of ANCP.

Do we know what happens to existing ANCP implementations if the see a adjancy message
with a version number different from 3.1 ?

cheers,
Peter

________________________________
From: Wojciech Dec (wdec) [mailto:[email-masked]]
Sent: 29. juli 2009 16:41
To: Peter Arberg; Alan Kavanagh; Sanjay Wadhwa; [email-masked]
Subject: RE: [ANCP] ANCP Protocol Versioning

Hi Peter,

so, based on the experience with the IESG review of last call drafts, one has reason to believe that pulling a trick like referring to a  v3.1 in anything but non normative is not going fly (nor would it be reasonable if it happens to be exactly the same as v3.2). The time of making it to rfc of a v3.1 has very little to do with it, since the latest draft of the protocol spec is to our knowledge 100% compatible with "pre-standard" implementation except for new capabilities.
Anyway, before we go off documenting all that, perhaps a step back should be taken to evaluate the situation:
- the currently deployed protocol, based on some set of the current drafts, has it's core functionality intact. I.e. Given that in all new activities we've strived for backwards compatibility, with the exception of historic tlv conflict, there doesn't seem to be much of a reason for v3.2
- the tlv conflict is inherent to a stage of ANCP development and a v3.2 or its claims of backward compatibility to v3.1 (with conflicting tlv set) are not going to matter; the affected tlvs will still clash, irrespective of "backwards compatibility" of versions.
- Capability negotiation as offered by ANCP by itself provides a way to distinguish new protocol functions. It's here that the WG has been spending most of its time, and it's recognised as the way in which the protocol will evolve (or via sub-capabilities)
- An operator has requested that a line be drawn to distinguish a set of compatible pre-standard implementations (thus same pre-standard versions)  that they are running and the actual standard which may be in their opinion incompatible, hence v3.1 becomes to v3.2. The same operator has not expressed a need to have an rfc for v3.1
- Migrating from v3.1 to v3.2 is an operational activity for which the protocol does not appear to require modification (this appears to be no different than transitioning from L2TPv2 to v3 say).
- The current protocol draft states that the version SHOULD be 3.1 (which appears to need a correction)

Based on the above, it seems to me that if we go at a stroke to a v3.2 when the rfc gets published we could try to navigate by having a clause which states that pre-rfc  eg v3.1 *may* be compatible and a hint to reflect that version number to the sender but leaving remaining behaviour un-specified (since there is no actual guarantee of compatibility). How does this sound?

Cheers,
Woj.

________________________________
From: Peter Arberg [mailto:[email-masked]]
Sent: 29 July 2009 21:55
To: Wojciech Dec (wdec); Alan Kavanagh; Sanjay Wadhwa; [email-masked]
Subject: RE: [ANCP] ANCP Protocol Versioning

Hi Woj,

thanks,
Peter

-Woj.

-Woj.

Alan

-Sanjay

Cheers Woj

Alan

-Woj.

BR
Alan K

Hi All,

Regards,
Woj.

---

From: Tom Taylor <[email-masked]>
Date: Thu, 30 Jul 2009 08:41:43 +0200

The answer is still no. We would add these new message types in separate 
documents and identify them as new capabilities.

>> another version/sub-version would be noted in another RFC, agree 
...