Re: An idea: GxSE

[RJ Atkinson <rja@inet.org>]

At 03:16 27/06/01, Jon (Taz) Mischo wrote:
>I understand your point, but with careful construction this shouldn't be
>an issue.  Assuming you use a link state protocol for the interior portion
>and you allow the border routers to notify the interior routers of the
>egress point, you could move the rewrite closer to the edge.  

        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.

        The latter is a lot simpler.  IMHO, simpler is 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).

        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.

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

Ran