Subject: Re: [ANCP] ANCP Protocol Versioning

From: Hongyu Li <[email-masked]>
Date: Mon, 10 Aug 2009 14:51:35 +0800

Hi Peter,
 
I guess you are afraid when a new BNG implementing ANCP per the future RFC, whether it can talk to pre-rfc version AN. IMHO, this is
a question that should go to operators having pre-rfc ANs. If they request so, we may have to define both 3.1 and 3.2 actions in the
draft, which is really odd. Otherwise, it is only a piece of cake. Everybody just follows rfc.
 
cheers,
Hongyu

  _____  

From: [email-masked] [mailto:[email-masked]] On Behalf Of Peter Arberg
Sent: Thursday, July 30, 2009 8:38 AM
To: Wojciech Dec (wdec); Alan Kavanagh; Sanjay Wadhwa; [email-masked]
Subject: Re: [ANCP] ANCP Protocol Versioning

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,
 
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

  _____  

From: [email-masked] [mailto:[email-masked]] On Behalf Of Wojciech Dec (wdec)
Sent: 29. juli 2009 12:22
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 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

  _____  

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.

  _____  

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:

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: Mon, 10 Aug 2009 11:45:54 -0400

Hi All

I typed up some text to include in the ancp protocol draft,based on some discussions. So from reading the minutes it appears that the WG has agreed on moving the sub-version number to 2, which gives us Version/Sub 3.2. It makes sense to have this clearly noted in the ietf-ancp-protocol draft. I suggest on adding the following text to the ancp protocol draft to provide a clear reasoning and for the uplift and move us forward:

Prior to initiation of this work, existing ANCP deployments used an ANCP Protocol Version/Sub-Version 3.1. which differs in the TLV's from this RFC standards track version. Therefore RFC compliant versions MAY choose to work with such pre-RFC peers (NAS and DSLAM). 

A NAS with ANCP protocol 3.2 MAY support 3.1 and 3.2 DSLAMs. The ancp protocol Version/Sub-Version is set on a per peer basis and is synchronized/negotiated by the GSMPv3 Adjacency protocol as noted in section 5.3. to agree on the protocol version to use. 

Alan

________________________________

From: [email-masked] [mailto:[email-masked]] 
Sent: August 10, 2009 11:35 AM
To: [email-masked]; Peter Arberg; [email-masked]; Alan Kavanagh; [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: AW: [ANCP] ANCP Protocol Versioning

Hi all,
 
from our perspective it is essential to have a practible way to migrate to RFC.

regards
Peter Hamacher

Deutsche Telekom Netzproduktion GmbH
Zentrum Technik Einführung
Peter Hamacher
Heinrich-Hertz-Straße 3-7, 64295 Darmstadt
+49 6151 628 2864 (Tel.)
+49 521 92100494 (Fax)
E-Mail: [email-masked] <mailto:[email-masked]> 
http://www.telekom.com <http://www.telekom.com/> 

Deutsche Telekom Netzproduktion GmbH
Aufsichtsrat: Timotheus Höttges (Vorsitzender)
Geschäftsführung: Dr. Bruno Jacobfeuerborn (Vorsitzender), Albert Matheis, Klaus Peren
Handelsregister: Amtsgericht Bonn HRB 14190
Sitz der Gesellschaft: Bonn
USt-IdNr.: DE 814645262

Erleben, was verbindet.

________________________________

Von: [email-masked] [mailto:[email-masked]] Im Auftrag von Hongyu Li
Gesendet: Montag, 10. August 2009 08:52
An: 'Peter Arberg'; 'Wojciech Dec (wdec)'; 'Alan Kavanagh'; 'Sanjay Wadhwa'; [email-masked]
Betreff: Re: [ANCP] ANCP Protocol Versioning

Hi Peter,
 
I guess you are afraid when a new BNG implementing ANCP per the future RFC, whether it can talk to pre-rfc version AN. IMHO, this is a question that should go to operators having pre-rfc ANs. If they request so, we may have to define both 3.1 and 3.2 actions in the draft, which is really odd. Otherwise, it is only a piece of cake. Everybody just follows rfc.
 
cheers,
Hongyu

________________________________

	Hi Woj,

	 

	 

	 
	 
	cheers,
	Peter

________________________________

		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.

________________________________

			Hi Woj,

			 

			 
			 
			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.

				-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

________________________________

					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

________________________________

					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).

					-Woj.

