Hello Jeff, Thank you for your answer. I would be curious to hearing your view on the possible risks the new un-regulated, vendor controlled, space this draft creates as your document is silent about it.
> As mentioned elsewhere in thread, PENs are easy to get hence suggesting that > managed code pode. I tried to make sure that was clear in the [IANA-PEN] > link, but perhaps there's text I could add to make it more explicit? It can not harm. I was clearly ill-informed. >> Also it changes the way features are coded and would require re-coding once >> the format is stable and or the code is defined and not simply a code change >> which is for me unwise and an overkill. > > I have admittedly not taken a look at your implementation […] I can not see why I would want to implement your draft as a step toward implementing another draft (the end goal) which does not require it at all, unless it is intended to be used like like MultiProtocol as a generic extension mechanism and not only a test feature. The implementation difficulty is not the barrier: I can perfectly see how I could change the class inheritance of ExaBGP while keeping the attribute interface to implement your draft. We need to fix a human problem : laziness, lack of time or information leading to the squatting. In my view, asking over-worked developers / teams to add some complex code to test new features mean will not lead to a behavioural change. All that is required is to give the developer the playground they need to not bother network operation, as the dangers caused by transitive nature of attributes were already fixed with RFC7606. “Public” IANA resource such as IP and ASN have “private” ranges, among other reason, for experimentation. I can not se any harm to extend this principle more widely to help, not the operators this time, but the developers. >> I would rather see a much simpler solution: allocate some code point for >> development and make them iBGP transitive only, (and give operators an >> option to bypass this limit on selected eBGP links if they so wish...) > > And how would you propose to deal with code point allocation for this? For > example, we already have 255 available. A simple code is not enough, but a range would allow multiple features developed in parallel (in one code base), while also allowing possible cross vendor interoperability testing. TBD is a terrible word to read in a draft when you are trying to implement it. TDB is not a valid integer value, and 255 as a single available value is not enough, so it is not used. The wording in draft need to contain the information developers needs to implement the draft as they understand it. I my naive view, every draft could simply cherry pick a code. The numbers of “in-flight documents” is not high, I would expect simple self-policing on list to be enough with a large enough resource pool. Should a clash occur, a new draft can quickly fix the issue. Happy to hear if others have better ideas. But if an operator is willing / care enough to use experimental features in his production network and/or with another operator, I am pretty sure they will have the motivation to make sure to do their due diligence to make sure there is no clashes. Perhaps the solution would be to required a “disabled until explicitly enabled on iBGP” default behaviour for these attribute codes. Optional explicit configuration of the feature eBGP session is something I would expect vendors to add due to customer/user demand :-) Sincerely, Thomas _______________________________________________ GROW mailing list GROW@ietf.org https://www.ietf.org/mailman/listinfo/grow
