Both are a bit mushy. The ext-comm may come from an ebgp neighbor. I want to make sure that the not-found state is not interpreted as a locally achieved validation state. If the local state is not-found, then the received ext-comm should count.
"Similarly on the receiving IBGP speakers, the validation state of an IBGP route SHOULD be derived directly from the last octet of the extended community, if present. If a receiving router is performing RPKI validation locally and has determined a state other than not-found, then the state determined by the extended community SHOULD NOT be used." Thanks, Jakob. > -----Original Message----- > From: Randy Bush [mailto:ra...@psg.com] > Sent: Friday, March 03, 2017 8:05 PM > To: Chris Morrow <morr...@ops-netman.net> > Cc: Montgomery, Douglas (Fed) <do...@nist.gov>; Alvaro Retana (aretana) > <aret...@cisco.com>; Jakob Heitz (jheitz) > <jhe...@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) > > > Section 2, 3rd paragraph: > > > > "Similarly on the receiving IBGP speakers, the validation > > state of an IBGP route SHOULD be derived directly from the last octet > > of the extended community, if present." > > > > to: > > "Similarly on the receiving IBGP speakers, the validation state of > > an IBGP route SHOULD be derived directly from the last octet of the > > extended community, if present. A receiving router should use > > locally achieved validation state before trusting an IBGP neighbors > > state information." > > sure. or, tersified, > > "Similarly, a receiving IBGP 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
