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