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