Re: [bess] Benjamin Kaduk's No Objection on draft-ietf-bess-bgp-vpls-control-flags-07: (with COMMENT)
Ravi Singh <ravis@juniper.net> Sat, 20 April 2019 02:09 UTC
Return-Path: <ravis@juniper.net>
X-Original-To: bess@ietfa.amsl.com
Delivered-To: bess@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0BBDF12049B; Fri, 19 Apr 2019 19:09:11 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.339
X-Spam-Level:
X-Spam-Status: No, score=-1.339 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, KHOP_DYNAMIC=1.363, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=juniper.net
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 tdHhgY6P4yGJ; Fri, 19 Apr 2019 19:09:08 -0700 (PDT)
Received: from mx0a-00273201.pphosted.com (mx0a-00273201.pphosted.com [208.84.65.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8B6AB120479; Fri, 19 Apr 2019 19:09:08 -0700 (PDT)
Received: from pps.filterd (m0108156.ppops.net [127.0.0.1]) by mx0a-00273201.pphosted.com (8.16.0.27/8.16.0.27) with SMTP id x3K24eZI009722; Fri, 19 Apr 2019 19:09:02 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=juniper.net; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-transfer-encoding : mime-version; s=PPS1017; bh=BW5SEhOvxmCziAZ4CBo4K13MW/D0xEq5RNS1Hgrlg6w=; b=dB0yYGvUeQV6kgCvtj7qAqwaIbB8SWtKjyjf4L3wAhSyzq2WmiwR9CueyOo8cP+LcRy0 9eM7qCfGpz+/Snis24+DlENJS7uQI/Hwi+BRoNfPZM3tHwtyvcJHDVblCMeJhcP7OLjQ OuaQzSJ9NOeAKX/zjYf7cV4T0qK/Pbna9F3DYLB9PRcp41h1t6kGn+vVwCMZc0ByEQH+ 1xO8uYpdDLztdDa5CYUet8dg6nOSyKgHwWeh8Imkdj8A8wIbnFP3PiUwq6yYZVZfLpXt bC2OcrWAX9Dm4/BecXp5Zs1HwMlioDsCUmcG0vUYM4Jikd6qufILGGDRwshO4WVwibDS uw==
Received: from nam05-by2-obe.outbound.protection.outlook.com (mail-by2nam05lp2053.outbound.protection.outlook.com [104.47.50.53]) by mx0a-00273201.pphosted.com with ESMTP id 2ryjv30gaw-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-SHA384 bits=256 verify=NOT); Fri, 19 Apr 2019 19:09:02 -0700
Received: from BYAPR05MB4408.namprd05.prod.outlook.com (52.135.202.158) by BYAPR05MB5141.namprd05.prod.outlook.com (20.177.231.23) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.1835.7; Sat, 20 Apr 2019 02:08:59 +0000
Received: from BYAPR05MB4408.namprd05.prod.outlook.com ([fe80::655d:a12d:1434:d92]) by BYAPR05MB4408.namprd05.prod.outlook.com ([fe80::655d:a12d:1434:d92%7]) with mapi id 15.20.1835.007; Sat, 20 Apr 2019 02:08:59 +0000
From: Ravi Singh <ravis@juniper.net>
To: Benjamin Kaduk <kaduk@mit.edu>, The IESG <iesg@ietf.org>
CC: "draft-ietf-bess-bgp-vpls-control-flags@ietf.org" <draft-ietf-bess-bgp-vpls-control-flags@ietf.org>, Mach Chen <mach.chen@huawei.com>, "bess-chairs@ietf.org" <bess-chairs@ietf.org>, "bess@ietf.org" <bess@ietf.org>
Thread-Topic: Benjamin Kaduk's No Objection on draft-ietf-bess-bgp-vpls-control-flags-07: (with COMMENT)
Thread-Index: AQHU7unZGENqyhAo7E22LpsQ6QG026ZCw5Ng
Date: Sat, 20 Apr 2019 02:08:59 +0000
Message-ID: <BYAPR05MB4408370D6499D95A1278A510AB200@BYAPR05MB4408.namprd05.prod.outlook.com>
References: <155482411698.3382.14220246262717452382.idtracker@ietfa.amsl.com>
In-Reply-To: <155482411698.3382.14220246262717452382.idtracker@ietfa.amsl.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [66.129.239.11]
x-ms-publictraffictype: Email
x-ms-office365-filtering-correlation-id: b8b02bf9-a472-4e3f-7108-08d6c53526bc
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600141)(711020)(4605104)(4618075)(2017052603328)(7193020); SRVR:BYAPR05MB5141;
x-ms-traffictypediagnostic: BYAPR05MB5141:
x-ms-exchange-purlcount: 2
x-microsoft-antispam-prvs: <BYAPR05MB514109743538AFA73EC9A3EAAB200@BYAPR05MB5141.namprd05.prod.outlook.com>
x-forefront-prvs: 0013079544
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39860400002)(376002)(396003)(136003)(346002)(366004)(189003)(199004)(13464003)(966005)(86362001)(33656002)(73956011)(53546011)(14454004)(53936002)(6246003)(6306002)(19627235002)(7696005)(9686003)(305945005)(99286004)(76176011)(2171002)(102836004)(478600001)(5660300002)(446003)(66446008)(66946007)(76116006)(486006)(64756008)(11346002)(66476007)(256004)(14444005)(6506007)(26005)(186003)(74316002)(52536014)(55016002)(71190400001)(81156014)(54906003)(316002)(66066001)(8676002)(68736007)(476003)(7736002)(2906002)(6116002)(8936002)(81166006)(3846002)(25786009)(229853002)(97736004)(66556008)(6436002)(71200400001)(110136005)(4326008); DIR:OUT; SFP:1102; SCL:1; SRVR:BYAPR05MB5141; H:BYAPR05MB4408.namprd05.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; MX:1; A:1;
received-spf: None (protection.outlook.com: juniper.net does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam-message-info: vCC4aPoaX4pt7l4BSG+LZnI43pWfl7GFJX9Y290A46NdMKoYEPdooJuUQTiXNv8v5S2wuAXIn3dGweHcoxev/n3eZwfqKOxh7bH35ulqlXpLEqzqdAVTfPjntiMmowqyV1gLirPIXNH/IhpXNbdhIJE11LfCDKmJmP98uQK6tP8KrwG9dH2yvs3R2EJVJpvLNqR+3ATyjIQhIWehRL930huS6oDg9IP4JwIn0QYPsvdfzDUg5fR0BiNL4EaNvLJap5vAOgz7uBIGj9sLw0sHKuakTsBtpuES20BYFHjXeITzscPrwdbEPmqdnsXb9ETw67kcwusfh/gehbA9zzo/51WT1BAoT3evdC2ArmUHeCpTHUm2401/RwDn1edIiluwTSeLp4MWPG5eI2Iv040OXji/ZDBe7oCUEJ9Iv01dv1s=
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-OriginatorOrg: juniper.net
X-MS-Exchange-CrossTenant-Network-Message-Id: b8b02bf9-a472-4e3f-7108-08d6c53526bc
X-MS-Exchange-CrossTenant-originalarrivaltime: 20 Apr 2019 02:08:59.1257 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: bea78b3c-4cdb-4130-854a-1d193232e5f4
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR05MB5141
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-04-20_01:, , signatures=0
X-Proofpoint-Spam-Details: rule=outbound_spam_notspam policy=outbound_spam score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1904200014
Archived-At: <https://mailarchive.ietf.org/arch/msg/bess/3lUeCYqvcGLW70OpU1Ao1Xc6LC4>
Subject: Re: [bess] Benjamin Kaduk's No Objection on draft-ietf-bess-bgp-vpls-control-flags-07: (with COMMENT)
X-BeenThere: bess@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: BGP-Enabled ServiceS working group discussion list <bess.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/bess>, <mailto:bess-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/bess/>
List-Post: <mailto:bess@ietf.org>
List-Help: <mailto:bess-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/bess>, <mailto:bess-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sat, 20 Apr 2019 02:09:14 -0000
Hi Benjamin Thanks for your detailed feedback. Please see inline for <RS>. Regards Ravi > -----Original Message----- > From: Benjamin Kaduk via Datatracker [mailto:noreply@ietf.org] > Sent: Tuesday, April 9, 2019 8:35 AM > To: The IESG <iesg@ietf.org> > Cc: draft-ietf-bess-bgp-vpls-control-flags@ietf.org; Mach Chen > <mach.chen@huawei.com>; bess-chairs@ietf.org; mach.chen@huawei.com; > bess@ietf.org > Subject: Benjamin Kaduk's No Objection on draft-ietf-bess-bgp-vpls-control- > flags-07: (with COMMENT) > > Benjamin Kaduk has entered the following ballot position for > draft-ietf-bess-bgp-vpls-control-flags-07: No Objection > > When responding, please keep the subject line intact and reply to all email > addresses included in the To and CC lines. (Feel free to cut this introductory > paragraph, however.) > > > Please refer to https://urldefense.proofpoint.com/v2/url?u=https- > 3A__www.ietf.org_iesg_statement_discuss- > 2Dcriteria.html&d=DwICaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK- > ndb3voDTXcWzoCI&r=6ArkE4n20mNZQF6JxrMYwJyAGBWWjzhSIC2O3- > fXPV4&m=bYCIT8qprRL9tp64crav4NXQbv- > 9JtK1NodEE30aj4Y&s=gKACcDwG815F9IokZIdC2_-SkojE9jRvN6G5s46EJp0&e= > for more information about IESG DISCUSS and COMMENT positions. > > > The document, along with other ballot positions, can be found here: > https://urldefense.proofpoint.com/v2/url?u=https- > 3A__datatracker.ietf.org_doc_draft-2Dietf-2Dbess-2Dbgp-2Dvpls-2Dcontrol- > 2Dflags_&d=DwICaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK- > ndb3voDTXcWzoCI&r=6ArkE4n20mNZQF6JxrMYwJyAGBWWjzhSIC2O3- > fXPV4&m=bYCIT8qprRL9tp64crav4NXQbv- > 9JtK1NodEE30aj4Y&s=YK6yKMztrNqCa2EKzwI9j4Rp7lgy5gK6xuHRqJJSbdI&e= > > > > ---------------------------------------------------------------------- > COMMENT: > ---------------------------------------------------------------------- > > Thanks for this document; it's good to get this behavior clarified and made > more usable. > > Unfortunately, I cannot agree with the "no new security considerations" > statement in Section 7. I wavered for a while on whether to make this a > DISCUSS-level point, but decided not to since I don't think the material > consequences are especially severe. Please take it under consideration, > though. > <RS> I've updated the security considerations section. > It seems to me that we are changing the expected tradeoff between > availability and functionality, and that change should be documented as a > new consideration. Specifically, the state prior to this document (in practice) > seems to be that when a PE advertises the C-bit in its NLRI, all PWs in both > directions that use that NLRI will use the CW, or will fail. Any transient error, > random bit flip, attacker-induced bit flip, etc., would cause a PW failure > which is presumably highly visible. Using the recommendations in this > document, we prioritize availability over using the CW feature, so those > errors/bit-flips now cause the PW to be established but not use the CW, > which may be a less visible event and have second-order effects for the > traffic therein. The operator deploying this technology should make an > informed decision about its usage. > > (We are also changing the behavior of the S bit so there would be some > considerations there, too, though failure to agree on the S bit still results in a > highly visible outage, so the considerations are a little different.) > > Some other, more minor, section-by-section comments follow. > > Section 1 > > ["PE" is not listed as "well-known" at > https://urldefense.proofpoint.com/v2/url?u=https-3A__www.rfc- > 2Deditor.org_materials_abbrev.expansion.txt&d=DwICaQ&c=HAkYuh63rsuh > r6Scbfh0UjBXeMK- > ndb3voDTXcWzoCI&r=6ArkE4n20mNZQF6JxrMYwJyAGBWWjzhSIC2O3- > fXPV4&m=bYCIT8qprRL9tp64crav4NXQbv-9JtK1NodEE30aj4Y&s=SPOx6ODer- > K0xPN-CpKPGJii3Lb9cSv41y9d4ChYZb4&e= and thus would normally be a > candidate for expansion on first use] <RS>: Addressed > > The use of the Control Word (CW) helps prevent mis-ordering of IPv4 > or IPv6 Psuedo-Wire (PW) traffic over Equal Cost Multi-Path (ECMP) > paths or Link Aggregation Group (LAG) bundles. [RFC4385] describes > the format for CW that may be used over Point-to-Point PWs and over a > VPLS. Along with [RFC3985], the document also describes sequence > number usage for VPLS frames. > > RFC 4385 seems to be carrying fairly generic disucssion, to me, without a > clear statement that that CW format should be used for p2p PWs and VPLS > usage. (Though, I cannot dispute the "that may be used" statement, since > the intent of 4385 seems to be quite generic.) Perhaps it is more accurate to > say "a format" than "the format", though, absent some other specification > that mandates this particular one? [<RS>] [<RS>] There is no other specification, AFAIK, for a control-word format other than what is in RFC4835. So, "the format" seems appropriate. > > Section 3.1 > > This new behavior means that any fault (or attacker influence) causes the PW > to degrade to not using the CW, and possibly to do so "silently". > In other contexts this sort of fallback would get harsh review from the > security community, though it's unclear that the risk/reward here merits a > harsh response. > > Section 3.2 > > send outgoing frames with sequence numbers as well. This memo > further specifies the expected behavior. [...] > > I would prefer to see an explicit statement of the semantics of (not) setting > the S-bit, as given by this specification. (That is, the previous section says "If > a PE sets the C-bit in its NLRI, [...]" but we don't have a similarly declarative > statement for the S bit.) Note, however, that this is the non-blocking > COMMENT portion of the ballot and I am not trying to impose my preference > on you. > > Do we need to say that if both PEs send a S-bit of 0, sequence numbers > MUST NOT be used? > <RS> I've address this in -08. > I a little bit expected to see some text about why CW usage and sequencing > are sufficiently different so as to get differential treatment for mismatched > advertisement, but perhaps it is not really necessary for a document of this > nature. > <RS> I've addressed this in -08. > Section 5 > > [VPLS-MULTIHOMING] is not yet in IESG processing; would it make sense to > move this content into that document? > <RS> I believe keeping C-bit/S-bit mismatch handling in a single document makes it easier to understand the behavior. > Section 5.2 > > The PW behavior is similar to the CW scenario so that the insertion > of S-bit evaluation SHOULD be independent per PW. However, because > > nit: I think this would be a lot clearer if it was "The PW behavior with respect > to sequencing is similar to the CW scenario". (But maybe that's just because > my brain is still parsing PW and CW as visually similar and trying to make > them be semantically similar, even though they are not.) > > one PW would be established, between PE1 and PE2. Thus, even > though CE5 is physically multi-homed, due to PE4's lack of support > for S-bit, and no PW between PE1 and PE4, CE5 would not be multi- > homed. > > nit: I think the relevant attribute is the lack of support for > *sequencing* (which is indicated via the S-bit), rather than "lack of support > for S-bit" itself. <RS> Addressed > > Section 6 > > Let PE2 and PE3 also be CW enabled. Let PE4 not be CW enabled. PE1 > will advertise a VPLS BGP NLRI, containing the C/S bits marked as 1. > PE2 and PE3 on learning of NLRI from PE1, will include the CW in VPLS > frames being forwarded to PE1. However, PE4 which does not have the > ability to include CW, will not. > > This text seems to be written to the letter of RFC 4761 excluding the > modifications made by this document (i.e., advertising NLRI leads to peers > setting those bits for traffic to the indicated PE, without any negotiation). > > Do we want any discussion of the sequencing behaviors and S-bit settings for > this example? > <RS>: Addressed.
- [bess] Benjamin Kaduk's No Objection on draft-iet… Benjamin Kaduk via Datatracker
- Re: [bess] Benjamin Kaduk's No Objection on draft… Ravi Singh