Loose Source Routing

Wed Mar 7 00:38:56 UTC 2001

Uh is this "invent an acronym" day on NANOGame Street?

|   It makes sense to require peers to allow LSTR through their peer's
|   networks.

LSRR is an IP option.  So is SSRR.  They stand, respectively, for
Loose Source and Record Route and Strict Source and Record Route (RFC 791).
All IP routers should DTRT with these options, even when disallowing
the service.

LSTR is something you made up which I guess means Loose Source Trace Route,
which I guess refers to what you get from some traceroutes that take a 
-g (to specify one (of perhaps several) LSRR gateways).

You probably _can_ allow something approaching only the traceroute
application to use LSRR across your network, but basically that'd
be done by something like filtering at the edge based on packet type
if the LSRR option is set.  Given that intermediate routers that
are not LSRR gateways themselves have little to do with processing
of an LSRR option, this seems, well, a suboptimal approach.

Of course, if you're doing MPLS (barf barf barf) then digesting 
a new acronym hourly and doing tonnes of packet classifications
at the edge is second nature anyway, so I guess I should shut
up before someone calls me a curmudgeon.

|   Any badness that LSTR would allow seems to pale in comparison to A> 
|   Peer's need to check policy compliance and operational troubleshooting,
|   and B> other nefarious things that can be done and not solved.

Okay, I can't resist: if you have deployed MPLS strategically
such that basically all traffic is going through multihop TE
tunnels, what becomes of a packet with several LSRR or SSRR 
options flagged?

(Extra credit for answers that let you be one of 2304290348209843 people
listed in the Acknowledgements or Authors sections of a typical MPLS wg draft,
or if you're a smarty pants who has already accomplished that, and still don't
have a looking-glass in your network).

	Sean.
- --
Sean Doran <smd+mean at ab.use.net>