Re: An idea: GxSE

[RJ Atkinson <rja@inet.org>]

At 14:44 27/06/01, Jon (Taz) Mischo wrote:
>I was talking about a design that specifically didn't require route
>redistribution.  Except in NSPs and larger running IS-IS, you generally
>don't have that sort of route distribution.  Your IGP will generally
>reliably get you to the same border router.  It may send you to a
>different border router due to IBGP, but these behaviors are fairly
>static.  As such, it's pretty easy to alert back towards the host that a
>rewrite needs to happen, and let the nearest capable router take care of
>it.

        We need an approach that handles large end-user organisations
(consider: GE, HP, NRL) where not all upstream trunks have interfaces
in a single router.  NRL's campus, which has ~3000 users at one
site, used to have 3-4 separate routers with upstream connections
(don't know what their topology is these days).

        It is precisely that sort of site that is more likely to be 
multi-homed, IMHO.

>>         Operational folks probably won't generally tolerate putting
>> all that extra stuff into the IGP, because it makes a complex system 
>> a great deal more complex.  This is particularly true in multi-homed
>> enterprises, most of which just run a plain old IGP (e.g. RIPv2, OSPF)
>> and are unlikely to deploy protocols common in ISPs (e.g. I-BGP, IS-IS).
>
>"All that extra stuff" is actually 1 thing if you use the ICMP message you
>talk about below.  The one thing is the ability to signal that it has
>routing table stability or doesn't have routing table
>stability.  Furthermore, you would only want to move rewriting into the
>network if you are running a link state protocol, as I said before.  This
>means OSPF, IS-IS, or EIGRP (which is really a hybrid and non-standard,
>but it IS used in lieu of IS-IS sometimes).

        Right, so I'd much rather use that ICMP message, work with any
IGP, not change any IGP, and not put any extra gorp in the IGP.

        A multihoming approach ought to work equally well if one is 
using RIPv2.  Lots of sites can and do use RIPv2 as their IGP.  RIPv2 
is more common when there is a single border router with 1 or more 
uplinks to different service providers, IMHO.  It is fine provided
the scale of the site is reasonable and the site has been structured
in a thoughtful manner.  RIP is also much easier to configure than 
a typical link-state IGP.

        Note that my objection is to putting any additional goop
into any of the IGPs (I don't consider IBGP to be an IGP).  Perhaps
I misunderstood your note ?

>An ICMP message sent back towards the host with rewriting directions
>would, indeed, be a good way to move the rewrite further back in the
>network.

        Or just tell the host to change its own source address
for that session and continue to let the site border router(s)
rewrite the destination if appropriate...

>Agreed.  But it means either an indication into the IGP that there is some
>sort of route instability, or another ICMP message towards the host
>indicating that rewriting should be done at the egress point again.

        Or the egress point just does the rewrite and also throws a clue
back to the origin host, without putting any gorp into the IGP.

>The main reason for moving the rewrite back is that you don't want to be
>putting all of the work on the border routers all of the time.

        I don't object to letting folks move the rewrite back
or to letting the host participate in such decisions.  

        I will note that I'm truly not worried about a router 
performing the rewrite over say 10 Gbps Ethernet uplink to an ISP 
at full line rate.  Forwarding ASICs are your friend.  Other folks 
mileage might vary of course...

Ran