________________________________

					Hi Woj et.al

					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: Robert Rennison <[email-masked]>
Date: Mon, 10 Aug 2009 11:30:32 -0400

Peter, Honyu

Whilst a vendor may decide unilaterally  to support  pre-standard implementations  of  ANCP, it would be rather strange to see an RFC pointing out that pre-standard versions of the RFC SHOULD, or even MAY be supported.

Indeed it was agreed that no explicit mention of pre-standard versions should be made within the final RFC.

Trying to come up with heuristics to allow for interoperability with all of the pre-standard flavors of ANCP is not something that was deemed desirable to put into an RFC.

"At least" one can see from the version field that the RFC version is 3.2 and that pre-standard versions are clearly identified, this should reduce the amount of logic to infer exactly what version of the draft is being implemented.

One major operator present was OK, reluctantly  but ok,  with  "merely" being able to differentiate the pre-standard versions as a whole from the standard version, hence bumping the version number provides a  way of resetting things and then ensuring that in the future any
new TLVs, do not overlap with other TLVs and that the capability negotiation mechanism is used to differentiate new capabilities within the protocol without having to bump versions again.

So, whilst not a perfect solution to fix all of the sins of the past, I think this is a reasonably pragmatic compromise.

Cheers

Rob

________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of Hongyu Li
Sent: Monday, August 10, 2009 2:52 AM
To: 'Peter Arberg'; 'Wojciech Dec (wdec)'; 'Alan Kavanagh'; 'Sanjay Wadhwa'; [email-masked]
Subject: Re: [ANCP] ANCP Protocol Versioning

Hi Peter,

cheers,
Hongyu

Hi Woj,

cheers,
Peter

Hi Peter,

Cheers,
Woj.

Hi Woj,

thanks,
Peter

-Woj.

-Woj.

Alan

-Sanjay

Cheers Woj

Alan

-Woj.

BR
Alan K

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)

Regards,
Woj.

---

From: Hongyu Li <[email-masked]>
Date: Tue, 11 Aug 2009 09:36:24 +0800

Robert,
 
I agree with most of your comments. There is only one problem I have regarding to your proposal, actually this applies to Alan's
proposal also. If we say something in the document that you may need to talk to a device in a language with version 3.1, but we say
nothing about what are the actions of this language v3.1 while we know that they are different from actions of v3.2, such
description will lose its guidance to readers.
 
If we say something of supporting v3.1, we may have to say what it really is. Otherwise, we don't say anything about it. I
personally prefer the latter, which is simple. It shall not be the burden of this future RFC to carry all historical residue.
 
cheers,
Hongyu

  _____  

