I assume that the ext-comm passes policy. Thanks, Jakob.
> -----Original Message----- > From: Keyur Patel [mailto:[email protected]] > Sent: Friday, March 03, 2017 12:43 PM > To: Jakob Heitz (jheitz) <[email protected]>; The IESG > <[email protected]>; IETF-Announce <ietf- > [email protected]> > Cc: [email protected]; [email protected]; > [email protected]; The IESG > <[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) > > Jacob, > > Apologies for the delayed response. Comments #Keyur > > On 2/23/17, 1:26 PM, "Jakob Heitz (jheitz)" <[email protected]> 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:[email protected]] On Behalf Of The IESG > > Sent: Wednesday, January 11, 2017 7:25 AM > > To: IETF-Announce <[email protected]> > > Cc: [email protected]; > [email protected]; [email protected]; The IESG > > <[email protected]>; [email protected]; [email protected] > > 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 > > [email protected] > > https://www.ietf.org/mailman/listinfo/sidr > _______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
