Re: [mpls] draft-vainshtein-mpls-gal-tc-ttl-handling-00.txt
Rolf Winter <Rolf.Winter@neclab.eu> Fri, 24 July 2015 09:23 UTC
Return-Path: <Rolf.Winter@neclab.eu>
X-Original-To: mpls@ietfa.amsl.com
Delivered-To: mpls@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4DAE61A88E1 for <mpls@ietfa.amsl.com>; Fri, 24 Jul 2015 02:23:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.612
X-Spam-Level:
X-Spam-Status: No, score=-2.612 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
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 09007kM0wOmf for <mpls@ietfa.amsl.com>; Fri, 24 Jul 2015 02:23:52 -0700 (PDT)
Received: from mailer1.neclab.eu (mailer1.neclab.eu [195.37.70.40]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6D9F91A8845 for <mpls@ietf.org>; Fri, 24 Jul 2015 02:23:52 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mailer1.neclab.eu (Postfix) with ESMTP id DEF9410A40C; Fri, 24 Jul 2015 11:23:50 +0200 (CEST)
X-Virus-Scanned: Amavisd on Debian GNU/Linux (netlab.nec.de)
Received: from mailer1.neclab.eu ([127.0.0.1]) by localhost (atlas-a.office.hd [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dxEYQbgSKagY; Fri, 24 Jul 2015 11:23:50 +0200 (CEST)
X-ENC: Last-Hop-TLS-encrypted
X-ENC: Last-Hop-TLS-encrypted
Received: from ENCELADUS.office.hd (enceladus.office.hd [192.168.24.52]) (using TLSv1 with cipher AES128-SHA (128/128 bits)) (No client certificate requested) by mailer1.neclab.eu (Postfix) with ESMTPS id BA52210A40B; Fri, 24 Jul 2015 11:23:40 +0200 (CEST)
Received: from HYDRA.office.hd ([169.254.4.41]) by ENCELADUS.office.hd ([192.168.24.52]) with mapi id 14.03.0210.002; Fri, 24 Jul 2015 11:23:40 +0200
From: Rolf Winter <Rolf.Winter@neclab.eu>
To: Alexander Vainshtein <Alexander.Vainshtein@ecitele.com>
Thread-Topic: draft-vainshtein-mpls-gal-tc-ttl-handling-00.txt
Thread-Index: AQHQr17KwZBID3vsg0edcC6q5VGWJJ3nUE3AgAAMGgCAAyf6UA==
Date: Fri, 24 Jul 2015 09:23:39 +0000
Message-ID: <791AD3077F94194BB2BDD13565B6295D99DCC97D@Hydra.office.hd>
References: <040c01d09c3f$2f060220$8d120660$@olddog.co.uk> <D1B17EC7.3B759%swallow@cisco.com> <791AD3077F94194BB2BDD13565B6295D99DB996E@PALLENE.office.hd> <DB3PR03MB07804F02663E85853D5AB5059D830@DB3PR03MB0780.eurprd03.prod.outlook.com>
In-Reply-To: <DB3PR03MB07804F02663E85853D5AB5059D830@DB3PR03MB0780.eurprd03.prod.outlook.com>
Accept-Language: en-US, de-DE
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.7.0.204]
Content-Type: text/plain; charset="iso-8859-2"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <http://mailarchive.ietf.org/arch/msg/mpls/9H4kt2H2jWkSJfqAwExD64jNRqg>
Cc: 'Loa Andersson' <loa@mail01.huawei.com>, "mpls@ietf.org" <mpls@ietf.org>
Subject: Re: [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: Fri, 24 Jul 2015 09:23:55 -0000
See inline [things we agree on snipped] NEC Europe Ltd | Registered Office: Athene, Odyssey Business Park, West End Road, London, HA4 6QE, GB | Registered in England 2832014 > b) when the GAL is used for section OAM, then setting the TTL to 1 is > necessary as it is used for addressing. > > This is a noteworthy exception to the rule outlined in the document. > > [[Sasha]] I may be missing something but I do not really understand why > such an exception is required. > > I assume that by "Section OAM" you refer to the case when the top LSE > in the label stack contains GAL. > > If this is correct, then this LSE (being the top one) would be > examined by the LSR at the other end of the data link, and the packet > immediately identified as an OAM packet based on the fact that the > examined LSE contains GAL. Further disposition of this packet would be > then decided by the packet type as encoded in the GACH and, if > necessary, buy packet type-specific means. This would happen regardless > of the TTL value in this LSE. Setting it to 1 should not really change > anything IMHO. Well, the TTL is being used here for addressing and you want to change these semantics. Architecturally, this doesn't seem right. If "just look at the label" is a valid fix to the problem, why not fixing the receivers that have the problem. Why changing all the senders? > > > > Generally, the proposal begs the question "why having all senders > change when the problem seems to be in some receivers". > > > > Best, > > > > Rolf > > > > > > > > > > > > NEC Europe Ltd | Registered Office: Athene, Odyssey Business Park, West > End Road, London, HA4 6QE, GB | Registered in England 2832014 > > > > > -----Original Message----- > > > From: mpls [mailto:mpls-bounces@ietf.org <mailto:mpls- > bounces@ietf.org> ] On Behalf Of George Swallow > > > (swallow) > > > Sent: Donnerstag, 25. Juni 2015 17:51 > > > To: adrian@olddog.co.uk <mailto:adrian@olddog.co.uk> ; Alexander > Vainshtein; mpls@ietf.org <mailto:mpls@ietf.org> > > > Cc: 'Loa Andersson' > > > Subject: [mpls] draft-vainshtein-mpls-gal-tc-ttl-handling-00.txt > > > > > > 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 mailing list > > > mpls@ietf.org <mailto:mpls@ietf.org> > > > https://www.ietf.org/mailman/listinfo/mpls > <https://www.ietf.org/mailman/listinfo/mpls>
- [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