Updated Processing of Control Flags for BGP Virtual Private LAN Service (VPLS)
draft-ietf-bess-bgp-vpls-control-flags-08

A few nits:

(1) In Section 3.1.  Typo.  s/seqence/sequence/

(2) Section 4.  Typo. s/VPLS,there/VPLS, there/  

(3) Section 5.1.  Editorial.  s/the below specified network topology/the network topology specified in Section 6/

Minor comment: sections 3.1 and 3.2 have different ways of describing a mismatch between the 2 PE. Text is clear and non ambiguous but I prefer section 3.2 "If the PEs at both ends of the PW do not agree" which is concise.

— Section 3.1 —

   but the PW MUST
   NOT be prevented from coming up due to this mismatch. So, the PW MUST
   still come up but not use control word in either direction.

The second MUST seems wrong to me: the normative behaviour is already stated by the 
MUST NOT, but there could be other factors that legitimately prevent the PW from coming up, no?  Likely, this should say, “So, the PW will still come up, ...”

— Section 3.2 —

   If the PEs at both ends of the PW do not agree on the
   setting of the S-bit, the PW SHOULD NOT come up.

Why SHOULD NOT?  Why might it be allowed to come up anyway, and what would the consequences of that be (which would need to be understood in order to not obey the SHOULD NOT)?

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?

Please normalize the name of extended community throughout the document - it is "Layer2 Info Extended Community".

s4, last paragraph: How should the NLRIs be differentiated in an interoperable way?

Given this document updates the normative behaviour of RFC 4761, I would have expected to see some discussion about interoperability. Is the behaviour as specified in RFC 4761 not widely deployed/implemented or would it be possible to add some sentences about interoperability which already deployed devices?

One minor editorial request:
- Please expand PE on first occurrence.

* Section 6

I think this network diagram would be useful in understanding Section 5 and should be moved before the discussions in Section 5.

* Section 5.2

"and no PW between PE1 and PE4"

Shouldn't this be 

"and no PW between PE2 and PE4"

as the draft was discussing multihomed connectivity from PE2 towards A5.