Re: [sidr] Question about draft-ietf-sidr-pfx-validate-03

Danny,

IMO the way to handle this is observe that all routes have a validity state attribute and that it needs to be settable in policy.  I believe the draft already says this (I will check though) and so it provides the necessary minimum toolset needed to apply a given state to local routes.  It might be worth saying something about what state a route should take by default, which I'm pretty sure we don't do now.  (If done this might need to be broken down into several cases, e.g. EBGP vs. IBGP vs. locally originated.)

--John

On Nov 13, 2011, at 12:54 AM, Danny McPherson wrote:

> 
> My read of the current draft suggests that if there's a route generated by the 
> local AS in BGP it could never have a "Valid" state, and by definition would 
> either posses a "Not found" or "Invalid" state -- even though the local 
> AS may well have a "ROA" and reside in the mapping table as well(!).
> 
> I do not believe the current text is Section 5 is sufficient to address this case, 
> specifically with either this:
> 
> "Considering invalid routes for BGP decision process is 
> a pure local policy matter and should be done with utmost care."
> 
> or this:
> 
> "In some cases (particularly when the selection algorithm is 
> influenced by the adjustment of a route property that is not 
> propagated into IBGP) it could be necessary for routing 
> correctness to propagate the validation state to the IBGP 
> peer.  This can be accomplished on the sending side by setting 
> a community or extended community based on the validation 
> state, and on the receiving side by matching the (extended) 
> community and setting the validation state."
> 
> I could think of a number of way to address this, but for there to exist the 
> possibility that an internally generated prefix (for which a ROA may well exists)
> could NEVER have a "Valid" state needs to be corrected.
> 
> Also, S 4:  s/to rest of the network/to the rest of the network/
> 
> Thanks, 
> 
> -danny
> 
> _______________________________________________
> sidr mailing list
> sidr@ietf.org
> https://www.ietf.org/mailman/listinfo/sidr