>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?
No, I do not strongly object to "NEW". I think myself and Brian were concerned if the same bit (or bits) would be used for marking updates no-policy-invalid as for origin-validation-invalid. May be that is why you dropped 'invalid' and used 'discard' instead (in NEW2). I am OK with what Jeff is suggesting now: >>If you're just looking for "you can't use this without import policy >>specified", you want something along the lines of: >>In the absence of configured import policy, BGP routes are ineligible for >>route selection. (RFC 4271, section 9.1.1.) >>-- Jeff Seems OK to leave the details to the implementers about how to tag/notate/mark the updates. Sriram -----Original Message----- From: Job Snijders [mailto:[email protected]] Sent: Tuesday, November 01, 2016 12:24 PM To: Jeffrey Haas <[email protected]> Cc: Sriram, Kotikalapudi (Fed) <[email protected]>; [email protected] Subject: Re: [GROW] Working Group Adoption Call: draft-mauch-bgp-reject 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
