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

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

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/14.3.2.130206
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
Precedence: list

Sasha, Adrian -

In the abstract this document claims to "clarify" RFC5586.  However it
actually modifies the behavior in two ways.

First in section 4.2.1.1, 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
"examining".

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

George

[mpls] New I-D draft-vainshtein-mpls-gal-tc-ttl-h… Adrian Farrel
Re: [mpls] New I-D draft-vainshtein-mpls-gal-tc-t… Andrew G. Malis
Re: [mpls] New I-D draft-vainshtein-mpls-gal-tc-t… Shah, Himanshu
Re: [mpls] New I-D draft-vainshtein-mpls-gal-tc-t… Huub van Helvoort
Re: [mpls] New I-D draft-vainshtein-mpls-gal-tc-t… Adrian Farrel
Re: [mpls] New I-D draft-vainshtein-mpls-gal-tc-t… Dongjie (Jimmy)
Re: [mpls] New I-D draft-vainshtein-mpls-gal-tc-t… Adrian Farrel
[mpls] draft-vainshtein-mpls-gal-tc-ttl-handling-… George Swallow (swallow)
Re: [mpls] draft-vainshtein-mpls-gal-tc-ttl-handl… Rolf Winter
Re: [mpls] draft-vainshtein-mpls-gal-tc-ttl-handl… Alexander Vainshtein
Re: [mpls] draft-vainshtein-mpls-gal-tc-ttl-handl… George Swallow (swallow)
Re: [mpls] draft-vainshtein-mpls-gal-tc-ttl-handl… Rolf Winter
Re: [mpls] draft-vainshtein-mpls-gal-tc-ttl-handl… Adrian Farrel