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://www.ietf.org/iesg/statement/discuss-criteria.html for more information about IESG DISCUSS and COMMENT positions. The document, along with other ballot positions, can be found here: https://datatracker.ietf.org/doc/draft-ietf-bess-bgp-vpls-control-flags/ ---------------------------------------------------------------------- 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. 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://www.rfc-editor.org/materials/abbrev.expansion.txt and thus would normally be a candidate for expansion on first use] 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? 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? 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. Section 5 [VPLS-MULTIHOMING] is not yet in IESG processing; would it make sense to move this content into that document? 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. 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? _______________________________________________ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
