Subject: Re: [Sidrops] WGLC - draft-ietf-sidrops-validating-bgp-speaker - ENDS 09/07/2018 - Sept 7th 2018

From: Christopher Morrow <[email-masked]>
Date: Mon, 28 Oct 2019 13:11:15 -0400

This WGLC ... has dragged on very much too long :(

I think there's not consensus to move this forward at this time.
I think I should have said this ~8 months ago, but was hopeful that
either we might reach consensus OR the draft would be move to match
expectations of the working group.

At this point, I think a clear signal from the WG would help the
authors change their draft OR abandon it.

-chris

On Fri, Sep 7, 2018 at 10:03 AM Daniel Kopp <[email-masked]> wrote:
>
>
> > On 6. Sep 2018, at 15:40, Job Snijders <[email-masked]> wrote:
> >
> > In that case, it appears the draft has been taken over by current
> > events?  From what I understood from your organisation's communications
> > related to deploying RPKI origin validation there has been a commitment
> > to deploy this fall.
>
> No, the draft hasn’t been taken over by other events.
> The idea was to adjust the implementation according to the draft.
> So I don’t see that this draft is outdated in that sense.
>
> > This puzzles me - AMS-IX already implemented this, some documentation
> > can be found here: https://ams-ix.net/technical/specifications-descriptions/ams-ix-route-servers/route-server-filtering
> > (note the 6777:65012, 6777:65022, and 6777:65023) communities.
>
> Yes, AMS-IX has already some flavour of implementation for that… and one goal of the draft is to have a common and well defined way how to implement this.
>
> Kind regards
> Daniel
>
>
> _______________________________________________
> Sidrops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sidrops

---

From: Randy Bush <[email-masked]>
Date: Mon, 28 Oct 2019 11:13:32 -0700

> authors change their draft OR abandon it.

this draft, and others, should merge to use a common signal.  i think
oliver has the need here.

randy

---

From: Nick Hilliard <[email-masked]>
Date: Tue, 29 Oct 2019 00:05:22 +0000

> authors change their draft OR abandon it.

the ideas behind the draft have fundamental problems which don't appear 
to be resolveable.

Separate to this, since the last proper discussion about this draft in 
early 2018, proper RPKI has begun to take off in a serious way, so I 
would question whether the long term justification for progressing the 
draft is there.

Nick

---

From: Daniel Kopp <[email-masked]>
Date: Tue, 29 Oct 2019 15:28:59 +0000

Many thanks Chris for brining this up again. The authors would really like to progress with this draft.
From beginning of this year (and already last year) it seems that RPKI adoption is on a steep ascent.
But I think this doesn’t affect the idea of this draft (tagging RPKI validation results onto BGP announcements, especially at IXPs) in a very negative way.

I appreciate Randy’s and Nick's feedback and looking forward to further comments and opinions.
Hope we can have a consensus about the draft soon.

Thanks again!

Best
Daniel

> On 28. Oct 2019, at 18:11, Christopher Morrow <[email-masked]> wrote:
>

---

From: "Jakob Heitz (jheitz)" <[email-masked]>
Date: Wed, 30 Oct 2019 00:51:27 +0000

IOS-XR revalidates. Has done since the beginning.

Regards,
Jakob.

-----Original Message-----
From: Sidrops <[email-masked]> On Behalf Of Randy Bush
Sent: Tuesday, September 4, 2018 11:07 PM
To: Christopher Morrow <[email-masked]>
Cc: SIDR Operations WG <[email-masked]>
Subject: Re: [Sidrops] WGLC - draft-ietf-sidrops-validating-bgp-speaker - ENDS 09/07/2018 - Sept 7th 2018

>   1) "route origin validation is not as hard to see deploying today"

see draft-ietf-sidrops-ov-clarify-05.txt.  essentially vendors'
implementations are funky and so it is hard for me to do it myself.

and it is not only ov-clarify.  test whether your fave implementation
re-evaluates a bgp prefix when a roa change comes in over rpki-rtr.  the
messy story goes on.

>   2) "just introducing an IXP lan/RS that simply implements the validation
> and takes action(s) is the right course of action"

s/the right course/one right course/

what is nice is that the ixp-provided filter does not have the same
problems as above.  so it is a leapfrog while hardware vendors catch up.
it is driving origin validation deployment.

randy

---

