Subject: [Sidrops] A few quick comments / suggestions about Origin Validation Signaling

From: "Montgomery, Douglas (Fed)" <[email-masked]>
Date: Tue, 26 Mar 2019 09:48:27 +0000

https://datatracker.ietf.org/doc/draft-ymbk-sidrops-ov-signal/

1.  Make title more descriptive - we already have a few specs about what most folks would call "Origin Validation Signaling".   Maybe "Outsourced Origin Validation".  "Distributed" if that is our euphemism for outsourced.

At the last NANOG a few new comers to the technology pointed out what a confusing swamp of specs we have - and that navigating that swamp is non-trivial.  More descriptive titles would be a small step in the right direction.

2. Section 3 Trust Boundary

   "An [RFC4456] Route Reflector Cluster is an obvious candidate for this
   approach.  The route reflector(s) would perform Origin Validation and
   signal an Invalid route back to the sending client."

While I agree that an RP is the obvious place to do this, the draft would give one the impression that there are others.   

I would suggest that providing a few more details about how this would modify RFC4456 behavior would be useful.  That is one fully described example of how this would work.

If the RR model is the only model in which we think this works, we should say so.   Or more to the point, if I were to modify my general iBGP behavior as described in this draft, do we see any problems with doing that?

2.  Section 5 Actions

   "A sender receiving the returned prefix announcement so marked MUST
   treat it the way it would treat an Invalid origin that it itself
   detected.  It should withdraw all routes it had announced to that
   prefix with the Invalid origin AS.  This includes withdrawing any
   instances of additional paths with that origin AS advertised under
   [RFC7911]."

Does the above apply to both e-BGP and i-BGP advertised routes?   

Does it need the caveat of "on peering sessions on which OV is being performed"?

dougm
--  
Doug Montgomery, Manager Internet & Scalable Systems Research @ NIST

---

From: Randy Bush <[email-masked]>
Date: Tue, 26 Mar 2019 16:35:04 +0100

thanks doug.  will get to this after prag and i get sleep.

randy