[ANCP] Depreciation of TLVs ... again

["Wojciech Dec (wdec)" <wdec at cisco.com>]

Hi Folks,
 
the Vancouver meeting saw some renewed discussions regarding TLV
changes. 
For the record I will (once again) provide the reasons why this problem
needs to be addressed (whether through depreciation or other means). The
problem is likely to cause interoperability problems with any new ANCP
implementations.

The options as I see it are (if there are others, lets hear them):

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).
1b. Do not depreciate TLVs, but introduce a "known caveats" in the
appendix of the protocol draft, describing the potential legacy
implementation interoperability problem.
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--

Regards,
Woj.


_______________________________________________
ANCP mailing list
ANCP at ietf.org
https://www1.ietf.org/mailman/listinfo/ancp