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.