Subject: Re: [Sidrops] WGLC for draft-ietf-sidrops-ov-egress-00.txt - ENDS 11/25/2019 (November 25 2019)

From: Chris Morrow <[email-masked]>
Date: Sun, 01 Dec 2019 20:07:02 +0000

On Wed, 27 Nov 2019 21:17:08 +0000,
> > Is there such a thing as non-deterministic policy?
> > What does it mean to say that the outcome of applying
> > one or a set of policies is that it results in
> > a random AS being the origin AS?
> 
> non-derministic != random
> 
> in this case it is meant to refer to policy results which depend on
> exogenous data

The case probably is that at some point (with certain attributes set
by an upstream bgp speaker) OriginAS could be any of a set of values.

So, ideally the operator would just create ROA with the set covered,
right? (really 1 ROA per origin)

I think Sriram is getting to that, or is saying it in a way that
wasn't clear to me :)

-chris

---

From: Randy Bush <[email-masked]>
Date: Sun, 1 Dec 2019 12:40:14 -0800

Many documents already say to be sure to issue ROA(s) for the AS(s) which announce the prefix. This document does not change that in the slightest. If we start reiterating practice and restating the obvious we will have a document three or more times as large but with zero real added value.   Let us not do that to this simple document. 

randy, on a phone

> On Dec 1, 2019, at 12:07, Chris Morrow <[email-masked]> wrote:
>

---

From: Chris Morrow <[email-masked]>
Date: Sun, 01 Dec 2019 21:31:42 +0000

On Sun, 01 Dec 2019 20:40:14 +0000,
Randy Bush <[email-masked]> wrote:
> 
> Many documents already say to be sure to issue ROA(s) for the AS(s)
> which announce the prefix. This document does not change that in the
> slightest. If we start reiterating practice and restating the obvious
> we will have a document three or more times as large but with zero
> real added value.  Let us not do that to this simple document.
> 

that seems fair. (provided that this was what Sriram meant I guess)

---

From: "Sriram, Kotikalapudi (Fed)" <[email-masked]>
Date: Mon, 2 Dec 2019 00:54:08 +0000

>that seems fair. (provided that this was what Sriram meant I guess)

My problem was with these two sentences:

#1 
"Configurations may have complex policy where the final announced
   origin AS may not be easily predicted before all policies have been
   run."

Is it not the same as simply saying: 
Configurations may have complex policy where the final announced
   origin AS is determined only after all policies have been run.

Why not state that and keep it simple?

#2 
"Therefore it SHOULD be possible to specify an origin validation
   policy which MUST BE run after such non-deterministic policies."

What does it mean to say "specify origin validation policy"?
RFC 6811 has already specified the origin validation procedure (policy?).
The use of the term "non-deterministic policies" is ill advised.
The operator knows their complex policies and can determine
the origin AS that would result after the policies are applied.
So the sentence can be simply stated as:
Therefore, origin validation MUST BE performed after the policies are run.

I hope this clarifies what I was trying to say.

Sriram

________________________________________
From: Chris Morrow <[email-masked]>
Sent: Sunday, December 1, 2019 4:31 PM
To: Randy Bush
Cc: Chris Morrow; Sriram, Kotikalapudi (Fed); [email-masked]; [email-masked]; [email-masked]; Jeffrey Haas
Subject: Re: [Sidrops] WGLC for draft-ietf-sidrops-ov-egress-00.txt - ENDS 11/25/2019 (November 25 2019)

---

From: Randy Bush <[email-masked]>
Date: Sun, 01 Dec 2019 17:00:14 -0800

> Why not state that and keep it simple?

because it is the inability to predict which is important.

> the origin AS that would result after the policies are applied.

no.  that is point.  as stated before, exogenous data can make the
result not deteminable from analysis of the configuration.

> I hope this clarifies what I was trying to say.

it does.  but i happen not to agree with it.

randy

---

