Thomas, On Thu, Nov 17, 2016 at 09:40:00AM +0000, Thomas Mangin wrote: > 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.
This was commented somewhat further in IDR and also during my code points presentation in IDR at IETF 97 (suggested reading). There is somewhat of a need for fully private space. We're starting to see this very strongly in data center contexts wherein BGP is used as a transport and there's significant danger of contamination of fully internal features leaking into the public Internet. But as I mentioned in the IDR thread, this was not my initial motivation for the draft. It does, however, serve as a fine starting point for that discussion. > 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. As noted in my code point presentation, laziness is *not* the issue. As you note in your own response, developers need something they can use when TBD is specified. > 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. Private is an excellent example. If a particular path attribute code space was marked private, this doesn't stop the issue of collisions. If your implementation uses 240 and another uses 240, you'll run into the same treat-as-withdraw encoding problems we've seen with other forms of squatting. Essentially, private doesn't help you. Neither does a playground. The fundamental issue, as noted in the code point presentation, is that BGP path attributes have a large "blast radius". It's very difficult to keep them localized in their current form and thus there's a need to be very strict about what is used globally. > 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. Such "cherry picking" is essentially just squatting. It's also antisocial in global BGP. If someone has code deployed in a transit scenario wherein they're squatting on something that was intended to be globally deployed, the code point is outright toxic now: you can't safely use it for either feature. This is why there's 4 code points going through IANA deprecation in IDR right now. Don't make this 5+. > 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. They don't have the tools. > Perhaps the solution would be to required a “disabled until explicitly > enabled on iBGP” default behaviour for these attribute codes. iBGP doesn't make this safe. > Optional explicit configuration of the feature eBGP session is something I > would expect vendors to add due to customer/user demand :-) I do comment on this even in the experimental context in my draft. However, this doesn't work safely in a squatting context. -- Jeff _______________________________________________ GROW mailing list [email protected] https://www.ietf.org/mailman/listinfo/grow
