Re: [mpls] working group last call for draft-ietf-mpls-lsp-ping-mpls-tp-oam-conf

"Adrian Farrel" <adrian@olddog.co.uk> Wed, 08 April 2015 18:56 UTC

Return-Path: <adrian@olddog.co.uk>
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 964D11B350A for <mpls@ietfa.amsl.com>; Wed, 8 Apr 2015 11:56:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -99.9
X-Spam-Level:
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 mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gMv3pjzd9_GD for <mpls@ietfa.amsl.com>; Wed, 8 Apr 2015 11:56:53 -0700 (PDT)
Received: from asmtp3.iomartmail.com (asmtp3.iomartmail.com [62.128.201.159]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 6129D1B3506 for <mpls@ietf.org>; Wed, 8 Apr 2015 11:56:52 -0700 (PDT)
Received: from asmtp3.iomartmail.com (localhost.localdomain [127.0.0.1]) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id t38Iumq6016568; Wed, 8 Apr 2015 19:56:48 +0100
Received: from 950129200 (089144230255.atnat0039.highway.a1.net [89.144.230.255]) (authenticated bits=0) by asmtp3.iomartmail.com (8.13.8/8.13.8) with ESMTP id t38Iuk2C016549 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=NO); Wed, 8 Apr 2015 19:56:47 +0100
From: "Adrian Farrel" <adrian@olddog.co.uk>
To: "'Gregory Mirsky'" <gregory.mirsky@ericsson.com>, "'Ross Callon'" <rcallon@juniper.net>, <mpls@ietf.org>
References: <BY1PR0501MB143041FD755CA2819623985EA5180@BY1PR0501MB1430.namprd05.prod.outlook.com> <BY1PR0501MB14307B7B5965125211314F1FA5FE0@BY1PR0501MB1430.namprd05.prod.outlook.com> <032b01d07175$7a6535f0$6f2fa1d0$@olddog.co.uk> <7347100B5761DC41A166AC17F22DF1121B94362A@eusaamb103.ericsson.se>
In-Reply-To: <7347100B5761DC41A166AC17F22DF1121B94362A@eusaamb103.ericsson.se>
Date: Wed, 8 Apr 2015 19:56:50 +0100
Message-ID: <046401d0722d$c6e67070$54b35150$@olddog.co.uk>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQH1MtJuR9PoFq/Ikt5tBrpfIzTGugHj/uh8Ad/4fEgBVqFPUZzRHsEw
Content-Language: en-gb
X-TM-AS-MML: disable
X-TM-AS-Product-Ver: IMSS-7.1.0.1576-7.5.0.1018-21458.002
X-TM-AS-Result: No--10.363-10.0-31-10
X-imss-scan-details: No--10.363-10.0-31-10
X-TMASE-MatchedRID: QW5G6BKkLTotqx4vLVZ3FvHkpkyUphL9oprEeoZHCQJh2lxkfcGsFBr7 FyaVZKQrm0VAp0zzAIVjbqBQKsxALxerDOEQhKOMnbUZkYTzXIYkKs3LoBtQlRxUkJPe1WBqUpN 5b4Xd/F24PhLcqHA2WoR6ktsj4/uoxGtpMtFxybKNZ7kc4Uq+4+iY+s2L3xQEZ5yuplze9puuz4 mtMHP79GlLQc62MC4SugilbkAuMWXvkJu04PYxt/OHbIp2eXtYpwnFZnn+VHw3Z3efQH+wj53bq Ww72JHkD8fxgfysaI6Rk6XtYogiarQ/aqQZTRfKC24oEZ6SpSkj80Za3RRg8Ix/1d2MX54y1ZrG b+KZKdNf7vpwhSLPpuZzPO+SIFIBrW7Lspl6Tvo=
Archived-At: <http://mailarchive.ietf.org/arch/msg/mpls/fHXwAwc_adQ_rRHrCSXlf9Y9m40>
Cc: mpls-chairs@tools.ietf.org, draft-ietf-mpls-lsp-ping-mpls-tp-oam-conf@tools.ietf.org
Subject: Re: [mpls] working group last call for draft-ietf-mpls-lsp-ping-mpls-tp-oam-conf
X-BeenThere: mpls@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
Reply-To: adrian@olddog.co.uk
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: <http://www.ietf.org/mail-archive/web/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: Wed, 08 Apr 2015 18:56:55 -0000

Hi Greg,

[snip]

> You've suggested:
>       ". unassigned bits MUST be transmitted as zero and ignored on receipt ."
> in another discussion, it was pointed to me that "transmitted as zero and 
> ignored on receipt" for reserved fields or bits/flags is falling out of favor
as
> accepted form of expression. Would appreciate suggestions on how to
> improve it.

I guess I'm old so stuff I like falls out of favor all the time, but it doesn't
change my opinion :-)

Firstly, there is a difference between truly reserved fields, and fields that
are currently unassigned but which you expect to possibly assign one day.

In the former case, no-one really cares how the fields are set and, of course
(?) no-one will look at such fields.

In the latter case you need to be forward compatible. 
That means that an implementation that can process some new meaning of the
previously unused field must receive a value form a legacy implementation that
it will not misinterpret. The easiest way to handle this is to require legacy
implementations to transmit zero - then the new meaning of the field can include
"zero means not supported".
Similarly, a legacy implementation that receives a non-setting (from a new
implementation) needs to not barf. The easiest way is to simply ignore the
fields that are believed to be unused.

None of this means that a legacy implementation should police the setting of
zero in an unused field it received. Indeed, although it could police the
sender's adherence to "MUST be zero" is should not do so because it is not
supposed to look at the field at all.

Maybe you need to be asking the person who suggested that the concept is falling
out of favor. They might have a suggestion.

A