On Tue, Nov 01, 2016 at 11:07:19AM -0400, Jeffrey Haas wrote: > On Sun, Oct 30, 2016 at 05:10:01PM +0100, Job Snijders wrote: > > I'd like to propose a different strategy and describe some background. > > Both of you mention per-peer flags or new per-route state flags, which > > in essence are updates to rfc4271, this feels like too heavy of a > > hammer. > > > > I'd prefer to make the document compatible with existing deployments of > > software which is already compliant with the spirit of this document. > > > > OLD: > > Software MUST mark any routes from an EBGP peer as 'invalid' in the > > Adj-RIB-In, if no import policy was configured. > > > > NEW: > > Software MUST consider any routes from an EBGP peer as invalid, if > > no import policy was configured. > > > > NEW2: > > "Software MUST discard any routes from an EBGP peer, if no import > > policy was configured." > > I rather object to NEW2 and, if included, withdraw any support of this > draft. > > A fundamental issue with this behavior is that it dumps routes that > would have to be recovered via expensive refresh.
Am I correct to understand that the word 'discard' has very specific meaning in this context? Does "discard" mean "forbidden to store in memory"? Sriram, I believe you were the first to raise a concern about the "OLD" text, do you have a preference for "NEW2" or strongly object to "NEW"? If the latter, can you help bridge the gap between intended meaning implementation consequences? Or perhaps: NEW3: "Software MUST ignore any routes from an EBGP peer, if no import policy was configured." ? > FWIW, I still haven't evaluated our own software under the prior > version of the draft, but think it's a generally good idea. I look forward to your evaluation! Kind regards, Job _______________________________________________ GROW mailing list [email protected] https://www.ietf.org/mailman/listinfo/grow
