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