From: Robert Rennison [mailto:[email-masked]] 
Sent: Tuesday, August 11, 2009 4:04 AM
To: Alan Kavanagh; [email-masked]; [email-masked]; Peter Arberg; [email-masked]; [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: RE: [ANCP] ANCP Protocol Versioning

Alan,
 
Ok so perhaps the RFC may use a "may" but in a non normative section.
 
A lot would depend on where in the document you wished to place any such note. As Woj pointed out in an earlier email, anything in a
normative section would most likely not get past the editors.
 
Perhaps an appendix "
 
I'd be reluctant to cover how to negotiate the version.  Your reference to section 5.3 refers to capabilities negotiation not
version negotiation which is covered in  section 11.1 of 3292  where the version negotiation is discussed, note however that this
refers to a single version field not the version/sub version field as used in ANCP. Once you get into mentioning the version
negotiation then one would have to cover how one tell the difference between  versions of the versions i.e. between these versions
using Version 3.1  draft-wadwha- vs draft-ietf-ancp-....  .

Hence it would perhaps be better to  omit anything about how to do any version negotiation. say that the RFC compliant version may
use the version/subversion field to detect a pre-standard implementation and that this maybe done on a per peer basis such that a
given NAS may support both Standards compliant  3.2  and pre-standard
 
How about.
 
---------------------------------------------------------------------------------------
Appendix. Handling of pre-RFC deployments of the ANCP  protocol
 
This appendix is non normative
 
Prior to completion of this document, several pre-RFC  versions of the protocol were documented and implemented. 
There were numerous pre-standard versions of the protocol all using a version/subversion field set to 3.1.
 
A NAS implementing the ANCP protocol as defined in this document may, on a peer basis, use the version and subversion field
to detect a pre-RFC implementation of the protocol and choose to work with such pre-RFC peers ( e.g NAS or DSLAM)
-----------------------------------------------------------------------------------
 
Note lower case "may" since I'm not sure that upper case MAY applies in non-normative text.
 
Cheers
 
Rob

  _____  

From: [email-masked] [mailto:[email-masked]] On Behalf Of Alan Kavanagh
Sent: Monday, August 10, 2009 11:46 AM
To: [email-masked]; [email-masked]; Peter Arberg; [email-masked]; [email-masked]; [email-masked]
Cc: [email-masked]; [email-masked]
Subject: Re: [ANCP] ANCP Protocol Versioning

Hi All

I typed up some text to include in the ancp protocol draft,based on some discussions. So from reading the minutes it appears that
the WG has agreed on moving the sub-version number to 2, which gives us Version/Sub 3.2. It makes sense to have this clearly noted
in the ietf-ancp-protocol draft. I suggest on adding the following text to the ancp protocol draft to provide a clear reasoning and
for the uplift and move us forward:

Prior to initiation of this work, existing ANCP deployments used an ANCP Protocol Version/Sub-Version 3.1. which differs in the
TLV's from this RFC standards track version. Therefore RFC compliant versions MAY choose to work with such pre-RFC peers (NAS and
DSLAM). 

A NAS with ANCP protocol 3.2 MAY support 3.1 and 3.2 DSLAMs. The ancp protocol Version/Sub-Version is set on a per peer basis and is
synchronized/negotiated by the GSMPv3 Adjacency protocol as noted in section 5.3. to agree on the protocol version to use. 

Alan

  _____  

Hi all,

regards
Peter Hamacher

E-Mail:  <mailto:[email-masked]> [email-masked]

Erleben, was verbindet.

  _____  

Hi Peter,

cheers,
Hongyu

  _____  

Hi Woj,

 

 

 
 
cheers,
Peter

  _____  

Hi Peter,

 
Cheers,
Woj.

  _____  

Hi Woj,

 

 
 
thanks,
Peter

  _____  

 
 
-Woj.

  _____  

 

  _____  

 
-Woj.

  _____  

 
Alan

  _____  

-Sanjay

  _____  

Cheers Woj

Alan

  _____  

-Woj.

  _____  

Hi Woj et.al

BR

Alan K

  _____  

Hi All, 

Regards, 
Woj.

---

From: "Alan Kavanagh" <[email-masked]>
Date: Wed, 12 Aug 2009 17:28:55 -0400

Hi Robert
 
We are prety mush saying the same here on this. I would agree on having this outlined in an appendix though ill leave that to Sanjay et.al editors to decide where best to fit such text.
 
My reference to the negotiation protocol is from RFC3292 in section 11.1 (as you also note) which covers the 8-bit Version number of which we now use the full 8-bits for the Version+Sub_version and i see nothing preventing us from using this, though i agree with you that RFC3292 does not cover the sub-version number, but that's something we can modify to support the sub-vers field. 
 
The MAY is always set in uppercase in the RFC. 
 
How about:
 
Prior to completion of this RFC, several pre-RFC versions of the protocol were documented, implemented and deployed in Service Providers Access Network which used an ANCP protocol Version/Sub-Version set to 3.1.
 
A NAS implementing the NAS protocol defined in this RFC, may on a per peer basis, use the Version and Sub-Version fields to detect a pre RFC implementation of the ANCP protocol and choose to work with such pre-RFC peers (NAS and DSLAM).
 
Also, as Peter and Sanjay have noted on previous emails on this thread it should be captured in the draft (small paragraph) on how to handle adjacency connections when a RFC-standards compliant ANCP node (3.2) receives an adjacency connection request from a version/sub-version 3.1 ANCP node? 
 
Alan

