[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


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

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