[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [ANCP] Depreciation of TLVs ... again
Hi Michael, All
thanks for you feedback and the additional caveat. It seems that 1b is the preferred way forward, so unless someone objects between now and the end of January, it's settled. A small remark about this "known caveats" section; it should be clearly stated that it is not normative, and not required to implement ANCP on either the NAS or the AN.
Regards,
Woj.
> -----Original Message-----
> From: Busser, M [mailto:Michael.Busser at t-systems.com]
> Sent: 16 January 2008 08:32
> To: stefaan.de_cnodder at alcatel-lucent.be; Wojciech Dec (wdec)
> Cc: ancp at ietf.org
> Subject: AW: [ANCP] Depreciation of TLVs ... again
>
> All.
>
> I fully agree with Stefaan.
> We can not assume 1a, so i am aganinst it.
>
> I also think, that TLV Type 0x02 is not that important. It is
> also an optional TLV.
> So ignoring it for a while at the NAS as Stefaan suggests is
> an acceptable solution for me.
> It it also not used by RAM or OAM at the moment (as far as I
> know), so we shouldn't have problems with that.
>
> With subTLV 0x90 renumbered to 0x91, we can proceed as follows:
>
> Lets assume, we have a AN running with an "old" version of
> the draft (e.g. Dec. 2005).
> Those systems will never send a subTLV 0x91. If the NAS
> receives a subTLV 0x90, it should interpret this subTLV as DSL-Type.
>
> If we have a AN running a later version of the draft, the NAS
> will at least receive a subTLV 0x91 because this is
> mandatory. It may also receive a subTLV 0x90, wich is optional.
> In this case, the NAS should interpret 0x90 as
> Access-Loop-Encapsulation and 0x91 as DSL-Type.
>
> The only thing, we have to take care of is that the NAS have
> to be updated to this behaviour first.
> After that, the AN vendors can change their implementations
> whenever the want.
>
> I also agree with Stefaan, that we schould describe this in
> detail in an appendix.
> The other changes we made, concerns the length of some
> parameters. This can be solved by the AN vendors, as long as
> we have different implementations at the NAS side in that
> specific detail.
> This is actually already the case as far as i know.
>
> I think, 1b is the way to go.
>
>
> Some other useful information for a "known caveats" appendix:
>
> OAM-Loopback-Test-Parameter=0x07
> The length of the parameter has changed from 8 to 4 bytes.
> Depending on the implementation at the NAS, a AN can receive
> the OAM-Loopback-Test-Parameter with length=8 as well as with
> length=4 byte.
> AN vendors should take this into account.
>
>
> The other way of course is to have a kind of a version number
> wich is our preference.
> But even if the group decide to have an ANCP version number,
> we need an agreement, how to proceed from the actually
> running implementations.
>
> Best Regards
>
> Michael Busser
>
> T-Systems Enterprise Services GmbH
> Systems Integration
>
>
>
>
> -----Ursprüngliche Nachricht-----
> Von: Stefaan DE CNODDER [mailto:stefaan.de_cnodder at alcatel-lucent.be]
> Gesendet: Montag, 7. Januar 2008 15:50
> An: Wojciech Dec (wdec)
> Cc: ancp at ietf.org
> Betreff: 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
>
>
> _______________________________________________
> 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