[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [ANCP] ANCP Protocol Versioning
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:tom.taylor at rogers.com]
Sent: July 29, 2009 3:38 PM
To: Alan Kavanagh
Cc: ancp at ietf.org
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?
> (simple yes or no).
[PTT] Yes
>
> 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).
[PTT] 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:wdec at cisco.com]
> Sent: July 29, 2009 3:22 PM
> 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
> <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.
> 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