[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [ANCP] Depreciation of TLVs ... again
Previously posted versioning strategy accepted by the WG:
--snip--
The conclusion that we reached is that any protocol version or
sub-version change are to be done primarily to address substantial
protocol changes that will render previous versions incompatible - this
is best practice, besides common sense that is used throughout the IETF
community. It will be for the WG group, backed by technical advice when
required, to decide when this stage is actually reached.
In view of our WG's chartered work, such a stage may actually come
towards the end of the protocol specification where we could, for
example decide to use a modified protocol state-machine, protocol
transport, and/or transport port.
The following list is deemed to not qualify as substantial protocol
changes, and thus will not be considered as sufficient ground for
changing/revising the ANCP version, or sub-version number:
i) a new revision of the protocol spec*
ii) a conflicting TLV or sub-TLVs
iii) incompatibilities arising from implementations of pre-RFC drafts.
iv) new negotiable protocol capabilities (eg Bulk message capability)
* Unless the revised draft diverges so far in protocol compatibility
from its origin as to render it incompatible, for example a new protocol
RFC
If and when the WG agrees that substantial changes have been made to the
protocol, a new protocol version will require an IANA version registry
change.
--snip---
The problem in this case is that the known problems stem from pre-RFC
draft implementations, and even if doing a version change, any deployed
"pre ANCP draft" devices would be rendered incompatible unless one
introduced in the "next version draft" clauses about backwards
compatibility to "pre-rfc" implementations - this is an oxymoron.
That said, if the WG is ready to agree and bite the bullet in
versioning-up, that option is also possible, but for the reasons above
(shouldn't have an RFC dictating backward compatibility to a pre-RFC
implementation) not trivial.
-Woj.
> -----Original Message-----
> From: Jakob Heitz [mailto:jheitz at redback.com]
> Sent: 08 January 2008 14:35
> To: ancp at ietf.org
> Subject: Re: [ANCP] Depreciation of TLVs ... again
>
> If a change in a TLV or the addition of a new TLV will cause
> incorrect operation in a receiver that implements a previous
> version of the protocol, then the new version requires a new
> version number.
>
> Then the version negotiation can be used to avoid the
> incorrect operation in case not all peers support the new version.
>
> I do not understand the reluctance to bump version numbers.
> There is enough number space to accommodate the most trivial changes.
>
> Stefaan DE CNODDER wrote:
> >
> > Woj,
> >
> > Let's say that I am against 1a. It also requires that all
> ANs and all
> > NASes are upgraded at the same time which is unlikely.
> >
> > It depends on which node is typically upgraded first. Are
> ISPs first
> > upgrading the NAS or first the AN? I would expect first
> the NAS. If
> > that's true, then it looks to me that it should be like this:
> >
> > If I see correctly "PORT-UP message TLV Type 0x02" changed
> meaning and
> > the original data that was in TLV 0x02 is now in 0x06.
> However, this
> > is an optional TLV and does not look that important, and to avoid
> > interop problems, a NAS should not interprete TLV 0x02 "for some
> > time", except in displaying this information or other
> things that does
> > not break the correct operation of ANCP. This until we are
> sure that
> > there are no implementations that use the old spec. This should be
> > described in an appendix of the draft.
> >
> > subTLV 0x90 is renumbered to 0x91. Here the BRAS should, to avoid
> > interop problems, interprete both 0x90 and 0x91 in the same
> way. If
> > both are there, then only 0x91 should be interpreted. Also this
> > should be described clearly in the appendix.
> >
> > In the future it would be better that the numbering is kept
> as it is.
> > For instance, for TLV 0x02 it should never have been moved
> to 0x06 and
> > then using 0x02 for something else... This could have been
> avoided,
> > but if it cannot be avoided, then it should be described
> explicetely
> > in the appendix.
> >
> > regards,
> > Stefaan
> >
> >
> > Wojciech Dec (wdec) wrote:
> >
> >> Stefaan, are you behind option 1b then?
> >>
> >> The case if currently for :
> >>
> >> PORT-UP message TLV Type 0x02
> >> PORT-UP message TLV 0x04 sub-TLV 0x90
> >>
> >> Both of which I beleive are currenly implemented (based on the
> >> conflicting definition in draft-wadhwa-00).
> >>
> >> BTW. I naturally meant depricate not depreciate ;-)
> >>
> >> -Woj.
> >>
> >>
> >>
> >>> -----Original Message-----
> >>> From: Stefaan DE CNODDER
> >>> [mailto:stefaan.de_cnodder at alcatel-lucent.be] Sent: 07
> January 2008
> >>> 15:07
> >>> To: Wojciech Dec (wdec)
> >>> Cc: ancp at ietf.org
> >>> Subject: Re: [ANCP] Depreciation of TLVs ... again
> >>>
> >>>
> >>>
> >>>
> >>>> 1a. Do not depreciate TLVs, and assume that all
> implementations and
> >>>> users will follow the latest ANCP draft (i.e. assume that
> >>>
> >>> draft-l2cp
> >>>> problems never happened).
> >>>
> >>> You cannot assume that.
> >>>
> >>>
> >>>> 1b. Do not depreciate TLVs, but introduce a "known
> caveats" in the
> >>>> appendix of the protocol draft, describing the potential legacy
> >>>> implementation interoperability problem.
> >>>
> >>> Important changes that may lead to interop issues when
> >>> implementations implement different versions of the same draft
> >>> should be documented properly in the appendix. But this
> should be
> >>> avoided as much as possible... Maybe it should be looked
> at case by case.
> >>> If a number changes of a TLV that is not important, then
> it will not
> >>> harm a lot, but if it happens to important TLVs like the ones
> >>> carrying bandwidth or ACIs, then it should be avoided and if not
> >>> possible to avoid, describe it very well in the appendix.
> >>>
> >>> regards,
> >>> Stefaan
> >>>
> >>>
> >>>
> >>>> 2. Depreciate TLVs.
> >>>>
> >>>> Now, given that option 2 appears to have just recently been
> >>>
> >>> presented
> >>>> with a reasonable argument against it (see Vancouver
> >>>
> >>> minutes below), I
> >>>> call for the WG to decide on 1a or 1b.
> >>>>
> >>>> Some background:
> >>>>
> >>>> The problem was introduced in edits made between pre-ANCP
> >>>
> >>> WG drafts to
> >>>> draft-wadhwa-gsmp-l2control-configuration-00.
> >>>> Version 00 of this draft dated August 2, 2005 saw the
> >>>
> >>> PORT-UP message
> >>>> TLV 0x02 assigned to
> >>>
> >>> "Access-Aggregation-Circuit-ID-Binary". The next
> >>>> version 01, dated September 2006, saw the same TLV assigned to
> >>>> "Access-Loop-Remote-Id".
> >>>> A similar story applies to PORT-UP TLV 0x04 sub-TLV
> 0x90, which saw
> >>>> it's meaning changed between drafts. The ANCP protocol draft is
> >>>> derived from the 01 version.
> >>>>
> >>>> It so happens however that most known implementations are
> >>>
> >>> based on the
> >>>> 00 draft, which presents an interoperability problem to
> anyone who
> >>>> implemented the 00 definition and those that implement the
> >>>
> >>> latest ANCP
> >>>> draft. Hacks aside, a long term fix needs to be devised.
> >>>> NOTE: There is no known way to distinguish l2cp draft 00,
> >>>
> >>> 01 or ANCP
> >>>> draft speakers other than trough hacks, which current 00
> >>>> implementations are known to have adopted as a "workaround"
> >>>
> >>> to *ONE* of the problem.
> >>>
> >>>> Now the original proposal of a solution was drafted in
> >>>
> >>>
> http://www1.ietf.org/mail-archive/web/ancp/current/msg00152.html and
> >>>> the WG provided no objections. Furthermore the topic was also
> >>>> discussed during IETF 69 back in March 2007 (minutes here:
> >>>> http://tools.ietf.org/wg/ancp/minutes?item=minutes68.html).
> >>>
> >>> Again no
> >>>> objections were raised by any of the WG participants.
> >>>> Hence the decision to *depreciate* conflicting TLVs was
> previously
> >>>> made by the WG (and claims of this being otherwise are
> removed from
> >>>> the truth).
> >>>>
> >>>>
> >>>> ---snip---
> >>>>
> >>>> ANCP Protocol Draft - Sanjay Wadhwa (swadhwa at juniper.net)
> >>>> http://tools.ietf.org/html/draft-ietf-ancp-protocol-01
> >>>> <http://tools.ietf.org/html/draft-ietf-ancp-protocol-01>
> >>>> Discuss protocol draft updates and ANCP graceful restart.
> >>>> ----------------------------------------------------------
> >>>> consistency with framework
> >>>> new section 2.1 on terminology
> >>>> net data rate used
> >>>> new multipair bonding text
> >>>> text for topology discovery extensions 5.4.2 clarified
> >>>
> >>> message format
> >>>> in line configuration extension, section 5.4.3 concern over tlv
> >>>> changes, diverges from tr-101 and rfc 4679 in TLV#.
> >>>> Common notion is for BRAS to pass TLV transparently into Radius.
> >>>> Changes held back. Doesn't see issue as colliding values
> have been
> >>>> changed previously.
> >>>>
> >>>> access loop remote id and sub tlv access loop encapsulation
> >>>> suggest not deprecate these tlvs, keep them alive
> Peter, why
> >>>> did Woj want this deprecated, agrees that
> >>>
> >>> these shouldn't
> >>>> be deprecated.
> >>>> Sanjay, reason was to depreciate to avoid overlap, but
> >>>
> >>> ROI is small
> >>>> in this case.
> >>>> graceful restart draft updated, support for
> multicast use cased
> >>>> agreed upon by the WG.
> >>>> Matthew, should graceful restart be a separate draft
> >>>
> >>> going forward,
> >>>> Sanjay agreed
> >>>> Matthew, graceful restart not on charter, need to add
> >>>
> >>> to milestones
> >>>
> >>>> ---snip--
>
>
> _______________________________________________
> ANCP mailing list
> ANCP at ietf.org
> https://www1.ietf.org/mailman/listinfo/ancp
>
_______________________________________________
ANCP mailing list
ANCP at ietf.org
https://www1.ietf.org/mailman/listinfo/ancp