Jacob, Ebgp Peers are out of scope. Imho, implementations are free to implement receipt and processing of a community from a ebgp peer as a knob. The standard doesn't have to accommodate knobs.
Regards, Keyur Sent from my iPhone > On Mar 3, 2017, at 8:40 PM, Jakob Heitz (jheitz) <[email protected]> wrote: > > However it SHOULD be possible to > configure an implementation to send or accept the community when > warranted. An example of a case where the community would reasonably > be received from, or sent to, an EBGP peer is when two adjacent ASes > are under control of the same administration. A second example is > documented in [I-D.ietf-sidr-route-server-rpki-light]. > > Thanks, > Jakob. > >> -----Original Message----- >> From: Chris Morrow [mailto:[email protected]] >> Sent: Friday, March 03, 2017 8:38 PM >> To: Randy Bush <[email protected]> >> Cc: Jakob Heitz (jheitz) <[email protected]>; Chris Morrow >> <[email protected]>; Montgomery, Douglas (Fed) >> <[email protected]>; Alvaro Retana (aretana) <[email protected]>; >> [email protected]; >> [email protected]; [email protected]; [email protected] >> Subject: Re: [sidr] Protocol Action: 'BGP Prefix Origin Validation State >> Extended Community' to Proposed Standard >> (draft-ietf-sidr-origin-validation-signaling-11.txt) >> >> At Sat, 04 Mar 2017 13:36:05 +0900, >> Randy Bush <[email protected]> wrote: >>> >>>> The ext-comm may come from an ebgp neighbor. >> >> ebgp neighbor? the text talks about ibgp, and about explicitly ignoring ebgp >> senders of this community (by default). >> >> right? >> >>> >>> ok. saves a character. my kind of change :) >>> >>> "Similarly, a receiving BGP speaker, in the absence of validation >>> state set based on local data, SHOULD derive a validations state from >>> the last octet of the extended community, if present." >>> >>> randy _______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
