Subject: [sidr] Comments on draft-pmohapat-sidr-origin-validation-signaling

From: Jeffrey Haas <[email-masked]>
Date: Wed, 4 Aug 2010 15:24:43 +0000

In addition to the energetic discussion about the terminology for the three
states of the community, I'd also like to suggest that the origin of the
validation may be relevant.  The cache protocol gives a data source for the
validation and that source probably should be represented within this
community.  This also argues that it may be reasonable to have multiple
instances of this community - or that the representation of the data source
should be a bit-vector.

I also wonder if "color" would need to go into a community such as this one.
Since the current purpose of "color" is unclear, it's hard to know one way
or the other.

The above has impact on the suggested changes to the BGP decision process.
For example, an operator may prefer that RPKI validation have precedence
over IRR validation.  Similarly, "color" may impact it.

-- Jeff

---

From: Pradosh Mohapatra <[email-masked]>
Date: Sun, 8 Aug 2010 14:03:07 -0700

Hi Jeff,

[Sorry about the delayed response]

> over IRR validation.  Similarly, "color" may impact it.

The original thought process was that all the above you have listed are local policy matter. E.g. the data source (RPKI or IRR) would be taken as a local policy hint to prefer one vs. the other... Same with color etc. Ultimately, it's only the path state that gets disseminated in IBGP and the corresponding decision process change is defined in the draft. But I see where you are going: if border router A fetches the origin validation database from RPKI and another border router B fetches the origin validation database from IRR, the third router receiving IBGP updates may want to know the source to be able to make a better decision. However this use case is extremely rare; do we really want to go there?

- Pradosh

---

From: Randy Bush <[email-masked]>
Date: Sun, 08 Aug 2010 17:20:39 -0700

> if border router A fetches the origin validation database from RPKI
> and another border router B fetches the origin validation database
> from IRR, the third router receiving IBGP updates may want to know the
> source to be able to make a better decision. However this use case is
> extremely rare; do we really want to go there?

no, let us not boil the ocean.

the question is not how complex all this can be made, but rather how
simple.

randy