Subject: [IPTEL] Intra-domain routing ramblings

From: "Bob Penfield" <[email-masked]>
Date: Wed, 3 Oct 2001 09:50:56 -0400

Hi all,

I've been doing some thinking about the various intra-domain routing
proposals, and I think there are a number of issues we need to work through.
This is a TRIP-biased analysis.

I guess my biggest concern with using something other than TRIP is the fact
that once the routing information gets into a TRIP speaking LS, it will be
flooded to all the other TRIP LSs in the ITAD. Ideally, this would be
aggregated information where routes with common addresses would be combined.
The question then is how "deep" into the ITAD do we want to advertise
specific gateway route availability, capacity and so forth? Do we want to
push the information to the "nearest" routing server LS, and require all
calls to go thru that routing server? Or do we want to push it to all parts
of the ITAD so that a call take only one proxy hop to get thru the ITAD to
the desired gateway? I suppose it depends on how many LSs & proxies are in
the ITAD.

I see three levels of hierarchy in the routing information exchange:

1. Gateway to LS
2. Intra-ITAD LS exchanges
3. Inter-ITAD LS exchanges

The concern is that the data exchanged at level 2 will duplicate the data
exchanged at level 1, particularly if gateways advertise their routing
information to multiple LSs in the ITAD.

If the number of LSs in an ITAD is small and it was desirable to have calls
routed to a gateway as soon as it entered the ITAD, using TRIP for level 1
would be the most efficient. Since, in this case, you want all the gateway
information  flooded to all LSs in the ITAD, you would not make the
Gateway-to-LS a separate ITAD. The Gateway would inject routes to a local
LSs, and those routes would be flooded to the rest of the LSs in the ITAD.
The problem is that the currently described TRIP Decision Process requires
that each LS pick 1 route (in essence pick a gateway) to put in its Loc-TRIB
and use for routing calls. This goes against REQ 11. I think REQ 11 is
important so that routing servers/LSs/proxies can make choices between
gateways based on the current conditions and ensure a high probability of
successful call setup.

Another consideration is having different protocols for basically the same
information is an extra burden on LS implementers and will affect the cost
of products. I think one of the really good features of TRIP is that it
combines the intra-domain capabilities of OSPF with the inter-domain
capabilities of BGP into a single protocol.

Discovery seems to be an important requirement for many people. IMHO, using
a separate mechanism for discovering gateways and LSs is perfectly
legitimate. SIP does not use SIP to discover SIP servers. We could use SLP
or DNS, or define something new, or even add it to TRIP.

That's just my opinion.

cheers,
(-:bob

Robert F. Penfield
Chief Software Architect
Acme Packet, Inc.
130 New Boston Street
Woburn, MA 01801
[email-masked]

_______________________________________________
IPTEL mailing list
[email-masked]
http://lists.bell-labs.com/mailman/listinfo/iptel

---

From: "Henning G. Schulzrinne" <[email-masked]>
Date: Wed, 03 Oct 2001 10:59:52 -0400

In addition to the model you posit, I believe there are probably several
models that could arise:

- In many situations, people won't need or want TRIP. After all, most
organizations in the world are quite happy without BGP, but do need
OSPF, RIP, IS-IS, etc.

- In other situations, you are going to have a single point (LS) per
ITAD that speaks TRIP, again similar to the arrangement for many
organizations with a single BGP peering arrangement. In that case, that
point is likely to do all kinds of policy translations and information
filtering in any event, so that having two protocols is a minor
inconvenience at best. You are not just going to be able to byte-copy
interior information to the externally advertised TRIP announcements.
[I'm avoiding the term LS since this term is also used for non-TRIP
things.]

Also, an interior protocol can make different choices. For example, it's
much easier to agree on some kind of internal charging indication for a
gateway/prefix, without worrying about coming up with one that fits
every peer and passes Department of Justice muster.

This, again, argues, I believe, that finding a one-size-fits-all
solution is not likely to be viable in this case. It is important to
make sure that information needed by TRIP can be conveyed by the
interior protocol, but the amount of per-prefix information in TRIP that
people seem to be able to agree on is so small at this point that this
seems to be hardly a consideration.

-- 
Henning Schulzrinne   http://www.cs.columbia.edu/~hgs

---

From: Manjunath Bangalore <[email-masked]>
Date: Thu, 04 Oct 2001 14:19:28 -0700

Hi Bob,

    Some thoughts on the propogation of routes from level 1 to level 2 in the
heirarchy that you brought out:

> the desired gateway? I suppose it depends on how many LSs & proxies are in

   My thinking is that gateway routes should be propogated only to the
"nearest" TRIP LS, (maybe to
 an additional LS or two for redundancy purposes). If gateway routes were to be
advertised deeper into
 the ITAD, the model would not scale as the number of gateways in the
ITAD increases and will result in significant
 additional traffic. Another important consideration that would not make that
model feasible is that, gateway
 routes carry capacity information, and if several LSs look at the same
capacity information in selection of
gateways to terminate calls, that can result in inconsistent assignment of
gateways. Ideally, there should be only one
controlling entity (LS/Proxy) that should be reading from the capacity
information in the gateway routes for identifying
gateways to terminate calls and rationing the available capacities from a
collection of alternative gateway routes to
achieve good load balancing to fairly distribute calls among the different
gateways.

   When gateways advertise routes to the nearest first-hop LS, the LS would
propogate these routes further into the ITAD
after modifying the "Next Signaling Hop" to point to the Proxy/Gatekeeper (for
instance) signaling entity controlling the gateways and one that has access to
the capacity information advertised by the gateways.

Thanks,
-Manjax