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@ab.use.net>