Robert Raszuk <[email protected]> writes:
Les, I don't think this is noise. Your examples are missing key operational consideration .. Link attribute applicable to ANY application may be advertised well ahead of enabling such application in a network. So requesting operator to always advertise tuple of app + attr is not looking forward and makes unnecessary operational burden.
[as wg-member] Hi Robert, Originally this was the argument that sort of put wind in the sails (for me) for this any bit, but some more thinking about how things would really work changed my mind. In order for some new feature, let's call it Wizbang, to take advantage of existing any bit marked attributes, the operator still has to deploy new software that contains the new Wizbang feature, right? So the addition of a new Wizbang bit pretty much comes free for the operator. So, this draft really is just about making the encoding a bit more efficient. I think if we were defining a new encoding, having this functionality makes sense, but we aren't defining a new encoding. The proposal is to change an existing published encoding, and the bar has to be higher for that I think. Thanks, Chris. [as wg member]
Thx. R.
_______________________________________________ Lsr mailing list [email protected] https://www.ietf.org/mailman/listinfo/lsr
