Re: [sidr] Protocol Action: 'BGP Prefix Origin Validation State Extended Community' to Proposed Standard (draft-ietf-sidr-origin-validation-signaling-11.txt)

I assume that the ext-comm passes policy.

Thanks,
Jakob.

> -----Original Message-----
> From: Keyur Patel [mailto:keyur@arrcus.com]
> Sent: Friday, March 03, 2017 12:43 PM
> To: Jakob Heitz (jheitz) <jheitz@cisco.com>; The IESG <iesg-secretary@ietf.org>; IETF-Announce <ietf-
> announce@ietf.org>
> Cc: draft-ietf-sidr-origin-validation-signaling@ietf.org; sidr@ietf.org; sidr-chairs@ietf.org; The IESG
> <iesg@ietf.org>; sandy@tislabs.com; rfc-editor@rfc-editor.org
> Subject: Re: [sidr] Protocol Action: 'BGP Prefix Origin Validation State Extended Community' to Proposed Standard
> (draft-ietf-sidr-origin-validation-signaling-11.txt)
> 
> Jacob,
> 
> Apologies for the delayed response. Comments #Keyur
> 
> On 2/23/17, 1:26 PM, "Jakob Heitz (jheitz)" <jheitz@cisco.com> wrote:
> 
>     What happens if a BGP speaker validates a route in its own RPKI database
>     and finds it to be either Valid or Invalid (not NotFound) and also receives
>     the extended community that specifies a different validation state?
> 
> #Keyur: That pretty much means that ibgp speakers has out of sync rpki data. This could very well happen if the ibgp
> speakers have different refresh intervals for polling the rpki data (or some error has occurred that has resulted
> into a stale state).
> 
>     I don't see that condition covered in the draft.
>     I would say to ignore the extended community.
> 
> #Keyur: I am not sure if we need to add any text? Extended community maps to a policy on a n inbound side. Policy
> would dictate how you would want to use the community. Implementations could always log any conflicting rpki state
> they encounter?
> 
> Regards,
> Keyur
> 
>     Thanks,
>     Jakob.
> 
>     > -----Original Message-----
>     > From: sidr [mailto:sidr-bounces@ietf.org] On Behalf Of The IESG
>     > Sent: Wednesday, January 11, 2017 7:25 AM
>     > To: IETF-Announce <ietf-announce@ietf.org>
>     > Cc: draft-ietf-sidr-origin-validation-signaling@ietf.org; sidr@ietf.org; sidr-chairs@ietf.org; The IESG
>     > <iesg@ietf.org>; sandy@tislabs.com; rfc-editor@rfc-editor.org
>     > Subject: [sidr] Protocol Action: 'BGP Prefix Origin Validation State Extended Community' to Proposed Standard
>     > (draft-ietf-sidr-origin-validation-signaling-11.txt)
>     >
>     > The IESG has approved the following document:
>     > - 'BGP Prefix Origin Validation State Extended Community'
>     >   (draft-ietf-sidr-origin-validation-signaling-11.txt) as Proposed
>     > Standard
>     >
>     > This document is the product of the Secure Inter-Domain Routing Working
>     > Group.
>     >
>     > The IESG contact persons are Alvaro Retana, Alia Atlas and Deborah
>     > Brungard.
>     >
>     > A URL of this Internet Draft is:
>     > https://datatracker.ietf.org/doc/draft-ietf-sidr-origin-validation-signaling/
>     >
>     >
>     >
>     >
>     >
>     > Technical Summary
>     >
>     >    This document defines a new BGP opaque extended community to carry
>     >    the origination AS validation state inside an autonomous system.
>     >    IBGP speakers that receive this validation state can configure local
>     >    policies allowing it to influence their decision process.
>     >
>     > Working Group Summary
>     >
>     >   This document has had consistent interest from the working group.
>     >   Because it defines a new BGP community, it was reviewed by the idr
>     >   working group as well.
>     >
>     > Document Quality
>     >
>     >   The document has been implemented by major router vendors.
>     >   It is known to be in use in two large IXPs, AMS-IX and DE-CIX.
>     >
>     > Personnel
>     >
>     >   Document Shepherd: Sandra Murphy
>     >   Responsible Area Director: Alvaro Retana
>     >
>     > _______________________________________________
>     > sidr mailing list
>     > sidr@ietf.org
>     > https://www.ietf.org/mailman/listinfo/sidr
> 