Sent: August 10, 2009 4:04 PM

Alan,

A lot would depend on where in the document you wished to place any such note. As Woj pointed out in an earlier email, anything in a normative section would most likely not get past the editors.
 
Perhaps an appendix "
 
I'd be reluctant to cover how to negotiate the version.  Your reference to section 5.3 refers to capabilities negotiation not  version negotiation which is covered in  section 11.1 of 3292  where the version negotiation is discussed, note however that this refers to a single version field not the version/sub version field as used in ANCP. Once you get into mentioning the version  negotiation then one would have to cover how one tell the difference between  versions of the versions i.e. between these versions using Version 3.1  draft-wadwha- vs draft-ietf-ancp-....  .

Hence it would perhaps be better to  omit anything about how to do any version negotiation. say that the RFC compliant version may use the version/subversion field to detect a pre-standard implementation and that this maybe done on a per peer basis such that a given NAS may support both Standards compliant  3.2  and pre-standard
 
How about.

 

 
Cheers
 
Rob

	Hi All

	Alan

	Hi all,

	regards
	Peter Hamacher

	
	Erleben, was verbindet.

	Hi Peter,

	
	cheers,
	Hongyu

		Hi Woj,

		 

		 

		 
		 
		cheers,
		Peter

			Hi Peter,

			 
			Cheers,
			Woj.

				Hi Woj,

				 

				 
				 
				thanks,
				Peter

					 
					 
					-Woj.

					 

					 
					-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, 12 Aug 2009 18:43:11 -0400

How about an Informational RFC after the base protocol RFC comes out, describing 
  the negotiation process?

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

---

From: Robert Rennison <[email-masked]>
Date: Mon, 10 Aug 2009 16:03:44 -0400

Alan,

Perhaps an appendix "

How about.

Cheers

Rob

Hi All

Alan

Hi all,

regards
Peter Hamacher

Deutsche Telekom Netzproduktion GmbH
Zentrum Technik Einführung
Peter Hamacher
Heinrich-Hertz-Straße 3-7, 64295 Darmstadt
+49 6151 628 2864 (Tel.)
+49 521 92100494 (Fax)
E-Mail: [email-masked]<mailto:[email-masked]>
http://www.telekom.com<http://www.telekom.com/>

Erleben, was verbindet.

Hi Peter,

cheers,
Hongyu

Hi Woj,

cheers,
Peter

Hi Peter,

Cheers,
Woj.

Hi Woj,

thanks,
Peter

-Woj.

-Woj.

Alan

-Sanjay

Cheers Woj

Alan

-Woj.

BR
Alan K

Hi All,

Regards,
Woj.

---

From: <[email-masked]>
Date: Thu, 27 Aug 2009 16:00:21 +0200

All,
 
All exchanged arguments are valid.
 
I think a protocol draft describes protocol issues, values, TLV, etc. and not network element mechanisms. 
The challenge now would be to cover notes pointing out how to code pre version and RFC version - that was agreed last meeting.
 
But what's missing in that game is a short description that both peers (BRAS & AN) need to identify which SW version to choose based on sub version value. 
A mechnism in detail for detection and automatic SW load depending on sub version is neccessary.
 
I'm not sure if that is in scope of a protocol draft or if it should be described seperately. But keeping the time line of protocol draft and avoiding delaying ANCP work it may be desirable to identify sections in protocol draft where notes are useful to detail that issue without changing sections and order of the document.  
 
>From my understanding three sections are concerned. I propose adding the notes at that sections. 
 
Please see below the identified sections and added notes taken based on protocol draft 05 for discussion:
 
Regards
Thomas
 ---------------------------------------------------------------------------------
 
Chapter 2 Introduction / page 4:

...

Not all the fields in relevant GSMP messages are used by ANCP.  This draft indicates the value that ANCP should set for the fields in these GSMP messages.

[T.H.:] Note: Implementations which use GSMP and ANCP conventions before RFC publication must use sub-version 1.

                      RFC based implementations must use sub-version 2. For details see chapter 5.

...

------------------------------------------------------------------------------------ 

Chapter 5. Access Node Control Protocol (ANCP) / page 15

...

