Subject: Re: [Sidr] exact match for ROA vs more specifics

From: Stephen Kent <[email-masked]>
Date: Fri, 23 Feb 2007 15:30:38 -0500

I'm in favor of an exact match requirement when talking about ROAs 
and route advertisements.  This helps ensure that matching the ROA 
against a prefix is intentional, not an accident. An address space 
holder can always generate additional ROAs with exactly the right 
prefixes to match the intent of the authorization.

Steve

_______________________________________________
Sidr mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/sidr

---

From: Geoff Huston <[email-masked]>
Date: Sun, 25 Feb 2007 11:05:33 +1100

I'm against this exact match requirement - I think its a case of 
semantic overload in mixing basic authorities (permission to 
originate) with routing policy (explicit nomination of what prefixes to route).

However if we have a "don't care" bit in the ROA to allow a prefix 
controller to allow the AS to originate the route any way they want 
then I'd be happy.

Geoff

---

From: Russ White <[email-masked]>
Date: Wed, 28 Feb 2007 12:45:35 -0500

Geoff Huston wrote:
> semantic overload in mixing basic authorities (permission to originate)
> with routing policy (explicit nomination of what prefixes to route).

Agreed....

I could see someone wanting to say: "nothing longer than /x will be
advertised in this space," but I don't see any reason to make this an
exact match only.

:-)

Russ

---

From: Curtis Villamizar <[email-masked]>
Date: Wed, 28 Feb 2007 13:06:55 -0500

> advertised in this space," but I don't see any reason to make this an

Seems like an argument for the following expressiveness:

  prefix/len1[-len2]

Geoff would have to use prefix/len1-24 (or 28?, or ??) for most
prefixes, assuming that most prefixes would want some limit.  If not,
using prefix/len1-32 notation could be used to do what Jeff wants.  Or
some tool could display this as prefix/len1* to indicate any more
specific being allowed.  In this notation prefix/len would imply exact
match.

Obviously there is no need to store information in ascii string
format.  We want this expressiveness and maybe for display a common
notation would be helpful but not manditory.  It might be used in an
implimentation's XML representation or it might not be (an alternative
would be explicit prefix and len tags).

Curtis

---

From: "Larry J. Blunk" <[email-masked]>
Date: Wed, 28 Feb 2007 13:29:27 -0500

> would be explicit prefix and len tags).

  Curtis, sounds like an application for the RPSL range operators --

  An address prefix range is an address prefix
      followed by an optional range operator.  The range operators are:

   ^- is the exclusive more specifics operator; it stands for the more
      specifics of the address prefix excluding the address prefix
      itself.  For example, 128.9.0.0/16^- contains all the more
      specifics of 128.9.0.0/16 excluding 128.9.0.0/16.

   ^+ is the inclusive more specifics operator; it stands for the more
      specifics of the address prefix including the address prefix
      itself.  For example, 5.0.0.0/8^+ contains all the more specifics
      of 5.0.0.0/8 including 5.0.0.0/8.

   ^n where n is an integer, stands for all the length n specifics of
      the address prefix.  For example, 30.0.0.0/8^16 contains all the
      more specifics of 30.0.0.0/8 which are of length 16 such as
      30.9.0.0/16.

   ^n-m where n and m are integers, stands for all the length n to
      length m specifics of the address prefix.  For example,
      30.0.0.0/8^24-32 contains all the more specifics of 30.0.0.0/8
      which are of length 24 to 32 such as 30.9.9.96/28.

 -Larry

---

From: Curtis Villamizar <[email-masked]>
Date: Wed, 28 Feb 2007 13:59:30 -0500

In message <[email-masked]>
"Larry J. Blunk" writes:

Agreed.

Curtis