[mpls] Off-Topic (was RE: Working Group Las Call on draft-ietf-mpls-tp- on-demand-cv-03)

Sasha,

	This is definitely starting to wander off-topic.

	I'm pretty sure that particular aspect of the diagrams 
is intended as an example.

	It is clearly possible that TTL may be decremented by
more than one by something that otherwise looks like one
forwarding device. 

	One of the continuing issues with using ASCII art in
figures is that it is relatively painful to represent the
symbol for "greater-than-or-equal-to", so people frequently
use the path of least resistance and use "=" instead...  

	I am also pretty sure that it is a generic abuse of TTL 
to use it to try to infer the number of devices on a path.

	This could be a problem if you have a sender that uses
their "knowledge" of the network topology to set a starting
TTL value.  I think this would be a mistake, but it should 
be a correctable mistake and it would certainly be an easily
detectable problem.

	One (really old, so I may be dating myself) example of
a very reasonable case for decrementing by more than one at
a forwarder is if that forwarder is using a low-speed link
to forward.  In this case, a relatively small number of PDUS
can completely consune the available bandwidth on that link
if allowed to re-traverse the link a significant number of 
times.

	I have certainly run trace-route in the past and seen
the same node show up more than once in the path (which is
an indication that the node decrements TTL by more than one.

	Originally (really dating myself now), it was also an
explicit requirement that a device would decrement TTL by 
the larger of "1", or the number of seconds that packet was
queued while being processed by the device.  At today's line
rates, this is not a realistic consideration unless a device
has an outrageously huge set of packet buffers, however.

	But it might not be unreasonable for a device to use a
higher value than one to decrement TTL in cases where a set 
of packets are experiencing unusually long processing delays,
as this might have something to do with congestion and a
larger decrement for queues experiencing congestion would
"punish" looping traffic more severely than other traffic.

--
Eric

-----Original Message-----
From: Alexander Vainshtein [mailto:Alexander.Vainshtein@ecitele.com] 
Sent: Tuesday, March 29, 2011 4:17 AM
To: Eric Gray
Cc: mpls@ietf.org; Rolf Winter; Sami Boutros; hideki.endo.es@hitachi.com
Subject: RE: [mpls] Working Group Las Call on draft-ietf-mpls-tp- on-demand-cv-03
Importance: High

Eric, and all,
I suggest that we should look at the diagrams in RFC 3443.
They explicitly show that TTL is decremented by 1 by each LSR that the MPLS packet crosses... 

Regards,
     Sasha

> -----Original Message-----
> From: mpls-bounces@ietf.org [mailto:mpls-bounces@ietf.org] On Behalf Of
> Eric Gray
> Sent: Tuesday, March 29, 2011 10:04 AM
> To: Rolf Winter; Sami Boutros; hideki.endo.es@hitachi.com
> Cc: mpls@ietf.org
> Subject: Re: [mpls] Working Group Las Callondraft-ietf-mpls-tp- on-
> demand-cv-03
> 
> Rolf,
> 
> 	There is no case here to support your argument that TTL is
> always only decremented by one.  We should discuss this (as has
> been proposed), however - if you read the Routing Requirements
> RFC (RFC 1812) - you will find that the actual requirement is for
> a "forwarder" to decrement TTL "by at least one."
> 
> 	I can think of several scenarios where a single forwarder
> might be configured to decrement TTL by more than one for some
> set of packets.
> 
> --
> Eric
> 
> -----Original Message-----
> From: Rolf Winter [mailto:Rolf.Winter@neclab.eu]
> Sent: Tuesday, March 29, 2011 3:25 AM
> To: Sami Boutros; hideki.endo.es@hitachi.com; Eric Gray
> Cc: mpls@ietf.org
> Subject: RE: [mpls] Working Group Las Callondraft-ietf-mpls-tp- on-
> demand-cv-03
> Importance: High
> 
> Hi Sami,
> 
> see inline.
> 
> NEC Europe Limited | Registered Office: NEC House, 1 Victoria Road,
> London W3 6BL | Registered in England 2832014
> 
> >
> > Keep in mind that a node decrement TTL once, and
> > this per-interface MIP seems to require a node to decrement twice..
> >
> > Thanks,
> >
> 
> I don't think this is a good idea. This is not how the TTL works today.
> I think this is very unwise and touching a pretty fundamental principle
> here. FWIW, we have proposed an alternative and presented it the last
> IETF. Unfortunately, we have received little feedback on it. But I
> think the discussion we have right now is good and not too late. The
> OAM framework document includes per-interface MIPs and I think the
> group needs to start thinking hard now to make sure this is thought
> about before we finish off all these OAM tools. This way we do not need
> to come back later and change things. I don't think it will be overly
> hard, we just need to agree on something.
> 
> Best,
> 
> Rolf
> 
> _______________________________________________
> mpls mailing list
> mpls@ietf.org
> https://www.ietf.org/mailman/listinfo/mpls