Subject: Re: [RPSEC] BGP Requirements Draft

From: Sandy Murphy <[email-masked]>
Date: Mon, 26 Sep 2005 05:42:33 -0400 (EDT)

>In the aggregation case,
>suppose you have 10.1.0.0/24 and 10.1.1.0/24, and you simply reoriginate
>10.1.0.0/23? Haven't you removed information from the AS Path? You can
>argue that this is a "new advertisement," reducing us to the first case,
>but it's not really true, since 10.1.1.0/24 is contained within
>10.1.0.0/23, and yet may have completely different policies, etc. As the
>receiver of a route, you have no idea how many actual subnets actually
>"live within" that route, where they are divided, and what the policies
>for each one of those subsets might happen to be.

Not sure why you are bringing up these policies, Russ, since BGP does
not carry any information about the policies at all.  So no one has
any idea of what the polcies might happen to be.  Ever.

And since the other side of this argument is making no claim about 
authorization to advertise a route to a covering NLRI, the fact that
the 10.1.0.0/23 contains the 10.1.1.0/24 is not troubling at all.
It is certainly not a counterexample.

The argument is that if you send a route for the NLRI 10.1.1.0/24,
the receiver is allowed to use that route to form its own route to
10.1.1.0/24.  What the receiver does with other NRLI has NO BEARING
ON  THE QUESTION.

--Sandy

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

---

From: Sandy Murphy <[email-masked]>
Date: Mon, 26 Sep 2005 10:21:04 -0400 (EDT)

>Further, it is possible for the path adjacency check to catch this, by
>adding various capabilities. You're trying to make an apples to oranges
>comparison.

So by comparing the path adjacency check without "adding various
capabilities", I'm not doing a properly eqaual comparison?   Ah, come on.

--Sandy

---

From: Sandy Murphy <[email-masked]>
Date: Mon, 26 Sep 2005 11:00:12 -0400 (EDT)

>More to the point, how would AS_PATH signing cope? :)

I *think* that the proposal for dealing with AS_SETS was to include
in the update all the AS_PATHS that went into the construction of
the AS_SET.

Aggregation leading to AS_SETS really muddies the picture for either
technique, I think.

--Sandy