Re: [mpls] draft-vainshtein-mpls-gal-tc-ttl-handling-00.txt

"Adrian Farrel" <> Tue, 04 August 2015 12:22 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 0D5FF1A87C7 for <>; Tue, 4 Aug 2015 05:22:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -99.9
X-Spam-Status: No, score=-99.9 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_LOW=-0.7, USER_IN_WHITELIST=-100] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id nwBZ3pDMy-Uk for <>; Tue, 4 Aug 2015 05:22:05 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 386041A87A3 for <>; Tue, 4 Aug 2015 05:22:04 -0700 (PDT)
Received: from (localhost.localdomain []) by (8.13.8/8.13.8) with ESMTP id t74CLxOs010135; Tue, 4 Aug 2015 13:21:59 +0100
Received: from 950129200 ([]) (authenticated bits=0) by (8.13.8/8.13.8) with ESMTP id t74CIwHS009109 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Tue, 4 Aug 2015 13:21:33 +0100
From: Adrian Farrel <>
To: "'George Swallow (swallow)'" <>, 'Alexander Vainshtein' <>,
References: <040c01d09c3f$2f060220$8d120660$> <>
In-Reply-To: <>
Date: Tue, 04 Aug 2015 13:21:10 +0100
Message-ID: <031501d0ceb0$27ee02a0$77ca07e0$>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-2"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQDeK6uhM5RTLptNbvuboWUvixs2DJ/g9v2g
Content-Language: en-gb
X-TM-AS-MML: disable
X-TM-AS-Product-Ver: IMSS-
X-TM-AS-Result: No--7.736-10.0-31-10
X-imss-scan-details: No--7.736-10.0-31-10
X-TMASE-MatchedRID: xcONGPdDH5oRqNE+xcwLcL2xWbKjBfWPDYBVKmbeeQP/sy54VckvQ8Wl hj9iHeVpx4LeUhj/avTPo5bRzwAwzgWS5qt0WAhHLi5PDX0qWHo6QNs2WCY79RT++WnU8gyJTak PH+NO07HiT/ogpGqzgr+ZRx3n+HfgnVURoFo9SBz0hv/rD7WVZCQwGQSJ46NmNicYKk+uuBLBky pSI9hPzT1M3SaFgxRcIU9/dutw9uWjhdS4y9NWlHI4Qn4tV3Ttg99C97sXB8AKl9B2iIGyflriq BLx+uYbeJq1aaoimpj/tdOuViNvuAtrOhDKumbStLDu9qtqKeEKajiKVoihqXRBu8vg+6OQoXrT 0auYLu05KN/N7BG0NKJtjVoePu+qCiwghyPO0y4zSlmIs9AhOiH2Y0Xxk8nYSYPLE090cxcaIAs D6TcJWYrwsLCUwXL+/Sj/WnCM/LNrLhXNtOJWGFZ0V5tYhzdWxEHRux+uk8jHUU+U0ACZwH/KrJ K/Zm+PlSSlLKnMcx0knATmEr423crzfggWW+z8nqg/VrSZEiM=
Archived-At: <>
Cc: 'Loa Andersson' <>
Subject: Re: [mpls] draft-vainshtein-mpls-gal-tc-ttl-handling-00.txt
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Multi-Protocol Label Switching WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 04 Aug 2015 12:22:07 -0000

Hi George,

Closing the loop on this after several email exchanges.

> In the abstract this document claims to "clarify" RFC5586.  However it
> actually modifies the behavior in two ways.
> First in section, RFC5586 states:
>   The TTL field of the GAL LSE MUST be set to at least 1.
> This can equally be stated as "MUST NOT set the TTL to 0.  However this
> document changes that to "SHOULD NOT".  I see absolutely no reason for
> this change.
> Second, as per 5586 a receiver that discarded a received GAL with TTL=0
> was not out of compliance with that rfc.  Now you say that a receiver that
> a receiver "that examines an LSE that contains the GAL MUST ignore the
> value of the TTL field".

Compliance and conformance to RFCs has never been something that I have been
enthusiastic about. Especially not being out of compliance by not doing

Our aim here is not to set more rules for measuring compliance, but to increase
the chance of interoperability in the future.

And let's understand that nothing we write can in any way change whether an
implementation is compliant to 5586 since that document is already published.

> So a piece of hardware, say an ASIC, was designed years ago to discard
> packets with a TTL of 0 in the top label is now out of compliance whereas
> in RFC5586 the fault in this situation would lie clearly with the sender.

The fault continues to lie with the sender. However, being able to point a
finger and say "the sender is broken" doesn't really help deployments. The aim
is for new implementations to be allowed to process correctly despite the faults
of the sender.

> Now suppose further that our ASIC is also programmed to put packets with a
> TTL of 1 in the top label on the slow path.  Here the ASIC is not ignoring
> the TTL value - it is making a decision based on it.  It is, however,
> still enabling a CP or RP to process the GAL.  This, of course, may not be
> optimal, but it should not be illegal.

Indeed. Let us hope that Warren's Internet Police do not descend on us!

> So how about we say that "the LER that originates the G-ACh packet SHOULD
>    NOT set this value to 1 and MUST NOT set this value to 0."

You're right about this and we have moved to "MUST NOT 0 and SHOULD NOT 1"

> For the receiver, I think it suffices to say "SHOULD ignore the value of
> the TTL field".  But if you want to work a MUST into the language - its
> scope should not include the value 0 and the language should not be about
> "examining".
> Something like "MUST not discard Š based on a TTL value of 1 or more."

"An LER that examines an LSE that contains the GAL SHOULD ignore the value of
the TTL field, and MUST NOT discard the packet based on the value of the TTL


PS Response to Rolf's addendum to this thread comes in a separate email.