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

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:dougm@nist.gov]
> Sent: Friday, March 03, 2017 1:56 PM
> To: Jakob Heitz (jheitz) <jheitz@cisco.com>; Alvaro Retana (aretana) <aretana@cisco.com>; draft-ietf-sidr-origin-
> validation-signaling@ietf.org
> Cc: sandy@tislabs.com; sidr-chairs@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)" <jheitz@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:dougm@nist.gov]
> >> Sent: Friday, March 03, 2017 11:36 AM
> >> To: Alvaro Retana (aretana) <aretana@cisco.com>; Jakob Heitz (jheitz)
> >><jheitz@cisco.com>; draft-ietf-sidr-origin-
> >> validation-signaling@ietf.org
> >> Cc: sandy@tislabs.com; sidr-chairs@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-bounces@ietf.org on behalf of aretana@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-bounces@ietf.org on behalf of 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?
> >> >
> >> >    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-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-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
> >