Re: ROLC Overview

[Curtis Villamizar <[e-mail]>]

In message <[e-mail]>om>, j.garrett writes:
> I think it may be useful to summarize the ROLC
> problem and proposed solutions.
> 
> The ROLC Problem:  Multiple IP networks (or prefixes)
> may be overlaid on the same Large Cloud (i.e., subnetwork,

Could you *not* call this a subnetwork without clarifying that you
don't mean a LIS or classical subnet.  (Sorry- now back to the main
point of your note:).

> such as ATM, SMDS, Frame Relay, X.25, others?).
> In many cases current routing procedures will choose
> multi-hop paths across the large cloud.  This may happen
> for at least two reasons:
> 
>   1)  Current routing procedures are constrained by the
>       scope of current address resolution procedures.
>       The scope of current address resolution is an IP network,
>       or LIS.  Routing procedures will not choose a next-hop
>       unless address resolution procedures are available to
>       determine the subnetwork address of the next-hop.
>       Therefore, next-hops are on the same IP network/LIS
>       as the host/router using the next-hop.  Therefore,
>       paths across a Large Cloud with multiple IP networks/LISs
>       are often multi-hop paths.

Unless you don't aggregate further, in which case, existing protocol
capability to advertise third party route announcements can be used.
You just have to relax the "same subnet" restriction when generating a
third party route to "same media" and have an address resolution
protocol or carry the physical address as an attribute (as IDRP
already does).

>   2)  Some routing procedures may aggregate routes.  If a router
>       aggregates multiple routes that do not all share the same
>       next-hop, and if the next-hop for at least one of the
>       aggregated routes is on the Large Cloud, such aggregation
>       may lead to multi-hop paths across the Large Cloud, even if
>       the address resolution constraint has been solved.
> 
> At least two routing protocols (BGP-4 and IDRP) perform route
> aggregation today.  Both have a path attribute (AGGREGATOR) that
> identifies a route as aggregated, and identify the IP address
> of the router that did the aggregation.  An Internet-Draft
> (draft-rekhter-idr-over-atm-00.txt) describes how a router
> can solicit help from the AGGREGATOR to undo aggregation
> of aggregated routes.  IMHO, this approach (i.e., undo aggregation
> within the protocol that does the aggregation) is the proper
> solution to item 2, above.
> 
> Item 1, above, has been discussed since the Spring of 1991, first
> in the IPLPDN working group, and more recently in the ROLC group.
> Two types of solution have been discussed.  One type of solution
> is to overlay separate routing and address resolution procedures
> on top of "base" routing and address resolution procedures.
> One example of this approach is to send Redirects to routers.
> Shortcut routing was another variation, and NHRP is the most
> recent incarnation.  To date, every approach of this type has
> been shown to create stable routing loops.

No extension to address resolution is needed if the physical address
of the next hop is carried as a IDRP attribute (or if a BGP attribute
is added to do the same).

> The second type of solution to item 1, above, is to enhance
> address resolution, allowing "base" routing to use next-hops
> that are not on the same IP network as the router/host using
> the next-hop.  The enhancement is based on the observation that
> the router ADVERTISING a next-hop must be able to resolve the
> address of the next-hop.  Two approaches have been
> suggested for the router advertising the next-hop to also
> help resolve the IP address of the next-hop.  One approach
> simply adds the subnetwork address of the next-hop to the
> routing protocol.  Paul Francis suggested such an approach
> for BGP in  "Border Gateway Protocol NEXT-HOP-SNPA Attribute"
> (draft-ietf-bgp-nexthop-00.txt) dated April 15, 1991.

This made it to IDRP, but not to BGP.

> An alternate approach (query/response, with querys sent to
> the source of the routing information) was suggested by
> Garrett, Hagan, and Wong (Directed ARP, RFC 1433).  Embedding
> the subnetwork address in the routing protocol resolves all
> advertised next-hop routers.  However, this approach requires
> addition to the syntax of every protocol that carries the
> information.  The query/response approach resolves advertised
> next-hop routers, and also resolves destinations (ie, hosts)
> on the same subnetwork.  The query/response approach requires
> implementation of the query/response protocol, and changes
> to the procedures used by routing protocols (i.e., determination
> of next-hops to advertise) but does not require changes to
> the syntax of the routing protocol.

The only thing left is OSPF (unless you believe in IS-IS, but then the
same applies).  It would be possible to flood RIF LSAs (using the
opaque LSA) to a stubby area to get more specific routes from the ABRs.
If the ABRs didn't understand the opaque LSA you just get more hops
than you needed (same as when the router doesn't understand the new
optional BGP or IDRP attributes).

> I hope this overview is true, complete, and fair.  If so,
> perhaps it can help us focus.
> 
> John Garrett
> AT&T Bell Labs
> [e-mail]
> 908 580-4719

Thanks,

Curtis