Re: When can NLRI and Withdrawn Route info be modified?

[Brad Smith <[e-mail]>]

Hello Paul,

Thanks for the response.

> The protocol does not specify when it can or can't be modified.  Manual
> configuration can always modify something (you can lie about your view
> of the world if you want to be evil).

A particularly apropos example... my interest is, in particular, related
to securing BGP (yes, I'm still muddling around with this problem:).

Is there any reasonable constraint that can be put on when the NLRI can
be modified and who can do it?  E.g. would it be reasonable to say
that only an originating or aggregating BGP speaker can/should modify
the NLRI (and therefore Withdrawn Route) information?

The underlying issue here is, as a BGP speaker having to select a route,
who may I have to trust as the source of this information (seems pretty
clearly to be either the originator or last aggregator of the path), and
to what granularity does this authentication need to be expressed (hopefully
the NLRI and Withdrawn Routes can be authenticated as a whole by e.g. the
originator or last aggregator, my fear is they need to be authenticated on
a per destination network basis by the last BGP speaker in the path that
chose to muck with them).

> Is your question, when can things be aggregated and what do you have to do?
> If so, you can always choose to aggregate a route if you have information
> about some more specific prefixes of that canidate aggregate.  You can take
> this to the extreme of generating what we used to think of as a "default"
> route.
> 
> When you aggregate, you may, or may not, withdraw the more specific routes.
> Your choice again.  Obviously, it makes sense to withdraw more specific
> routes in almost all cases.  If you advertise a hunk of NRLI, you should
> be prepared to withdraw that same hunk if the conditions that created that
> aggregate change.

Understood.

> When do you use AA?  When you create an aggregate of more specific NRLI, the
> preferred choice is to combine the AS paths of the more specific NRLI into
> an AS set and advertise that set.  If for some reason, you do not create a
> set that contains complete information of all ASs in the paths you
> aggregated,  you add the AA attribute.

The answer to the following may be obvious, by definition, but I want
to make sure I understand... is it true that an ATOMIC_AGGREGATE will
only be generated in a situation where an AGGREGATE attribute would
also be generated? (Even writing this I realize that it could be read
as "is it true that aggregation is done only when aggregation is being
done"... but I'll leave the question on the table:).

> *My* reading of the text is, if, for any reason, you lose AS path information
> in the process of generating an aggregate, you must set AA to indicate that
> information has been suppressed.
> 
> Does anyone actually do anything with AA?  Not really as far as I know.

Understood.

Again, many thanks for your answers.

Brad