Re: Comments on alternatives

["j.garrett" <[e-mail]>]

Joel,

> Having posted some of the difficulties to the list, I certainly agree that
> there are some problems with our transit-router to transit-router
> behavior.
> 
> There are several possible approaches to the solution.
> 
> 1) Rifs/BGP Queries are a methodology outlined in an ID.  The primary
>     concern I have with this particular methodology is its interaction
>     with multiple levels of aggregation.  If there are multiple levels,
>     one is required to make several queries and maintain several
>     "relationships" with aggregating routers.  This seems to be significant
>     overhead.

The ID you reference may establish an additional "relationship" to undo
an aggregation (e.g., if the router that did the aggregation is not
already a peer).  Clearly there is some overhead associated with
establishment and maintenance of this relationship.  An alternative
with its own different overhead would be a request forwarded over
existing peer relationships in the opposite direction of the path taken
by the aggregated route.  This request simply asks for an unaggregated
route to "this NLRI".  The request stops when it reaches the router
that has the unaggregated route, and the  request never leaves
the subnetwork.  And, borrowing from the ID, the request is not sent
unless the SameATMNetwork attribute is set.  A subsequent request
could "delete" the first request.  This approach (which borrows key
ideas from the ID, with a minor modification) burdens intermediate
routers with additional (unaggregated) routes, but requires no
new "relationships".

> 
> 2) NHRP with state exchange could be used in certain situations.  If both
>     ends are BGP routers (or both are intra-domain routers within the same
>     domain) a degenerate exchange between the two will allow the detection
>     of routing loops, and their removal.
> 2a) In order to do this however, we would also have to specify what happens
>     when the query crosses the intra/inter border.  Is it terminated.  Is
>     the query propagated, and the response replaced if it turns out to be
>     router-router?  (There are enough bits to tell this.)  Or is there
>     something else to do in this case.

Since the "please don't aggregate" query suggested above is only
used for undoing aggregation, it should add considerably less
overhead than NHRP, and, of course, does not add loops.

> 
> 3) Or should we punt the whole thing back to a query that ONLY works for
>     host resolution.  I personally would like a mechanism which worked
>     for host-host, host-router, and appropriate router-router if that can
>     be determined safely and reliably.

Your comments seem focused on the "aggregation" problem.  IMHO,
the "address resolution problem" is more important, and is solved
(perhaps some polish is needed) using similar procedures but
radically different syntax in RFC1433 and RFC1735.  Also, the ID
you reference in item 1), above, adds a third variation (same source
provides address resolution information) with yet another syntax.
We should declare the address resolution problem solved, with an 
open item to determine the best syntax.

A perspective note:  Aggregation does not create additional hops
unless at least one of the routes to be aggregated has a next-hop
on the Large Cloud, and that next-hop is not the next-hop for the
aggregated route.  Also, aggregation is an option - a router on a
Large Cloud could determine whether a potential aggregation could
result in additional hops or not, and could choose to aggregate
only if aggregation did not create additional hops.

> 
> Thank you,
> Joel M. Halpern				[e-mail]
> Newbridge Networks Inc.

John Garrett
AT&T Bell Labs
[e-mail]
908 580-4719