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