From: Randy Bush <[email-masked]>
Date: Tue, 29 Oct 2019 19:49:48 -0700

> IOS-XR revalidates. Has done since the beginning.

and that is likely why those rolling out ROV this year were XR users.
thank you.

>> it is driving origin validation deployment.

further to that, as most RSs run bird and bird does not reevaluate, ...
it's boiling frog, not leapfrog.  sigh.

randy

---

From: Nick Hilliard <[email-masked]>
Date: Wed, 30 Oct 2019 09:49:02 +0000

bird doesn't re-evaluate, but this can be worked around in a non-ideal way:

> 40 11,20 * * * root /usr/sbin/birdc -s /var/run/bird/bird-rs1-lan1-ipv4.ctl reload in all >/dev/null

~100 clients causes CPU spikes as shown in the graph below.

The decay profile in the spikes is caused by reloads of other bird 
instances on the same vm.

Nick

---

From: "Borchert, Oliver (Fed)" <[email-masked]>
Date: Wed, 30 Oct 2019 17:50:07 +0000

Randy makes a good point by proposing to merge multiple efforts into one single approach. This will eliminate any possible confusion going forward. During the adoption call for signaling BGPsec path validation, a valid point was raised to use the current RFC 8097 signal and extend it using a section of the reserved field. Using BGPsec unverified as value 0 allows backwards compatibility and I am currently in the process of modifying draft-sidrops-bgpsec-validation-signaling to update 8097 for that purpose.

Today, I was talking to Daniel and I believe we can solve the issues addressed in draft-ietf-sidrops-validating-bgp-speaker. 
The current RFC 8097 already opens the door for signaling the attribute via EBGP. The end of section RFC 8097 section 5 reads:

"... However, it SHOULD be possible to configure an implementation to send or	 		
accept the community when warranted.  An example of a case where the	 		
community would reasonably be received from, or sent to, an EBGP peer	 		
is when two adjacent ASes are under control of the same	 		
administration.  A second example is documented in [SIDR-RPKI]."

With the current wording of "when warranted", one can make the case that a contractual agreement between two adjacent ASes which are NOT under control of the same administration could also warrant such exchange. Said that some extra wording to make this more clear or even simplify the issue can easily be added. This will also be helpful for future BGPsec validation state signaling where larger ISP's could perform the majority of BGPsec path validation and the client peer just would validate the last hop - if at all needed.

Regarding Operational Recommendations (section 5 of draft-ietf-sidrops-validating-bgp-speaker-03 ), I would propose to put this into a separate draft or maybe BCP. The different operational modes described there are worthwhile keeping but should be separate from the signaling,

Thoughts?

Oliver 

    
    
    randy
    
    _______________________________________________
    Sidrops mailing list
    [email-masked]
    https://gcc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fsidrops&amp;data=02%7C01%7Coliver.borchert%40nist.gov%7Cc9707c8f107741dd7a2208d75bd2941f%7C2ab5d82fd8fa4797a93e054655c61dec%7C1%7C1%7C637078832292414198&amp;sdata=LHM0DkGM6sqMwy1%2F3vhzWvPyP5aHaaEujo%2FZLt4IqRU%3D&amp;reserved=0

---

From: "Randy Bush" <[email-masked]>
Date: Wed, 30 Oct 2019 10:53:00 -0700

> This will eliminate any possible confusion

well, how about reduce? :)

randy

---

From: "Borchert, Oliver (Fed)" <[email-masked]>
Date: Thu, 31 Oct 2019 14:20:57 +0000

Well... yes, I agree reduce might be the better wording :)

    
    
    randy

---

From: Christopher Morrow <[email-masked]>
Date: Thu, 31 Oct 2019 11:40:50 -0400

So... it sounds like Oliver/Daniel/et-al will chat some more and
present a conclusion via draft or meeting presentation?

---

From: Randy Bush <[email-masked]>
Date: Thu, 31 Oct 2019 09:51:32 -0700

> present a conclusion via draft or meeting presentation?

draft please.  let's hope we have not totally become the social
engineering task force (SETF).

randy

---

From: "Borchert, Oliver (Fed)" <[email-masked]>
Date: Thu, 31 Oct 2019 18:02:29 +0000

I am planning on that. Not sure yet if I have to remote in though or be in person,
Nevertheless book me for 10 minutes,

Oliver

On 10/31/19, 11:41 AM, "Christopher Morrow" <[email-masked]> wrote: