The Routing Over Large Clouds Mailing List Archive by date

[Curtis Villamizar <curtis@ans.net>]

In message <199410191854.OAA26336@maelstrom.acton.timeplex.com>, Juha Heinanen 
In message <199410191854.OAA26336@maelstrom.acton.timeplex.com>, Juha Heinanen 
writes:
> 
>    The stripped down BGP or IDRP should allow you to acquire (and
>    maintain)  routing information only about a subset of routes
>    (the one you are interested in) available at the peer (the exit router).
> 
> Yakov,
> 
> are you also proposing that hosts would run this stripped down protocol?
> what bothers me here is that i would not like to complicate the hosts
> that much.  

I'm not sure what you regard as the problem with running a routing
protocol if it is specifically modified to accomodate hosts which have
a need for limited information and which would prefer to keep their
link completely idle at times.

The problem is that we have not defined how to do this in sufficient
detail.  (See below).

> what i would like to get for the hosts is nbma arp which is very easy to
> implement, scales as well as routing protocols in general do, and would
> give us a fast start in true end-to-end atm connectivity for video
> conferencing, etc.  

I see NBMA ARP as a simpler alternative to NHRP to address the problem
I see NBMA ARP as a simpler alternative to NHRP to address the problem
of finding the border router address.  It is simpler because it
doesn't have all the NHRP gunk that won't work anyway.  :-)

> i'm afraid that, because of its complexity and problems, many nic
> vendors will not implement nhrp any time soon, which leaves the users in
> the dark and slows down wide scale atm deployment.  or may be that is
> exactly the router vendors hope ...
> 
> -- juha

I don't see NHRP as relevant to ATM deployment (or anything for that
I don't see NHRP as relevant to ATM deployment (or anything for that
matter).  Other may use it.  Maybe not.

wrt - being more specific on what to do.

For a host or small router, the NBMA provider router can be passive
For a host or small router, the NBMA provider router can be passive
(not initiate connections).  The host can take the routing session
down when the link is not in use.  Keepalives can be disabled.  I
think Cisco already allows this.

For the NBMA, BGP or IDRP can be extended to allow a host to provide
For the NBMA, BGP or IDRP can be extended to allow a host to provide
filter information, similar to export policy in gated, except peer
provided.  If the host needs an address it uses the default route
temporarily.  The routing daemon on the host requests a route to cover
the destination.  The provider returns the aggregate covering the
destination and less specific aggregates indicating portions of the
aggregate covered by more specific routes that are not being provided.
The host would then receive updates reflecting changes to that
aggregate that it now has.  As destinations come into use that fall to
aggregate that it now has.  As destinations come into use that fall to
the default route or to one of the more specific aggregates noted as
"missing", the host can request more aggregates.  As aggregates become
"missing", the host can request more aggregates.  As aggregates become
unused (a host can periodically check the use counts in its routing
table) a request can be sent to no longer receive updates for them.
When all aggregates have been idle, the host will receive no routing
traffic and with no keepalives, no traffic at all.  It can then bring
down the level 2 adjacency if that will reduce cost.  The routing
protocol part of this could easily be prototyped with PPP even though
cut through is not possible.  

I've already proposed how to determine whether to send an NBMA ARP for
I've already proposed how to determine whether to send an NBMA ARP for
the destination or the next hop after getting the BGP update.  I
haven't proposed the extensions needed to extend BGP to exchange the
export filter information, though this too can be covered with
optional BGP attributes.  Same goes for IDRP.

I'll leave it up to Yakov to design the PDUs if he has the time and
agrees with this approach.

Regards,

Curtis