I assume that the ext-comm passes policy. Thanks, Jakob.
> -----Original Message----- > From: Keyur Patel [mailto:ke...@arrcus.com] > Sent: Friday, March 03, 2017 12:43 PM > To: Jakob Heitz (jheitz) <jhe...@cisco.com>; The IESG > <iesg-secret...@ietf.org>; IETF-Announce <ietf- > annou...@ietf.org> > Cc: draft-ietf-sidr-origin-validation-signal...@ietf.org; sidr@ietf.org; > sidr-cha...@ietf.org; The IESG > <i...@ietf.org>; sa...@tislabs.com; rfc-edi...@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)" <jhe...@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-boun...@ietf.org] On Behalf Of The IESG > > Sent: Wednesday, January 11, 2017 7:25 AM > > To: IETF-Announce <ietf-annou...@ietf.org> > > Cc: draft-ietf-sidr-origin-validation-signal...@ietf.org; > sidr@ietf.org; sidr-cha...@ietf.org; The IESG > > <i...@ietf.org>; sa...@tislabs.com; rfc-edi...@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 > _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr
