Hi Benjamin Thanks for your detailed feedback. Please see inline for <RS>. Regards Ravi
> -----Original Message----- > From: Benjamin Kaduk via Datatracker [mailto:nore...@ietf.org] > Sent: Tuesday, April 9, 2019 8:35 AM > To: The IESG <i...@ietf.org> > Cc: draft-ietf-bess-bgp-vpls-control-fl...@ietf.org; Mach Chen > <mach.c...@huawei.com>; bess-cha...@ietf.org; mach.c...@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 mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
