|
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
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
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
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
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.
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
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.
|