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

Eric Gray <eric.gray@ericsson.com> Mon, 20 November 2017 16:31 UTC

Return-Path: <eric.gray@ericsson.com>
X-Original-To: mpls@ietfa.amsl.com
Delivered-To: mpls@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 59EEB129B60 for <mpls@ietfa.amsl.com>; Mon, 20 Nov 2017 08:31:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Uj2mtqtjcqYR for <mpls@ietfa.amsl.com>; Mon, 20 Nov 2017 08:31:13 -0800 (PST)
Received: from usplmg21.ericsson.net (usplmg21.ericsson.net [198.24.6.65]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6E9A51294A3 for <mpls@ietf.org>; Mon, 20 Nov 2017 08:31:13 -0800 (PST)
X-AuditID: c6180641-81dff70000007a40-3a-5a130350f471
Received: from EUSAAHC006.ericsson.se (Unknown_Domain [147.117.188.90]) by usplmg21.ericsson.net (Symantec Mail Security) with SMTP id 98.EE.31296.053031A5; Mon, 20 Nov 2017 17:31:12 +0100 (CET)
Received: from EUSAAMB107.ericsson.se ([147.117.188.124]) by EUSAAHC006.ericsson.se ([147.117.188.90]) with mapi id 14.03.0352.000; Mon, 20 Nov 2017 11:31:12 -0500
From: Eric Gray <eric.gray@ericsson.com>
To: Sandra Murphy <sandy@tislabs.com>
CC: "mpls@ietf.org" <mpls@ietf.org>
Thread-Topic: [mpls] RFC5036 and "exceeds" / "reaches" limits on send and receive
Thread-Index: AQHTXcN2Hpl4qjm+M0Gozg4e8MxjDKMddVEw
Date: Mon, 20 Nov 2017 16:31:11 +0000
Message-ID: <48E1A67CB9CA044EADFEAB87D814BFF64B89673D@eusaamb107.ericsson.se>
References: <4E4D0B0B-4E7F-45F7-BD6E-F00245B16226@tislabs.com>
In-Reply-To: <4E4D0B0B-4E7F-45F7-BD6E-F00245B16226@tislabs.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [147.117.188.9]
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrNLMWRmVeSWpSXmKPExsUyuXRPlG4As3CUwce9eha3lq5ktZhwaTqz A5PHkiU/mTx+dMxiCWCK4rJJSc3JLEst0rdL4Mr4saiTuWCLWcWP3f9YGhgbTLsYOTkkBEwk Tq9tYwWxhQSOMEq8+ZvXxcgFZC9nlHg5aRMbSIJNQEPi2J21jCC2iICqxIlTa4AaODiYBZQl Tt2VAQkLCwRJrD50hhWiJFii+fpZZgjbSGLa7d9gY1iAWvfc2Qpm8wr4SsxecIIZZIyQgJ3E p4sZIGFOAXuJBZdfgrUyCohJfD+1hgnEZhYQl7j1ZD4TxMkCEkv2nGeGsEUlXj7+xwphK0rs 65/ODnGZpsT6XfoQrYoSU7ofskNsFZQ4OfMJywRG0VlIps5C6JiFpGMWko4FjCyrGDlKiwty ctONDDcxAqPgmASb4w7Gvb2ehxgFOBiVeHhz3wpFCbEmlhVX5h5ilOBgVhLhVYsCCvGmJFZW pRblxxeV5qQWH2KU5mBREuc958kbJSSQnliSmp2aWpBaBJNl4uCUamDkuHzifN++WWHTzEzj nacy3P6x+JhUq5PQhKtztH8LOArNeW2U0W/yPLZ431fVKLYjzceVHAs4s/+cCzSx3R9g53Ei ovTxhVf3Pz7WFNu3sefMAd679/l+nd9tMV1rxsXudZzfyrxr76Y91uGICXO/p2csd05aQypw XdzO9U2P/EItpTdHri1UYinOSDTUYi4qTgQAJBRnkn4CAAA=
Archived-At: <https://mailarchive.ietf.org/arch/msg/mpls/sQQlEXgjqxPZFXzcaDVSDRzWoL0>
Subject: Re: [mpls] RFC5036 and "exceeds" / "reaches" limits on send and receive
X-BeenThere: mpls@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Multi-Protocol Label Switching WG <mpls.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mpls>, <mailto:mpls-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/mpls/>
List-Post: <mailto:mpls@ietf.org>
List-Help: <mailto:mpls-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mpls>, <mailto:mpls-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 20 Nov 2017 16:31:15 -0000

Sandy,

	To answer the part of your question regarding whether the maximum (less than or equal to 255) could ever be exceeded, yes it could.  The procedure was written to support any non-zero maximum less than the maximum value possible.  However, it should say "that is greater than or equal to" the configured maximum, rather than "that exceeds" it.  

	I would be a bit surprised to discover that there are implementations where the implementer has not worked that out, but it is possible.  With loop-detection enabled, if you check to see if the received hop count is greater than or equal to the configured maximum, the test would detect the condition, even if the maximum was set to 255.

	In a manner of speaking - since the text 3.4.5.1.1 uses "reached" with respect to "maximum Hop Count limit" - one could argue that "greater than or equal to" is implicit.  Since Loop detection is only enabled if using Path Vectors, this check would be performed if attempting to detect a loop during setup.

	Note that an implementation can easily avoid this situation by treating any attempt to set a maximum value greater than MAX-Field-Value-minus-one as an error.

--
Eric Gray

-----Original Message-----
From: mpls [mailto:mpls-bounces@ietf.org] On Behalf Of Sandra Murphy
Sent: Tuesday, November 14, 2017 10:40 PM
To: mpls@ietf.org
Cc: Sandra Murphy <sandy@tislabs.com>
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.

Thanks.

—Sandy

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 3.4.4.1, 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 3.4.5.1.1, p 42

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

      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
mpls@ietf.org
https://www.ietf.org/mailman/listinfo/mpls