Re: [mpls] RFC5036 and "exceeds" / "reaches" limits on send and receive

Eric Gray <> Mon, 20 November 2017 15:55 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id E03B9129B36 for <>; Mon, 20 Nov 2017 07:55:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id pmxucLlJ7mQD for <>; Mon, 20 Nov 2017 07:55:17 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id C6593129B22 for <>; Mon, 20 Nov 2017 07:55:17 -0800 (PST)
X-AuditID: c6180641-bf5e19c000007a40-33-5a12fae5729a
Received: from (Unknown_Domain []) by (Symantec Mail Security) with SMTP id E8.5C.31296.5EAF21A5; Mon, 20 Nov 2017 16:55:17 +0100 (CET)
Received: from ([]) by ([]) with mapi id 14.03.0352.000; Mon, 20 Nov 2017 10:55:16 -0500
From: Eric Gray <>
To: Sandra Murphy <>
CC: "" <>
Thread-Topic: [mpls] RFC5036 and "exceeds" / "reaches" limits on send and receive
Thread-Index: AQHTXcN2Hpl4qjm+M0Gozg4e8MxjDKMdavsw
Date: Mon, 20 Nov 2017 15:55:15 +0000
Message-ID: <>
References: <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrFLMWRmVeSWpSXmKPExsUyuXRPrO7TX0JRBn0/hS1uLV3JajHh0nRm ByaPJUt+Mnn86JjFEsAUxWWTkpqTWZZapG+XwJXx6tEJtoImt4qGdzfYGhjnuHQxcnJICJhI XNr8hhnEFhI4wijxZYNSFyMXkL2cUeLAmz8sIAk2AQ2JY3fWMoLYIgKqEidOrWHtYuTgYBZQ ljh1VwYkLCwQJLH60BlWiJJgiebrZ5lBSkQEjCT2LuMGCbMAdU6f1MQOYvMK+Er0TZrCDlIi JGAn8eliBkiYU8BeYsHll2DXMAqISXw/tYYJxGYWEJe49WQ+E8TFAhJL9pxnhrBFJV4+/scK YStK7Oufzg5xmKbE+l36EK2KElO6H0JtFZQ4OfMJywRG0VlIps5C6JiFpGMWko4FjCyrGDlK iwtyctONDDcxAmPgmASb4w7Gvb2ehxgFOBiVeHhz3wpFCbEmlhVX5h5ilOBgVhLhVYsCCvGm JFZWpRblxxeV5qQWH2KU5mBREuc958kbJSSQnliSmp2aWpBaBJNl4uCUamDM+afn5lMalrt5 nmu5RU3aD4eHsh8KuHki8/T+H3nzhfG2MNcLtrRwo0m6Kdvd2jumtL5z6fxinn1xZ/jCrcbO P7/O/PXLImfqnC0Bs5+7O6112b/8fMXk9xcuzOT90OzqKyro1K/yUPbplhrNl+vzzxX5eT08 kpaXMWlf6QLByMJrrHGPdqQrsRRnJBpqMRcVJwIAEonEFn0CAAA=
Archived-At: <>
Subject: Re: [mpls] RFC5036 and "exceeds" / "reaches" limits on send and receive
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Multi-Protocol Label Switching WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 20 Nov 2017 15:55:20 -0000


	There is some inconsistency in the handling of Hop Count TLV  "greater than configured maximum" and a Path Vector TLV greater than Path Vector Limit (PVLim).

	However, there is some justification for this.  

	Ideally, the Hop Count TLV "configured maximum" should be the same for all LSRs in a network, but - even if that is not the case - there is no particular reason to check it twice.  In this respect "hop count" is treated in a similar fashion to TTL.

	As a side note, the difference is that TTL (at one time) counted both the time that a packet "resided" on a forwarding device and the fact that it resided _at all_ on the device - hence the processing rule that TTL would be bumped up by at least 1 at each hop.  The "time" that a packet lived in the network in the days of relative "slow forwarding" was also important. 

	In today's forwarding devices, an IP packet would be considered extremely stale if it spent more than a second at any single forwarding device - hence bumping TTL by more than 1 at a forwarder might still happen, but would not typically happen as a result of multi-second latency.

	Hop count, on the other hand, counts only the hops on a path - mostly because it is part of a control message, so the time it takes is not as relevant.  Whether it is actually bumped and checked at ingress or egress is not even externally visible - though checking at ingress saves both resources (not using fabric slots only to discard after doing so) and complexity (since discard requires returning a control message to the sender - which is often easier at ingress).

	Note that - in the common case where hop count limit is configured consistently in a network - checking before bumping hop count would result in a control packet going one additional hop in comparison  with checking it after bumping hop count.  Even a very badly configured case, the packet would make at most one additional circuit around the loop before being discarded and reported.

	Since the intention with TTL was (originally at least) to take into account both the hop and the time a packet spent at the hop, it should be bumped and checked on leaving the hop.

	The Path Vector Limit is different.  A Path Vector TLV grows with each hop that a control message traverses.  Therefore the vector limit should be checked at any point where the resulting Path Vector size might be a problem.  Since not every control message traverses the same hardware, it makes sense to recognize that there might be different limits established at different places - both within a device and within a network.

