Henk Uijterwaal wrote:
Larry,
There was considerable discussion during the development of the RPSLng spec (RFC4012) concerning modifying the syntax for existing attributes. The consensus was that this approach should not be taken and that new attributes should be created wherever an IPv6 address could appear so as not to break existing tools. draft-uijterwaal-rpsl-4bytesas-ext-00.txt appears to have abandoned this approach.
That is correct. I looked at the problem and creating new attributes for ASN32 would cause the number of attributes to expand as N^2. In other words, for each kind of attribute, there would be a version for IPv4-ASN16, IPv6-ASN16, IPv4-ASN32 and IPv6-ASN32. If something else is changed in the future, this will result in 8 versions of essentially the same attribute. This does not look very attractive to me.
Also, contrary to IPv4 and IPv6, we are very likely to have a mixed ASN16 and ASN32 world "forever". In fact, the ASN32 standard is specifically designed with this in mind, and the two worlds can live happily together.
So, any tool will have to be upgraded sooner or later, the only question is when and how.
In both cases (change existing attributes or create new ones), people will have to upgrade when they move into the ASN32 world. The difference is in the code change. In my draft, the tools will have to recognize 2 versions for an AS. Changing attributes means that tools will have to check if the ASN16 or ASN32 version is there, then parse that to get the information. In the end, this doesn't look like a big difference to me.
The big difference is that existing tools can potentially break if the syntax is changed in existing attributes. I agree that adding new attributes is undesirable, but I see a couple alternatives. The first would be to use straight integer notation for the AS numbers instead of the "." notations. This is actually compatible with the RFC 2622 flex macro for AS numbers (as Mark Prior noted) and would likely be compatible with existing tools. INT [[:digit:]]+ ASNO AS{INT} The presentation and submission layers could optionally support the "." notation. Note that RFC3779 uses a straight integer for 32-bit ASN's (as opposed to the dotted character bitstrings for IPv4 numbers), so this is not unprecedented. The other option would be to update RFC4012 (RPSLngbis?) as it is relatively fresh and the tools to process mp- attributes are few. -Larry