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
________________________________
From: Robert Rennison [mailto:Robert.Rennison at ecitele.com]
Sent: August 10, 2009 4:04 PM
To: Alan Kavanagh; Peter.Hamacher at telekom.de; lihy at huawei.com; Peter Arberg; wdec at cisco.com; swadhwa at juniper.net; ancp at ietf.org
Cc: HaagT at telekom.de; B.Witschurke at telekom.de
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: ancp-bounces at ietf.org [mailto:ancp-bounces at ietf.org] On Behalf Of Alan Kavanagh
Sent: Monday, August 10, 2009 11:46 AM
To: Peter.Hamacher at telekom.de; lihy at huawei.com; Peter Arberg; wdec at cisco.com; swadhwa at juniper.net; ancp at ietf.org
Cc: HaagT at telekom.de; B.Witschurke at telekom.de
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
________________________________
From: Peter.Hamacher at telekom.de [mailto:Peter.Hamacher at telekom.de]
Sent: August 10, 2009 11:35 AM
To: lihy at huawei.com; Peter Arberg; wdec at cisco.com; Alan Kavanagh; swadhwa at juniper.net; ancp at ietf.org
Cc: HaagT at telekom.de; B.Witschurke at telekom.de
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: Peter.Hamacher at telekom.de <mailto:Peter.Hamacher at telekom.de>
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: ancp-bounces at ietf.org [mailto:ancp-bounces at ietf.org] Im Auftrag von Hongyu Li
Gesendet: Montag, 10. August 2009 08:52
An: 'Peter Arberg'; 'Wojciech Dec (wdec)'; 'Alan Kavanagh'; 'Sanjay Wadhwa'; ancp at ietf.org
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
________________________________
From: ancp-bounces at ietf.org [mailto:ancp-bounces at ietf.org] On Behalf Of Peter Arberg
Sent: Thursday, July 30, 2009 8:38 AM
To: Wojciech Dec (wdec); Alan Kavanagh; Sanjay Wadhwa; ancp at ietf.org
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:wdec at cisco.com]
Sent: 29. juli 2009 16:41
To: Peter Arberg; Alan Kavanagh; Sanjay Wadhwa; ancp at ietf.org
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:parberg at redback.com]
Sent: 29 July 2009 21:55
To: Wojciech Dec (wdec); Alan Kavanagh; Sanjay Wadhwa; ancp at ietf.org
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: ancp-bounces at ietf.org [mailto:ancp-bounces at ietf.org] On Behalf Of Wojciech Dec (wdec)
Sent: 29. juli 2009 12:22
To: Alan Kavanagh; Sanjay Wadhwa; ancp at ietf.org
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:alan.kavanagh at ericsson.com]
Sent: 29 July 2009 19:11
To: Wojciech Dec (wdec); Sanjay Wadhwa; ancp at ietf.org
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:wdec at cisco.com]
Sent: July 29, 2009 10:01 AM
To: Alan Kavanagh; Sanjay Wadhwa; ancp at ietf.org
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: ancp-bounces at ietf.org [mailto:ancp-bounces at ietf.org] On Behalf Of Alan Kavanagh
Sent: 29 July 2009 15:51
To: Sanjay Wadhwa; Wojciech Dec (wdec); ancp at ietf.org
Subject: Re: [ANCP] ANCP Protocol Versioning
Exactly, hence we should ahve this explicitly noted in the draft.
Alan
________________________________
From: Sanjay Wadhwa [mailto:swadhwa at juniper.net]
Sent: July 29, 2009 9:48 AM
To: Alan Kavanagh; Wojciech Dec (wdec); ancp at ietf.org
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: ancp-bounces at ietf.org [mailto:ancp-bounces at ietf.org] On Behalf Of Alan Kavanagh
Sent: Wednesday, July 29, 2009 9:30 AM
To: Wojciech Dec (wdec); ancp at ietf.org
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:wdec at cisco.com]
Sent: July 29, 2009 3:33 AM
To: Alan Kavanagh; ancp at ietf.org
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:alan.kavanagh at ericsson.com]
Sent: 28 July 2009 19:28
To: Wojciech Dec (wdec); ancp at ietf.org
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: ancp-bounces at ietf.org [mailto:ancp-bounces at ietf.org] On Behalf Of Wojciech Dec (wdec)
Sent: July 28, 2009 5:30 AM
To: ancp at ietf.org
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.
------------------------------------------------------------------------
_______________________________________________
ANCP mailing list
ANCP at ietf.org
https://www.ietf.org/mailman/listinfo/ancp