Subject: Re: [sidr] Protocol Action: 'BGP Prefix Origin Validation State Extended Community' to Proposed Standard (draft-ietf-sidr-origin-validation-signaling-11.txt)
From: "Jakob Heitz (jheitz)" <[email-masked]>
To: Randy Bush <[email-masked]>, Chris Morrow <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Sat, 4 Mar 2017 04:28:46 +0000
List-Id: Secure Interdomain Routing <sidr.ietf.org>

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:[email-masked]]
> Sent: Friday, March 03, 2017 8:05 PM
> To: Chris Morrow <[email-masked]>
> Cc: Montgomery, Douglas (Fed) <[email-masked]>; Alvaro Retana (aretana) <[email-masked]>; Jakob Heitz (jheitz)
> <[email-masked]>; [email-masked]; [email-masked]; [email-masked];
> [email-masked]
> 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