Thanks. This is the part I was looking for: > I would suggest one keep/use the locally computed validation state, > not the signaled state.
Jakob. > -----Original Message----- > From: Montgomery, Douglas (Fed) [mailto:do...@nist.gov] > Sent: Friday, March 03, 2017 1:56 PM > To: Jakob Heitz (jheitz) <jhe...@cisco.com>; Alvaro Retana (aretana) > <aret...@cisco.com>; draft-ietf-sidr-origin- > validation-signal...@ietf.org > Cc: 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) > Importance: Low > > > On 3/3/17, 3:24 PM, "Jakob Heitz (jheitz)" <jhe...@cisco.com> wrote: > > >The case is unlikely, but something we need to write code for. > >Without an answer, then the validity will just be set by whichever > >was set last. That would make it indeterminate. > > > >The case is for a single route. There is no suggestion of the validity > >of one route being used to set validity of another. > > By single route, do you mean an update from a specific iBGP peer? Or do > you mean updates from two or more iBGP peers? > > > > >A router may be doing local validation, using rpki-rtr protocol. > >In additiion, it may receive a route with a validation state in > >an extended-community. > > In this case are you saying the router is doing origin validation on iBGP > updates, even though they contain the extended-community? > > If so, I would suggest one keep/use the locally computed validation state, > not the signaled state. > > > > >The question is what to do if one validation method sasys "invalid" > >and the other says "valid". > > > >The situation may arise if the router sending the extended-community > >is using a different validation method, not RPKI. > > It can also happen if all routers are doing RPKI, but there is transient > RPKI state skew between multiple validating caches, local SLURM policies, > etc. > > > > > >Thanks, > >Jakob. > > > >> -----Original Message----- > >> From: Montgomery, Douglas (Fed) [mailto:do...@nist.gov] > >> Sent: Friday, March 03, 2017 11:36 AM > >> To: Alvaro Retana (aretana) <aret...@cisco.com>; Jakob Heitz (jheitz) > >><jhe...@cisco.com>; draft-ietf-sidr-origin- > >> validation-signal...@ietf.org > >> Cc: 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) > >> Importance: Low > >> > >> I am not sure I understand the original question/point and/or Alvaro's > >> response. > >> > >> The spec in section 2 says: > >> > >> “...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.” > >> > >> > >> That seems like a suggested receive logic … although it is a SHOULD. Of > >> course it is still up to local policy how this validation state effects > >> the decision process. > >> > >> I think it would be a mistake to make some change that suggested that > >>the > >> received validation state on a iBGP update should somehow influence the > >> computed origin validation state of other received updates. In > >>particular > >> influencing the validation state of any locally validated updates. The > >> original question seems to suggest that a received INVALID or VALID > >>might > >> supersede a “NOT_FOUND”. (was that the suggestion?) Such a situation > >> represents an RPKI state skew between the two routers (might just be > >> transitory) but it is impossible to tell if the I/V or the NF represents > >> the more “up to date” result. Also having the origin validation results > >> of a router that is doing OV overwritten by some other router (possibly > >> synced to a different validating cache) will make debugging OV results > >> very difficult. > >> > >> In short, for now, I would not change the spec. With some operational > >> experience we might find some use for similar functionality (I wonder if > >> by NOT_FOUND you meant not validated) but for now, I would not change > >>it. > >> > >> dougm > >> — > >> Doug Montgomery, Mgr Internet & Scalable Systems Research at > >>NIST/ITL/ANTD > >> > >> > >> > >> > >> > >> On 2/23/17, 4:55 PM, "sidr on behalf of Alvaro Retana (aretana)" > >> <sidr-boun...@ietf.org on behalf of aret...@cisco.com> wrote: > >> > >> >[Took the IESG, ietf-announce and rfc-editor lists off.] > >> > > >> >Jakob: > >> > > >> >Hi! > >> > > >> >This document is already in AUTH48. I don’t think we need to make any > >> >changes to the document, but if we do, we need to decide very soon. > >> > > >> >The document doesn’t say anything about what should be done with this > >> >extended community, except to say that “speakers that receive this > >> >validation state can configure local policies allowing it to influence > >> >their decision process.” IOW, there is no expected default processing > >>of > >> >the validation state. > >> > > >> >If the community is received and the router also has validation > >> >information, then I agree that the extended community is not > >>needed…but I > >> >think that action is outside the scope of this document. > >> > > >> >Thanks! > >> > > >> >Alvaro. > >> > > >> > > >> > > >> > > >> >On 2/23/17, 4:26 PM, "iesg on behalf of Jakob Heitz (jheitz)" > >> ><iesg-boun...@ietf.org on behalf of 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? > >> > > >> > I don't see that condition covered in the draft. > >> > I would say to ignore the extended community. > >> > > >> > 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-signa > >>>li > >> >ng/ > >> > > > >> > > > >> > > > >> > > > >> > > > >> > > 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 > > _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr
