North American Network Operators Group

Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical

Internet Diameter and TTL decrementing Followup

  • From: alan
  • Date: Wed Mar 25 11:44:07 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.

> [email protected] - 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
> 		[email protected]/l3 hops desired from vendors

	Agreed.  Eloquently stated as always.

> [email protected] - 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.

> [email protected] - 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: [email protected])
> 	- leave decision about ttl decrementing to provider
> [email protected] - 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.

> [email protected] - 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 [email protected] 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.

> [email protected] - ss7 bypass (???)
> [email protected] - atm not dead, still needs for cem and tdm stuffs
> [email protected] - 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