IP over SONET considered harmful?

Mailman List Mirror (Read Only)
1

copying Tag-TTL into IP TTL. However, doing this introduces another
problem - it breaks traceroute. And there are enough folks in the MPLS
WG who think that the ability to traceroute through all the LSRs is an
"unalienated right".

  Without going to far into the traceroute source , would
  a solution to this problem be a modified traceroute that
  "understood" and could report Tag/MPLS "hops" as well as
  the normal method? There would need to be some way of
  identifying which devices were forwarding using Tag/Mpls
  and which were not, as well as getting and reporting
  the information. I think it falls into the same category of
  tracing cell forwarding in ATM without having access to the
  equipment doing the work.

In view of the above here are some of the possible avenues:

(a) try to get "rough consensus" with the MPLS WG to allow
    decrement IP TTL by 1 on egress (rather than copy Tag TTL
    into IP TTL), or

(b) talk to your favorite vendor(s), and ask the vendor(s) to put
    a "knob" that would decrement IP TTL by 1 on egress (rather
    than copying Tag TTL into IP TTL).

  Alan and I discussed the "knob" solution before, it seems
   to solve the problem, but under certain circumstances a packet
   could end up being forwarded forever because of (mis)configuration.

   -pee

2

Paul E. Erkkila writes:

Without going to far into the traceroute source , would
a solution to this problem be a modified traceroute that
"understood" and could report Tag/MPLS "hops" as well as
the normal method? There would need to be some way of
identifying which devices were forwarding using Tag/Mpls
and which were not, as well as getting and reporting
the information. I think it falls into the same category of
tracing cell forwarding in ATM without having access to the
equipment doing the work.

Without getting into whether this is a good idea - I suspect many
service providers would disable such a capability - one of the nice
aspects of traceroute is that it uses the usual packet forwarding path
until the last hop. In other words, it's a little hard to break the
normal packet forwarding mechanism without breaking traceroute too.
This charcteristic would be hard to preserve with such a solution.

Alan and I discussed the "knob" solution before, it seems
  to solve the problem, but under certain circumstances a packet
  could end up being forwarded forever because of (mis)configuration.

You do have to make sure that tunnels always move packets closer to
their destination, yes.