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, hopefully.
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 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@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@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 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