Eric Gray


-----Original Message-----
From: mpls [] On Behalf Of Sandra Murphy
Sent: Tuesday, November 14, 2017 10:40 PM
Cc: Sandra Murphy <>
Subject: [mpls] RFC5036 and "exceeds" / "reaches" limits on send and receive

I am reading RFC5036, the LDP spec.

I’m finding the language about the loop detection to be a bit ambiguous.

The text varies as to whether a loop is detected when something “exceeds” the limit or when something “reaches” the limit.

Some examples below.

I read the algorithms in the Appendix as requiring a check for “exceeds” on receipt, but no check for either “exceeds” or “reaches” on send. I don’t see a requirement when sending any message to check the hop count or the path vector length to see if it has reached/exceeded the limit.  [The Appendix A procedure descriptions are said to take precedence over any description in the text.]

Does that mean that an LSR might send a message that was doomed to be rejected upon receipt?  Is that the intent?

For the hop count in particular - the hop count field, if I read the spec correctly, is one octet, so a maximum value of 255.  I have not found a requirement that the “configured maximum value” for the hop count MUST be strictly less than the Hop Count TLV’s largest possible hop count value.

So if an LSR is propagating a Label Request message that had a hop count of 255, it should increment the hop count when sending to its neighbor.  What happens then - what value is sent?  I don’t see this covered in the Appendix’s algorithms, and the text is ambiguous.

If an LSR is checking to see if a received message’s Hop Count TLV has a HC Value that exceeds the “configured maximum value”, and the configured maximum value is configured to be 255, would the test ever succeed?

I figure I’ve missed something fundamental, as implementors would have to have figured this out.  And the usual configured maximum values are not going to push either limit.  But still, it would be good to understand.



Some examples of “exceeds” and “reaches”

Section 2.8.2, p 26

      If R receives a Label Mapping message from its next hop with a Hop
      Count TLV that exceeds the configured maximum value, or with a
      Path Vector TLV containing its own LSR Id or that exceeds the
      maximum allowable length, then R detects that the corresponding
      LSP contains a loop.

Section, p 40

   If an LSR receives a message containing a Hop Count TLV, it MUST
   check the hop count value to determine whether the hop count has
   exceeded its configured maximum allowable value.  If so, it MUST
   behave as if the containing message has traversed a loop by sending a
   Notification message signaling Loop Detected in reply to the sender
   of the message.

Section 2.8, p 23

                                               an LSR that detects a
         Path Vector has reached the maximum length behaves as if the
         containing message has traversed a loop.

         An LSR that detects a Hop Count has reached a configured
         maximum value behaves as if the containing message has
         traversed a loop.

<In this case, there’s no indication if the LSR is checking the maximum on receipt of a message or on sending after having incremented the value.>

Section, p 42

   Note that a Label Request message with a Path Vector TLV is forwarded

      1. A loop is found,

      2. The LSP egress is reached, or

      3. The maximum Path Vector limit or maximum Hop Count limit is
         reached.  This is treated as if a loop had been detected.
mpls mailing list