Internet Diameter and TTL decrementing Followup

I took the liberty of summarizing interesting comments by folks on
  this latest thread "IP over SONET considered Harmful?" My
  comments and questions are inline with these notes.

yakov - look at putting knob support in or get concensus

  Yes, this is indeed the answer. I'd like to see the MPLS
  group dictate that the MPLS standard require the ability for
  the user to specify MPLS and IP TTL interaction.

  I'll go away and leave you to your other conversations when
  MPLS people and the big MPLS vendors say they will do this
  in this forum.

bill@canarie - doing physical mesh

  Too expensive. We can afford it but it just isn't an
  optimal solution. WDM switching is WAAAY off.

havard - ttls under 64 are broken (per rfc)

  Slow automobile drivers are bad. Yet they exist. And
  must be considered.

jmalcolm - atm+fr nspnets hide l2 paths already, non mpls ttl
    decrementing@l2/l3 hops desired from vendors

  Agreed. Eloquently stated as always.

pee@fro - if you want l2/mpls tracing, build it w/out ttl use

   Would have been nice if those smart MPLS people had thought
  of that, wouldn't it?

  l3 ttl nullification too complex and scarey

   one idea would be to remove the TTL decrementation (is that
  a word?) from certain router interfaces. However, why
  build pits to fall into when we can change the path,

pferguso@cisco - mpls ttl discussed ad nauseum, knob suggested,

  No concensus on this should equal no standard. I truely
  think it's that big of a deal.

    atm+fr nspnets may prefer to hide l2 hops
  - internet wider than in nsfnet days
  - ss7 not involved in this problem (re: hannigan@xcom)
  - leave decision about ttl decrementing to provider
nshen@mci - nspnets can hide l2 or l3 if they choose, maybe put
    path tracing into cos bits or elsewhere than ttl exp.

  Ideas on how to do path tracing (to make this ttl for path viewing
  argument go away) would be appreciated.

kwe@geo - world didn't end when nsfnet had 2 ttl decrements per hop.
    back in 1994. a long time ago. much smaller
    internet (sorry for editorializing) -- harmful not

  Doesn't address this problem. Arguing by analogy is not helpful.

scudder - ttl complaints are product of low moral evolution

  I really like him. But I don't agree.

smd - people who don't want ip ttl decremented at each l3 hop must
  not be concerned about loops

  Not so concerned with loops as usability. Loops are easier to fix
  and prevent than windows 95 ttls.

  - all ISPs should display full frontal nudity and show all
    internal toplogy

  ISPs will hide things.

  However, having once been a big ISP serf, I really don't think the
  ISP gives a whoot if you see their topology. By that I mean they
  won't actively work to prevent you from finding out. Certainly
  they won't actively work to help you understand anything, but it's
  really not a conspiracy. More of a financial decision (do I spend
  money==time on showing them what's under my kimono or do I make
  things better so my customers like me so I make more money for my

  - use different ICMP for ttl unreachables at l3 and mpls

  Would be cool. How? Where in the packets and standards do we
  stuff this idea?

  - okay to give isps tools to hurt themselves if they
    are aware of risk
  - wants vadim to send ciena folks to him and lothberg
    about stuff

  Thanks for this broadcast. Maybe if you find a good restaurant in
  SFO you can let me know. And also tell too.

  - same email as last 2 years about moving ip into telco gear

  Good message to hammer home. However, it would be cool to see IP
  subsume ATM stuffs. And see apps and consumer products accelerate
  towards IP. Then TDM stuff naturally is optimized for IP more
  quickly. But the routers can handle it for the next 6-18 months.

  - really scared of loops because they bit him at sl/1239

  Haven't seen loops as a terrible problem. May be a difference in
  engineering style.

  - cost of ttl-able path important in ttl-able decision

  good point; sort of supports the user-configurable knob.

vadim - ng ip boxes obviate atm

  Not for a while. I think at NANOG you said we couldn't order your
  product yet? But I still have that ticket for that plane to

  - shameless plug for pluris causing clustering antiquity
  - NSPnet hub number decreasing

  Don't really buy this; physical space requirements and
  constraints demand more ubiquitous bw and geographic indifference.
  Whereas in the past people would consolidate and backhaul in few
  hubs, now folks are succesful and run out of
  space/power/foundation support. Maybe someday, but not for 2-3
  years, longer out than the next wave of ip buildouts.

  - wdm vendors don't like sonet

  Bet they don't tell Telco PL folks that :slight_smile:

  - ip over fiber solid engineering

  Agreed. Esp. with this nifty SONET on Router stuffs.

  - inet eng. harder than telco eng. as utilization is higher
    in inet eng.

  Agreed. Can't hammer this home hard enough.

hannigan@xcom - ss7 bypass (???)
stan@netmerc - atm not dead, still needs for cem and tdm stuffs
swb@newbridge - in '94 people had to patch unix hosts to raise ttl
    of ip packets

  Right. My fear is we build all these nifty SOIP (sonet over IP?)
  networks and noone shows up for the party, opting instead for
  expensive clunky IP over ATM providers because their TTLs are shiney and

  (obvious disclaimer - IP over ATM providers means IPonly networks
  that use ATM as a closed system transport mechanism for IP. I
  think the gang that thinks CUGs and NNI NSAP transport are growing
  will be shocked at the velocity of IP growth)

  - traceroute was hack
  - not everything in physical path must respond to trt

  So, all in all, we seem to have an implied concensus that:

  * The width of the Internet poses a problem for 'regular'
    IP traffic and conventions with an increase in IP hops.

    * NSP Network Providers should have the ability to unlink MPLS
    and IP TTls

  * IP is growing

  So, if we want this stuff to be useful (and prevent a cidr crisis)
  please help influence wgs to solve this problem in advance.

  Only you can help prevent TTL crises.