Re: An idea: GxSE

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

On Wed, 27 Jun 2001, RJ Atkinson wrote:

>         If there are multiple egress points, then either one is
> carrying full routes in the link-state IGP that you postulate
> xor the modification happens at the site border router only.
> The site border router must be listening to EBGP anyway if it
> is multihomed, so it already would have the data needed for reasonable
> path selection.

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.

>         The latter is a lot simpler.  IMHO, simpler is better.

I agree that simplicity is often better.

> >In fact, if
> >you let the initial rewrite occur at the egress router, and then move the
> >rewrite backwards into the network, with the egress router indicating
> >validity of all recently used routes back into the IGP/other protocol for
> >this purpose, you would know where the packets are going.
> 
>         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).

>         An alternative would be a new kind of ICMP message from
> the border router back to the originating host.  This could be
> authenticated (e.g. using AH) in situations where such authentication
> was a concern.

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.

> >Basically, if there is a topology change, you just need to make sure
> >your path is still valid.  Another behavior to control this may be to stop
> >rewriting at the edge if you detect a topology change that may affect your
> >internal routing, and let the egress router rewrite and re-alert you.
> 
>         The latter is simpler and consequently more palatable, IMHO.

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.

Another point is that if there's some route flap going on, you may want a
rewrite indication dampening period.  Even if you are incorrectly
rewriting near the edge, your border routers are still capable of
rewriting, since they'll recognize the SK and decide that the GR is
incorrect and rewrite it.  If there's instability between core routers,
this could creat an ICMP storm or delayed convergence in an IGP, so a
dampening period might be wise.

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.

-Taz

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