On Wed, 21 Dec 2011, Stefan Winter wrote:
If both drafts have their own complex encoding, it's double work: everyone needs to write their own parser for their own attribute. As time goes by, there will be more drafts needing to encode some complex information. Consolidation of such complex types into a common format is a good thing IMHO.
IPv6-6rd-Configuration Attribute 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Extended-Type |M| Flag | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Suboptions | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 245, extended-type TBD.
Using Extended-Type means you would have to wait for the extensions draft to be an RFC in order to be assigned an Extended-Type.
That's right. It is the only drawback. If you choose to go the custom-encoding way, you avoid a bit of waiting time at the expense of extra, non-reusable code in every 6rd implementation.
Compromised solution I originally suggested (Currently draft-ietf-softwire-6rd-radius-attrib-04) sought to avoid dependencies on other drafts while at the same time providing maximum compatibility with existing and future systems.
It requires an implementer to write one parser specifically for the 6rd-attribute, with no code re-use for other attributes that will be defined in the future. The code needs to be maintained separately from the a generic extended-attributes parser. That sounds rather short-sighted to me and goes contrary to the claim of "compatibility with future systems".
I'm not sure what "compatibility with existing systems" should mean. Existing systems can't make anything out of the IPv6-6rd-Configuration attribute, because they can't parse the content. All they can do is ignore the attribute. They can do that with an extended-type attribute just as well.
I don't think this is correct. The extensions document describes a *data type* 'TLV'. My suggestion simply leverages this type in the same way IPv4 Address and IPv6 prefix type from existing RFCs are already being leveraged.
If you implement extensions RFC in the future your implementation supports the TLV data type giving you the ability to encode and decode this attribute with configuration dictionaries. The wire format of IPv6-6rd-Configuration was intentionally made to be the same as a TLV.
The compromise allowed someone to *choose* to implement the TLV type generically OR a much less flexible parser capable of handling just this attribute without having to also support extensions.
Some vendors already support the TLV concept as it is necessary for wimax. It is possible to configure the -04 draft today with just configuration in some systems already supporting TLV.
My understanding they were not willing to wait for extensions to move ahead with the 6rd draft. In that light my view was something that looked like a "TLV" was better than the alternative fixed format.
If this constraint is invalid and they are willing to wait allowing 6rd draft to be dependent on extensions I agree it would certainly be the best approach for all concerned.
regards, Peter _______________________________________________ Softwires mailing list [email protected] https://www.ietf.org/mailman/listinfo/softwires
