Subject: [Sidrops] draft-ymbk-sidrops-ov-signal-02.txt

From: Randy Bush <[email-masked]>
Date: Mon, 28 Jan 2019 14:05:17 -0800

i would like to put draft-ymbk-sidrops-ov-signal-02.txt on the agenda
for praha.  discussion so far:

  there was one red herring; outsourcing security.  as this was
  discussed in the draft, i can only assume actual reading helped.

  the substantial issues raised in the meeting (i found nothing in the
  mailing list archives) seems to be the signaling/transport.  let's
  focus on this.

these seem to be three general alternatives for signaling.

  in-band, as described in the draft, uses an extended community.
  alternatively it could use a new attribute or other hack.  such
  alternative in-band mechanisms could be discussed/investigated.
  
  a new afi/safi, which did not get rousing support from router
  implementors who would have to create and support a whole new afi/safi
  for the task.  of course, creative folk could undoubtedly find more
  things to do with the new afi/safi if they get bored with bgp-ls:)

  augment the rpki-rtr protocol to allow the router to signal back to
  the cache one or more invalid routes.  but then what happens with
  those data?  if the cache will signal those to router clients, then
  those router clients will have done the evaluation on their own.

these are the thoughts which led us to in-band signaling.  but this is
certainly worth discussing, here, praha, or both.

randy

---

From: Tim Bruijnzeels <[email-masked]>
Date: Tue, 29 Jan 2019 11:13:00 +0100

Hi Randy, all,

I have a question: why is signalling OV (within a trust boundary) preferable over doing OV?

If signalling is desired, then the community seems plausible enough to me, albeit that it's not clear to me how this is easier on the router than doing OV in the first place.  A lot of routers support this now, and there are more and more lightweight RP options. But I may well miss the operational reason for this, so don't take this as opposition.

Tim

> On 28 Jan 2019, at 23:05, Randy Bush <[email-masked]> wrote:
> 
> _______________________________________________
> Sidrops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sidrops

---

From: Randy Bush <[email-masked]>
Date: Tue, 29 Jan 2019 06:59:41 -0800

hi tim,

(  omg!  someone is alive in this wg!  :)

> preferable over doing OV?

within the trust boundary, one tends to want to manage complex services
on fewer devices.  route reflection is a poster child; the clients
have a restricted number of peers and a minimized consistent view.  so
it is what we used in the text.

   Within a routing trust boundary, e.g. an operator's Point of Presence
   (PoP), it may not be desirable or necessary for all routers to
   perform Origin Validation using the Resource Public Key
   Infrastructure (RPKI) per [RFC6811].  A good example is route
   reflectors (see [RFC4456]).

a pop may have a few dozen routers.  no need to run rpki-rtr and full
validation on them all.

> If signalling is desired, then the community seems plausible enough to
> me, albeit that it's not clear to me how this is easier on the router
> than doing OV in the first place.

one can do it with policy, no need for a whole rpki-rtr client and
validation.

randy