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) <jhe...@cisco.com> 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:morr...@ops-netman.net] >> Sent: Friday, March 03, 2017 8:38 PM >> To: Randy Bush <ra...@psg.com> >> Cc: Jakob Heitz (jheitz) <jhe...@cisco.com>; Chris Morrow >> <morr...@ops-netman.net>; Montgomery, Douglas (Fed) >> <do...@nist.gov>; Alvaro Retana (aretana) <aret...@cisco.com>; >> draft-ietf-sidr-origin-validation-signal...@ietf.org; >> sa...@tislabs.com; sidr-cha...@ietf.org; sidr@ietf.org >> 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 <ra...@psg.com> 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 sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr
