On 3/3/17, 3:24 PM, "Jakob Heitz (jheitz)" <[email protected]> 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:[email protected]] >> Sent: Friday, March 03, 2017 11:36 AM >> To: Alvaro Retana (aretana) <[email protected]>; Jakob Heitz (jheitz) >><[email protected]>; draft-ietf-sidr-origin- >> [email protected] >> Cc: [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) >> 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)" >> <[email protected] on behalf of [email protected]> 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)" >> ><[email protected] on behalf of [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? >> > >> > 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:[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-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 >> > > [email protected] >> > > https://www.ietf.org/mailman/listinfo/sidr >> > >> > >> > >> >_______________________________________________ >> >sidr mailing list >> >[email protected] >> >https://www.ietf.org/mailman/listinfo/sidr > _______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
