RE: [ANCP] Depreciation of TLVs ... again

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

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--
> > 
> > Regards,
> > Woj.
> > 
> > 
> > _______________________________________________
> > 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