The 8-bit version field in the base GSMPv3 message header is split

   into two 4 bit fields for carrying the version and a sub-version of

   the GSMP protocol.  ANCP uses version 3 and sub-version 1 of the GSMP

   protocol.  An ANCP implementation SHOULD always set the version field 

   to 3, and the sub-version field to 1.  The Result field in the

   message header has been modified to be 4 bits long, and the Code

   field to be 12 bits long.

   Version:

        The version number of the GSMP protocol being used in this

        session.  ANCP uses version 3.

   Sub-Version:

        The sub-version number of the GSMP protocol being used in this

        session.  ANCP must use sub-version 2 of the GSMP protocol. [T.H]:Pre RFC 
         implemtations must use sub-version 1.

---------------------------------------------------------------------
 
Chapter 5.1.  ANCP/TCP connection establishment / Page 19:
 
...
 
NAS listens for incoming connections from the access nodes.  Port
   6068 is used for TCP connection.  Adjacency protocol messages, which
   are used to synchronize the NAS and access-nodes and maintain
   handshakes, are sent after the TCP connection is established.  ANCP
   messages other than adjacency protocol messages may be sent only
   after the adjacency protocol has achieved synchronization.
 
[T.H.]:Note: NAS must detect per peer the sub version and must load and synchronize with appropriate protocol implementation.  

...

  _____  

Von: [email-masked] [mailto:[email-masked]] Im Auftrag von Robert Rennison
Gesendet: Montag, 10. August 2009 22:04
An: Alan Kavanagh; Hamacher, Peter; [email-masked]; PeterArberg; [email-masked]; [email-masked]; [email-masked]
Cc: Haag, Thomas; Witschurke, Birgit
Betreff: Re: [ANCP] ANCP Protocol Versioning

Alan,

 
Perhaps an appendix "

 
How about.

 

 
Cheers
 
Rob

  _____  

Hi All

Alan

  _____  

Hi all,

regards
Peter Hamacher

Erleben, was verbindet.

  _____  

Hi Peter,

cheers,
Hongyu

  _____  

Hi Woj,

 

 

 
 
cheers,
Peter

  _____  

Hi Peter,

 
Cheers,
Woj.

  _____  

Hi Woj,

 

 
 
thanks,
Peter

  _____  

 
 
-Woj.

  _____  

 

  _____  

 
-Woj.

  _____  

 
Alan

  _____  

-Sanjay

  _____  

Cheers Woj

Alan

  _____  

-Woj.

  _____  

Hi Woj et.al

BR

Alan K

  _____  

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: Tom Taylor <[email-masked]>
Date: Thu, 27 Aug 2009 15:21:27 -0400

Comments below, marked with [PTT].

[email-masked] wrote:
> I think a protocol draft describes protocol issues, values, TLV, etc. and not
> network element mechanisms. The challenge now would be to cover notes
> pointing out how to code pre version and RFC version - that was agreed last
> meeting.
> 
> But what's missing in that game is a short description that both peers (BRAS
> & AN) need to identify which SW version to choose based on sub version value.
> I'm not sure if that is in scope of a protocol draft or if it should be
> described seperately. But keeping the time line of protocol draft and
> avoiding delaying ANCP work it may be desirable to identify sections in
> protocol draft where notes are useful to detail that issue without changing
> sections and order of the document.
> 
> Regards Thomas 
> Not all the fields in relevant GSMP messages are used by ANCP.  This draft
> indicates the value that ANCP should set for the fields in these GSMP
> messages.
> 
> 
> 

[PTT] By definition, pre-standard versions do not conform to the standard, so 
this text will have no effect.
> RFC based implementations must use sub-version 2. For details see chapter 5.
[PTT] Same comment as above.
> NAS listens for incoming connections from the access nodes.  Port 6068 is
> used for TCP connection.  Adjacency protocol messages, which are used to
> synchronize the NAS and access-nodes and maintain handshakes, are sent after
> the TCP connection is established.  ANCP messages other than adjacency
> protocol messages may be sent only after the adjacency protocol has achieved
> synchronization.
> 
> [T.H.]:Note: NAS must detect per peer the sub version and must load and
> synchronize with appropriate protocol implementation.
> 
[PTT] I would add "if possible".