|
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
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,
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
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.
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.
Exactly, hence we should ahve this
explicitly noted in the draft.
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.
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)
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.
|