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

"George Swallow (swallow)" <swallow@cisco.com> Thu, 25 June 2015 15:51 UTC

Return-Path: <swallow@cisco.com>
X-Original-To: mpls@ietfa.amsl.com
Delivered-To: mpls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com []) by ietfa.amsl.com (Postfix) with ESMTP id A03721A026C for <mpls@ietfa.amsl.com>; Thu, 25 Jun 2015 08:51:10 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.511
X-Spam-Status: No, score=-14.511 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from mail.ietf.org ([]) by localhost (ietfa.amsl.com []) (amavisd-new, port 10024) with ESMTP id BAV93ntpF5C9 for <mpls@ietfa.amsl.com>; Thu, 25 Jun 2015 08:51:09 -0700 (PDT)
Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com []) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5980D1A0105 for <mpls@ietf.org>; Thu, 25 Jun 2015 08:51:09 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1686; q=dns/txt; s=iport; t=1435247469; x=1436457069; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=LTFEuMmtlwejDe/WkkS1euIeathgY4lH+rGREk2Bc3w=; b=QoNRND3ebEZEiOvKX6sZpg6Wbu+yDCk50tkmRvZRgHjZiCCaLLQNAnOZ NPJ7adJyOQsOHKJjtv795y2GhLyuroTCrYk4k1JoudUNMyoVG3agUwUpV fHFO+wMmbYMcM001ATB8odObHfbEHoKBi3AxUPjuYI4KHGNjdUInlMDaJ w=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos;i="5.13,677,1427760000"; d="scan'208";a="10296938"
Received: from rcdn-core-4.cisco.com ([]) by rcdn-iport-1.cisco.com with ESMTP; 25 Jun 2015 15:51:08 +0000
Received: from xhc-rcd-x04.cisco.com (xhc-rcd-x04.cisco.com []) by rcdn-core-4.cisco.com (8.14.5/8.14.5) with ESMTP id t5PFp8oI019652 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 25 Jun 2015 15:51:08 GMT
Received: from xmb-rcd-x10.cisco.com ([]) by xhc-rcd-x04.cisco.com ([]) with mapi id 14.03.0195.001; Thu, 25 Jun 2015 10:51:08 -0500
From: "George Swallow (swallow)" <swallow@cisco.com>
To: "adrian@olddog.co.uk" <adrian@olddog.co.uk>, Alexander Vainshtein <Alexander.Vainshtein@ecitele.com>, "mpls@ietf.org" <mpls@ietf.org>
Thread-Topic: draft-vainshtein-mpls-gal-tc-ttl-handling-00.txt
Thread-Index: AQHQr17AxQO7YSp/ukO2atFhipP6qA==
Date: Thu, 25 Jun 2015 15:51:08 +0000
Message-ID: <D1B17EC7.3B759%swallow@cisco.com>
In-Reply-To: <040c01d09c3f$2f060220$8d120660$@olddog.co.uk>
Accept-Language: en-US
Content-Language: en-US
user-agent: Microsoft-MacOutlook/
x-originating-ip: []
Content-Type: text/plain; charset="Windows-1252"
Content-ID: <FE802374771BE24FB61CC079D6796652@emea.cisco.com>
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/mpls/5wKWnw1FXPEeeZ5Az73ttH0WpLw>
Cc: 'Loa Andersson' <loa@mail01.huawei.com>
Subject: [mpls] draft-vainshtein-mpls-gal-tc-ttl-handling-00.txt
X-BeenThere: mpls@ietf.org
X-Mailman-Version: 2.1.15
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: Thu, 25 Jun 2015 15:51:10 -0000

Sasha, Adrian -

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".

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.

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.
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."

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

Something like "MUST not discard Š based on a TTL value of 1 or more."