Internet Diameter and TTL decrementing Followup
alan at isi.net
alan at isi.net
Wed Mar 25 07:29:57 UTC 1998
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 at 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 at l2/l3 hops desired from vendors
Agreed. Eloquently stated as always.
> pee at 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,
hopefully.
> pferguso at 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 at xcom)
> - leave decision about ttl decrementing to provider
> nshen at 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 at 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
> required
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
shareholders?).
> - 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 pee at frontiernet.net 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
mars...
> - 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 :-)
> - 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 at xcom - ss7 bypass (???)
> stan at netmerc - atm not dead, still needs for cem and tdm stuffs
> swb at 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
new.
(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.
-a
More information about the NANOG
mailing list