Jeff, As I am not pushing for an alternate draft, would you agree that there is no need to test feature on EBGP links and that this attribute should therefore be limited to iBGP to protect the innocents ? EBGP testing should be done using the right final encoding using the proper attribute code.
Sincerely, Thomas > On 21 Nov 2016, at 14:40, Jeffrey Haas <[email protected]> wrote: > > 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
