Return-Path: X-Original-To: mpls@ietfa.amsl.com Delivered-To: mpls@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B9EEC12D581; Wed, 13 Apr 2016 04:38:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.619 X-Spam-Level: X-Spam-Status: No, score=-2.619 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=unavailable autolearn_force=no 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 WbEGc7Wcn4yP; Wed, 13 Apr 2016 04:38:30 -0700 (PDT) Received: from relais-inet.francetelecom.com (relais-ias91.francetelecom.com [193.251.215.91]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3836512DC5A; Wed, 13 Apr 2016 04:32:39 -0700 (PDT) Received: from omfedm06.si.francetelecom.fr (unknown [xx.xx.xx.2]) by omfedm12.si.francetelecom.fr (ESMTP service) with ESMTP id AEAA818C579; Wed, 13 Apr 2016 13:32:37 +0200 (CEST) Received: from Exchangemail-eme2.itn.ftgroup (unknown [10.114.31.57]) by omfedm06.si.francetelecom.fr (ESMTP service) with ESMTP id 89D6927C073; Wed, 13 Apr 2016 13:32:37 +0200 (CEST) Received: from OPEXCLILM21.corporate.adroot.infra.ftgroup ([fe80::e92a:c932:907e:8f06]) by OPEXCLILM23.corporate.adroot.infra.ftgroup ([fe80::787e:db0c:23c4:71b3%19]) with mapi id 14.03.0279.002; Wed, 13 Apr 2016 13:32:37 +0200 From: To: Eric C Rosen Thread-Topic: [bess] draft-rosen-mpls-rfc3107bis Thread-Index: AQHRhfj1qHf38G7z/0eG06bIad1uvp9p2nRAgBylsnA= Date: Wed, 13 Apr 2016 11:32:36 +0000 Message-ID: <20147_1460547157_570E2E55_20147_8686_2_53C29892C857584299CBF5D05346208A0F86D106@OPEXCLILM21.corporate.adroot.infra.ftgroup> 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> In-Reply-To: <9656_1458905159_56F52047_9656_7014_1_53C29892C857584299CBF5D05346208A0F81AAA7@OPEXCLILM21.corporate.adroot.infra.ftgroup> Accept-Language: fr-FR, en-US Content-Language: fr-FR X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.168.234.3] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-PMX-Version: 6.2.1.2478543, Antispam-Engine: 2.7.2.2107409, Antispam-Data: 2016.4.13.105417 Archived-At: Cc: "idr@ietf.org" , BESS , "mpls@ietf.org" Subject: Re: [mpls] [bess] draft-rosen-mpls-rfc3107bis X-BeenThere: mpls@ietf.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: Multi-Protocol Label Switching WG List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 13 Apr 2016 11:38:31 -0000 From: Eric C Rosen [mailto:erosen@juniper.net] > the "day 1" bugs do exist Do we really have implementation not setting the S bit on the sending side?? I don't see how this could be per design, as I fail to see a reason: - sending with S=3D1 or S=3D0 has the same cost from an implementation pers= pective, so this is not a "simplification" issue - sending with S=3D0 is a clear violation of RFC 3107 and will trigger a BG= P session shutdown from a peer compliant with 3107, so this does not seem l= ike a desirable goal from an implementation standpoint. Now, that could be a bug, but that bug would be detected with the first int= eroperability test with a compliant RFC 3107 implementation... So, how have we got into this situation? How can we be there 15 years after= the publication of RFC 3107? Thanks -- Bruno ___________________________________________________________________________= ______________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confiden= tielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu= ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages el= ectroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou = falsifie. Merci. This message and its attachments may contain confidential or privileged inf= ormation that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and dele= te this message and its attachments. As emails may be altered, Orange is not liable for messages that have been = modified, changed or falsified. Thank you.