Re: An idea: GxSE

["Jon (Taz) Mischo" <taz@tazlore.com>]

On Wed, 27 Jun 2001, RJ Atkinson wrote:

> >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).

You need to re-read some of what I've said about how this rewriting is
actually done.  You could have 20,000 border routers.  The behavior is
still the same.  A border router merely looks at the SK address of a
packet when it is going into an egress queue, and makes sure the GR is
appropriate.  If it's not, it rewrites the GR.  This may not happen on the
queue, this may happen in an asic on the port...there are many ways to
implement it.

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

They are a type of multi-homed site.

>         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.

As a former Network Engineer for a few large networks (including one of
the largest ISPs in the history of the US), I can tell you I'd tolerate a
new directive in an IGP better than a whole slew of ICMP messages to every
host every time Joe Blow's route flaps.

>         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.

RIP is used in some cases, yes.  It is good for very simple
networks.  GxSE works better with a link state protocol because it has
faster convergence and notices something is wrong a lot faster.  GxSE
would work just fine with RIP, it just wouldn't be as efficient.  That
is just a basic of routing, however.

>         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 ?

I think you may not have seen why I was talking about link state
IGPs.  The additional goop actually would HELP, in that it would prevent
packet storms.  Most network engineers dislike packet storms.

> >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...

ummm?  I don't think you understand GxSE.  Source addresses get rewritten,
not destination.  The point is NOT to have to do what you just
said.  That's what we're trying to avoid.

> >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.

Origin host doesn't need a clue.  My approach is for a stupid host.  
Doesn't need to know, unless it specifically asks because it is doing
something like IPsec.

> >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...

Heh.  The point is that ASIC changes mean hardware changes.  That's even
more slowly adopted.  How you choose to implement it is your business, not
mine.  I could tell you 10 different approaches.  The point here is mainly
that you should be able to move it away from the core, especially if your
core is overworked.

-Taz

-- 
        "Be liberal in what you accept,
      and conservative in what you send."
--Jon Postel (1943-1998) RFC 1122, October 1989