From: "Sriram, Kotikalapudi (Fed)" <[email-masked]>
Date: Mon, 2 Dec 2019 01:35:24 +0000

>because it is the inability to predict which is important.

In my understanding, the entire premise of the draft is that the operator
has created ROA with the appropriate origin AS whatever the complex
policies and exogenous data may be. Is it not?  
Then why do you insist on "inability to predict" the origin AS?
Seems contradictory to me. 

>result not deteminable from analysis of the configuration.

"not deteminable" by the AS operator? How? This needs to be illustrated with an example. 
Then the draft needs to explain if the origin AS is not determinable,
then was ROA not created? If the ROA cannot be created, then the draft requiring
OV on egress is hard to comprehend.

I may be missing something. But what is it?

Sriram

---

From: Randy Bush <[email-masked]>
Date: Sun, 01 Dec 2019 18:01:00 -0800

> In my understanding, the entire premise of the draft is that the
> operator has created ROA with the appropriate origin AS whatever the
> complex policies and exogenous data may be. Is it not?

no wonder you are surprised that it does not say that.  i kind of tried
to hint at the irrelevance when i said "their payments to ther RIR
should be current."

the purpose, as stated in the abstract, is

   For egress policy, it is important that the classification uses the
   effective origin AS of the processed route, which may specifically be
   altered by the commonly available knobs such as removing private ASs,
   confederation handling, and other modifications of the origin AS.

the document is clarification for router protocol implementors.

randy

---

From: "Borchert, Oliver (Fed)" <[email-masked]>
Date: Mon, 2 Dec 2019 22:32:58 +0000

>result not deteminable from analysis of the configuration.
 
Hi Randy,

I am somewhat puzzled, could you elaborate more what you mean by "exogenous data". 
Also I still don't see the "non-deteminable" aspect?

A clear example would be very helpful to understand what you mean,

Thanks,
Oliver

---

From: Randy Bush <[email-masked]>
Date: Mon, 02 Dec 2019 14:55:51 -0800

> I am somewhat puzzled, could you elaborate more what you mean by
> "exogenous data".  Also I still don't see the "non-deteminable"
> aspect?

prefix injected from static on A sent ibgp to B, and B has AS marking
policy based on a community which may or not have been marked by A.

randy

---

From: Chris Morrow <[email-masked]>
Date: Tue, 03 Dec 2019 04:28:39 +0000

On Mon, 02 Dec 2019 22:55:51 +0000,
> policy based on a community which may or not have been marked by A.

The general case here is likely that in a complex network (more than a
few routers), it's possible to have wonky things going on. Randy's one
example certainly is true, from a real network though I know of a case
where SOMETIMES prefixes get their origin-as set via initial creation
of the route (static route), and SOMETIMES the operator decided:

  "Oh, I should match on community-foo + attribute-bar and reset
   origin-as to BLOOP"

This leads to some hilarity when attempting to sort out RPKI/ROA data :(

  "Oh, that's clearly AS-BAR because we set that on the creation of
  the route!"

followed shortly by:

  "wait what? why is it AS-BLOOP??? WTF?"

In any case: "make the ROA you intend, all of them" is sound advice.
Verifying prior to shipping across your peering edge sure seems like
"being polite to the world" as well.

---

From: Randy Bush <[email-masked]>
Date: Tue, 03 Dec 2019 06:33:23 -0800

>   "wait what? why is it AS-BLOOP??? WTF?"

yep

> "being polite to the world" as well.

someone could give 500kg of complex advice to the operator who does this
stuff.  that ain't me.

the purpose of this draft is to request that the *vendors* allow origin
validation *after* all such kink.  hence the name.

randy

---

From: Jeffrey Haas <[email-masked]>
Date: Tue, 3 Dec 2019 09:45:38 -0500

> validation *after* all such kink.  hence the name.

And that was the early conclusion when we started working through this.
"It's messy".  
'Well, just let them run policy again after all of the weird stuff is done.'

-- Jeff