Re: [Idr] [bess] draft-rosen-mpls-rfc3107bis

Eric C Rosen <erosen@juniper.net> Tue, 05 April 2016 14:26 UTC

Return-Path: <erosen@juniper.net>
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1D96712D17D; Tue, 5 Apr 2016 07:26:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.902
X-Spam-Level:
X-Spam-Status: No, score=-1.902 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=junipernetworks.onmicrosoft.com
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 sQrn2R-9eXmM; Tue, 5 Apr 2016 07:26:11 -0700 (PDT)
Received: from na01-bn1-obe.outbound.protection.outlook.com (mail-bn1on0727.outbound.protection.outlook.com [IPv6:2a01:111:f400:fc10::727]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E6E1412D11B; Tue, 5 Apr 2016 07:26:10 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=junipernetworks.onmicrosoft.com; s=selector1-juniper-net; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=RZyB2y8DIjjN5bD/EVTIwcP6LAyUnLEVzNo3nFdymrM=; b=IFbjN2kO8B4EtKVt/+i4Cm9K+BP6cLMlrjbYTS3EBC8UPbC6HJgQbpo0dqLZP8EGFWzpSZkKeu546cHckHvtkZKLUCzHw0bC00k/TcSvxl+WnRhXY5Uc611a8yyT98pWPz5akLFWwO7r9OX8+Jz6Dn6jzZJNbkKFj8g1PxEuuoM=
Authentication-Results: juniper.net; dkim=none (message not signed) header.d=none;juniper.net; dmarc=none action=none header.from=juniper.net;
Received: from [172.29.33.33] (66.129.241.12) by BLUPR05MB788.namprd05.prod.outlook.com (10.141.209.150) with Microsoft SMTP Server (TLS) id 15.1.447.15; Tue, 5 Apr 2016 14:25:54 +0000
To: bruno.decraene@orange.com
References: <3515_1458832652_56F4050B_3515_774_1_53C29892C857584299CBF5D05346208A0F819B1E@OPEXCLILM21.corporate.adroot.infra.ftgroup> <56F42E71.9020201@juniper.net> <9656_1458905159_56F52047_9656_7014_1_53C29892C857584299CBF5D05346208A0F81AAA7@OPEXCLILM21.corporate.adroot.infra.ftgroup> <56FEA566.8070605@juniper.net> <4017_1459805319_5702DC87_4017_5007_1_53C29892C857584299CBF5D05346208A0F83177A@OPEXCNORM2F.corporate.adroot.infra.ftgroup>
From: Eric C Rosen <erosen@juniper.net>
Message-ID: <5703CAEC.9040407@juniper.net>
Date: Tue, 05 Apr 2016 10:25:48 -0400
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.7.1
MIME-Version: 1.0
In-Reply-To: <4017_1459805319_5702DC87_4017_5007_1_53C29892C857584299CBF5D05346208A0F83177A@OPEXCNORM2F.corporate.adroot.infra.ftgroup>
Content-Type: text/plain; charset="windows-1252"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Originating-IP: [66.129.241.12]
X-ClientProxiedBy: CY1PR0601CA0032.namprd06.prod.outlook.com (10.160.162.42) To BLUPR05MB788.namprd05.prod.outlook.com (10.141.209.150)
X-MS-Office365-Filtering-Correlation-Id: 5ffe3a67-7b3d-447b-7a3d-08d35d5e331b
X-Microsoft-Exchange-Diagnostics: 1; BLUPR05MB788; 2:ufDLkJSurOq5cZeNZiRJ1SdC83hMZbjfeBxqF+UY6HLIvLElVNqRM9aD5tYamlQwNJ76wraLJCLSOhamKtJM3XDR1+r+yWMtQpssYf6cFhihrMrSwaIuRNNcThi+EHa7+JxAuIUwjAX1syet1kn2hF9/CrbK/rdUPynZxH+8MhmseDAac2qpc+upka1usVMp; 3:QlHZ9Qw5EeB9IORFMpKVKuywYhFUrQwlKWpmPCqLzdrvsdqp5lP87AWJCW4QmRUHQxFeLxF82wlWhkF5+gOtSgROv2bKtBJLV89lw0GRAvn4ffF8jD/wynW6HqcmEV+D; 25:lwtEYf67Kq1vRlTyrQaRRAFifuLfeKGRhn83fLkkstIJLX+bcNQuFL0CFfqo5+r50qf1NrASMtYX6dvgSag3L2lfJfXguW1iPBguobMRuJc83tM4aLrqb6Puupf6e8QohRGknmslqhA+WnCm6gUoeDr7Lt+y97+Tk8GV4nAZE53LhZDxRJQCcn9d2B7ACFbKhEtsBoFAq0iltS/uaGixLOL8hqeaFzCviq+zFjgBsDOmnMIgbBmAb5OCYCyrBLOubSpMUkc2fhbdR1gcHY95BDZm/2bvKGayK0p6kXueiZ/OOCISR1yhteiB59gQjHncVZmUDxwc/+GmRhDY1c8tCW0zNnOYpCzOYf9NCLWjhXM=
X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BLUPR05MB788;
X-Microsoft-Exchange-Diagnostics: 1; BLUPR05MB788; 20:p9UcKtIzB+VC4jMVkaycdirTwx/gQvtlZ8zbZHioIjxpKLqg5zbT48jGPb651LOsIQ9MbVGcDhgr33IAotLsPKaCZFUQ4QQruqdwFDFJ4Zp+i0l5qbNx4pvEwX1x6C6Jv6ylAF3Jhmko96v/AsBV3jMBv0sU1dQ1cy4jWpNZF1Y/fuD7b69veIT2XecWX0s/eDVaFzcH5iJqqSu981n8UlVsfCkr57+mt4FoE9kS1ysDf42NA32rNaQ0ipBXhJ/ITHK123c4cgQlAFEkmtP4rnqD+6zou5WnEuTSZjB17bDa6iU0pYAatdsGVVpefMlKJBqUv2l4zhQvkk2AV1EWNFJ/0Kzmwl/k1pcHfdRL8d2YO1sLctOVpnVqpcS+0YWanE7rzOr0Twle7y7FjFst11ofIt8M+PmZHzN7hB0M7Sevmtmapcnysw+nRXuz9x0j1zzuO3Y3iAoNM2vEZpoOKWTOEVYLlIps+jNfxZXglUlrbYBMSEI9G2yZlOzJAwou; 4:/nRROFlKGXFH7j6CqUE1YqTwigdc0cSQEwttl7t8/j8L/eQghoPAAkatrTxTHDihATmX6VicdS+J+3RW7TpUpIkAbixS3bmuU+aLkodpSJu2NaBj6nzlSU9P2HZ4sZJ4JIWohD/Kk4wWb+jqXERAG3guikYYVEOIrtbow/aWKqwFbpflYW4wRzB649bO4Wzpy5Cgh7IfQMLU68pEEWK9CDIbkDLxm51KKNr/GLC9aXJYa+P/IvW/3sXbS6RiO4nJao78W5U8sIyR7ZgyDPNJMdVvTM8oc5OUP8qj7xpelrYmI4Ddjtq4B+SZudlHmFVfGkWm34383ZCp+VJvHCZjbu6oBZCCDiWnj/MYFHKo1VmQPFanrb1nB6/70K/s2mQl
X-Microsoft-Antispam-PRVS: <BLUPR05MB7883792D9093AFC199F6514D49E0@BLUPR05MB788.namprd05.prod.outlook.com>
X-Exchange-Antispam-Report-Test: UriScan:;
X-Exchange-Antispam-Report-CFA-Test: BCL:0; PCL:0; RULEID:(601004)(2401047)(8121501046)(5005006)(3002001)(10201501046); SRVR:BLUPR05MB788; BCL:0; PCL:0; RULEID:; SRVR:BLUPR05MB788;
X-Forefront-PRVS: 0903DD1D85
X-Forefront-Antispam-Report: SFV:NSPM; SFS:(10019020)(4630300001)(6009001)(6049001)(24454002)(377454003)(5008740100001)(4326007)(19580405001)(80316001)(19580395003)(1096002)(2906002)(3846002)(93886004)(6116002)(50466002)(586003)(81166005)(77096005)(230783001)(189998001)(2351001)(42186005)(2950100001)(110136002)(5004730100002)(33656002)(230700001)(66066001)(92566002)(50986999)(65806001)(36756003)(65816999)(64126003)(87266999)(54356999)(47776003)(76176999)(86362001); DIR:OUT; SFP:1102; SCL:1; SRVR:BLUPR05MB788; H:[172.29.33.33]; FPR:; SPF:None; MLV:sfv; LANG:en;
X-Microsoft-Exchange-Diagnostics: 1; BLUPR05MB788; 23:sQ8sgoiUucJYi89EKfAxzK6rAVmDv/EQIy65ViDDMghdqxs/Qfyc8XDM5mKVMjL4u/O/keYG2amtVsrCt0hMFy9nzfr7nWL0VI39ppdL2yfQyGU55gg7ew1zV7aNuiSF0Flg/sqWQbf73Zt0j7oaqmYR2ChaC6H5SyI7Qz9/Lnx4dtdzUSuejXZ51rM0pUMSbgX3zmf5ZbJiAbhxu4mjR9oY7b9BUbogL1qVKccvSCtGXWR3jKRLwb7sWhbhI3EDJhd1M6ZKxS20Em7/dDpV8HSBwcKjzbcZnfnBtSSzB09sbGYMaLfZToAu0RtGw8Ucvg+X+gcaZUGtdSsXJVXSd+xnDp2Vm4O6yj0GhEzz49qBkVUc2hwgEm1itR1zOqutMQ8Q4zksqadJ5EN8Y1NPRVgTphbiLV8VjQ4nEFZTcOIHbYnZKEcpLKjaEQjCJ4BAcOjiwYZTqZYyosKiAy7P2I6z0ze/WoEGA6q94NR4qYEZ2TJRO+ujlypoyR319aoXN7dqEtjXawDd9xX8jjq9bTNaktV9OenTH0CMnPhWfQPJ5Qemosfow+VBF+RPEz2MpkCU4w2/o21wxI3+6VqVUvWo4mmgRauYC7SE5KvHh0XPGgM0NXJCSClSvgSDBpfe2swJcJogQsv8/Tn0gCESRcE573O3KwmDb1+dGiUzNaH+YyA/i5SaA41jfmRPEx53B6HnQNDLPBr5WE5V/2lhUWCDiMajwZfTDTbzib+579BJXQcRD3H2MMkxCezK/34Ff7wF0jGYxbzkfb6tJ0chUg5dOc9sKF3relp1Q6ztvrWRRplHRV17d612/fIJpCqFc4IobcmeB/U+FCDQ0AAfxfHfGuYXG5VRxs5+Amsh52Zr2jTi1HqlWr+I0H9KO8PKJcfFS3BXC7v/DECxxJmWpiJUUmiTxzpssdNXldAVYJVtwsXULFwnCzT20ZWKZMPBmGhWXU8UQBc6V4tRAV8V3gN0WJSXTD3XRGI2MNGY/thK2PzQf+/zTPKoMMRB1qxdeJBGU9t41elbvxOib128dCXvymHL93V+ZxbtfHWeAFY=
X-Microsoft-Exchange-Diagnostics: 1; BLUPR05MB788; 5:UPNxHGlwgQsn23R+CzMtFwdxE77PVOJ8ZShx10vTjc0geNT7TtJWM/45O2rfwIm48j2gEaOqXxwfC3PJGI2lWDlANTujScJWrW1oLcZO6WmRxofjmxNfV6zz4qmYYcX5KzSJhD6ZxGcMf3l9NxvCaA==; 24:lw0pQPv3P7ZVGUL41gQtLCOE27qsKWQ5o7U1tDlTYadQROdjw6GypzXepeT6cEADhdzeBWFZRP5jdlB3Z+Qu6m2q2/f4XMDJfsSgPv3s0K8=
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-OriginalArrivalTime: 05 Apr 2016 14:25:54.5119 (UTC)
X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BLUPR05MB788
Archived-At: <http://mailarchive.ietf.org/arch/msg/idr/7tSerNNMlYfXrIJ_J9NwVcR72gk>
Cc: "idr@ietf.org" <idr@ietf.org>, BESS <bess@ietf.org>, "mpls@ietf.org" <mpls@ietf.org>
Subject: Re: [Idr] [bess] draft-rosen-mpls-rfc3107bis
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/idr/>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 05 Apr 2016 14:26:14 -0000

On 4/4/2016 5:28 PM, bruno.decraene@orange.com wrote:
> My issue is how do we prove that_nobody_  is using it? Proving the negative is hard, and silence is not part of the proof. To prove the negative, we would need explicit statement from everyone, which looks impossible.

I think you're exaggerating a little ;-)  I'm having trouble believing 
that you are unable to determine whether the 3107 "multiple labels" 
feature is in use in any of your company's deployments.

I think a more serious concern is how to avoid tickling the "day 1" bugs 
that may exist.  There may be implementations, supporting only a single 
label, that fail to set the S bit.  There may be implementations, 
supporting only a single label, that fail to check the S bit.  These 
"day 1" bugs will never have caused a problem, because the multiple 
labels feature has not been used.  We should endeavor to ensure that 
these"day 1" bugs do not cause a problem in the future if newer 
implementations begin to use the multiple labels feature.

Right now, we're arguing about which of the following two strategies is 
more likely to cause a problem:

1. In the first strategy, 3107bis requires the S bit to be set when 
there is a single label.  This will allow 3107bis to interoperate with 
3107 implementations of "multiple labels", but it will not allow 3107bis 
to interoperate with (buggy) 3107 implementations that send a single 
label, but don't set the S bit.

2. In the second strategy, 3107bis assumes, in the absence of the 
Capability, that there is only a single label, and doesn't bother to 
check the S bit.  This will allow 3107bis to interoperate with (buggy) 
implementations that send a single label but fail to set the S bit; it 
will not allow 3107bis to interoperate with (non-buggy) 3107 
implementations of multiple labels.

My argument is that the second strategy is better because it will be 
less disruptive.  This is based on my belief that the "day 1" bugs do 
exist, and that the "multiple labels" feature has yet to be deployed.

Your argument seems to be that the first strategy is better because (a)  
it only causes disruption if the 3107 implementation has a bug, in which 
case the bug can be fixed, and (b) if the second strategy is used, a 
3107-compliant implementation of multiple labels will fail to 
interoperate with a 3107bis-compliant implementation of multiple labels, 
and both implementors will claim compliance.

I think your argument is reasonable, the question is really just which 
strategy will cause less disruption.

Do other members of the WGs have opinions about this?