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

[Ballot comment]
* 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.

[Ballot 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?

[Ballot comment]
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/

[Ballot comment]

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?

[Ballot comment]
— 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)?

[Ballot comment]
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.

[Ballot comment]
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.

[Ballot comment]
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 editor request:
- Please expand PE on first occurrence.

(Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs:

The IANA Functions Operator has reviewed draft-ietf-bess-bgp-vpls-control-flags-07, which is currently in Last Call, and has the following comments:

We understand that this document doesn't require any registry actions.

While it's often helpful for a document's IANA Considerations section to remain in place upon publication even if there are no actions, if the authors strongly prefer to remove it, we do not object.

If this assessment is not accurate, please respond as soon as possible.

Thank you,

Sabrina Tanamal
Senior IANA Services Specialist

The following Last Call announcement was sent out (ends 2019-04-01):

From: The IESG
To: IETF-Announce
CC: mach.chen@huawei.com, martin.vigoureux@nokia.com, Mach Chen , bess-chairs@ietf.org, bess@ietf.org, draft-ietf-bess-bgp-vpls-control-flags@ietf.org
Reply-To: ietf@ietf.org
Sender:
Subject: Last Call:  (Updated processing of Control Flags for BGP VPLS) to Proposed Standard


The IESG has received a request from the BGP Enabled ServiceS WG (bess) to
consider the following document: - 'Updated processing of Control Flags for
BGP VPLS'
  as Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits final
comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2019-04-01. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the beginning of
the Subject line to allow automated sorting.

Abstract


  This document updates the meaning of the Control Flags field in the
  Layer2 Info Extended Community used for BGP-VPLS NLRI as defined in
  RFC4761. This document updates RFC4761.





The file can be obtained via
https://datatracker.ietf.org/doc/draft-ietf-bess-bgp-vpls-control-flags/

IESG discussion can be tracked via
https://datatracker.ietf.org/doc/draft-ietf-bess-bgp-vpls-control-flags/ballot/

The following IPR Declarations may be related to this I-D:

  https://datatracker.ietf.org/ipr/2235/

As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up.

Changes are expected over time. This version is dated 24 February 2012.

(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)?  Why
is this the proper type of RFC?  Is this type of RFC indicated in the
title page header?

  Standards Track.

(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:

Technical Summary

  This document updates the meaning of the "control flags" fields
  inside the "layer2 info extended community" used for BGP-VPLS NLRI as
  defined in RFC4761. If approved, this document updates RFC4761.


Working Group Summary

  There is good consensus from the WG, and there is no controversy.

Document Quality

  There were active discussions in the WG, many valuable
  comments received and addressed. A number of iterations
  reflecting that.

Personnel

  Document Shepherd: Mach Chen
  Responsible Area Director: Martin Vigoureux

(3) Briefly describe the review of this document that was performed by
the Document Shepherd.  If this version of the document is not ready
for publication, please explain why the document is being forwarded to
the IESG.

  The Document Shepherd has reviewed the draft and raised some 
  comments that have been addressed in the latest version. After the review,
  the Document Shepherd thinks that there is no outstanding issue with the
  draft and it is ready for publication.

(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?
 
  No.

(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that
took place.
 
  No.

(6) Describe any specific concerns or issues that the Document Shepherd
has with this document that the Responsible Area Director and/or the
IESG should be aware of? For example, perhaps he or she is uncomfortable
with certain parts of the document, or has concerns whether there really
is a need for it. In any event, if the WG has discussed those issues and
has indicated that it still wishes to advance the document, detail those
concerns here.

  No.

(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed. If not, explain why.

  Yes.

(8) Has an IPR disclosure been filed that references this document?
If so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

  Yes, an IPR disclosure has been filed that references this document.
  The WG is OK with the IPR disclosure.

(9) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with others
being silent, or does the WG as a whole understand and agree with it? 

  There is good consensus from the WG.

(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in separate
email messages to the Responsible Area Director. (It should be in a
separate email because this questionnaire is publicly available.)

  No.

(11) Identify any ID nits the Document Shepherd has found in this
document. (See https://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.
 
  None.

(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.

  N/A.

(13) Have all references within this document been identified as
either normative or informative?

  Yes.

(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If such normative
references exist, what is the plan for their completion?

  No.

(15) Are there downward normative references references (see RFC 3967)?
If so, list these downward references to support the Area Director in
the Last Call procedure.

  No.

(16) Will publication of this document change the status of any
existing RFCs? Are those RFCs listed on the title page header, listed
in the abstract, and discussed in the introduction? If the RFCs are not
listed in the Abstract and Introduction, explain why, and point to the
part of the document where the relationship of this document to the
other RFCs is discussed. If this information is not in the document,
explain why the WG considers it unnecessary.
 
  This document updates RFC4761. It is mentioned on the title page header,
  explicitly listed in the abstract, and discussed in the introduction.


(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document. Confirm that all protocol extensions that the document makes
are associated with the appropriate reservations in IANA registries.
Confirm that any referenced IANA registries have been clearly
identified. Confirm that newly created IANA registries include a
detailed specification of the initial contents for the registry, that
allocations procedures for future registrations are defined, and a
reasonable name for the new registry has been suggested (see RFC 5226).

  No IANA requests from this document, the IANA section is well written.

(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find
useful in selecting the IANA Experts for these new registries.
 
  None.

(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.

  N/A.

As required by RFC 4858, this is the current template for the Document
Shepherd Write-Up.

Changes are expected over time. This version is dated 24 February 2012.

(1) What type of RFC is being requested (BCP, Proposed Standard,
Internet Standard, Informational, Experimental, or Historic)?  Why
is this the proper type of RFC?  Is this type of RFC indicated in the
title page header?

  Standards Track.

(2) The IESG approval announcement includes a Document Announcement
Write-Up. Please provide such a Document Announcement Write-Up. Recent
examples can be found in the "Action" announcements for approved
documents. The approval announcement contains the following sections:

Technical Summary

  This document updates the meaning of the "control flags" fields
  inside the "layer2 info extended community" used for BGP-VPLS NLRI as
  defined in RFC4761. If approved, this document updates RFC4761.


Working Group Summary

  There is good consensus from the WG, and there is no controversy.

Document Quality

  There were active discussions in the WG, many valuable
  comments received and addressed. A number of iterations
  reflecting that.

Personnel

  Document Shepherd: Mach Chen
  Responsible Area Director: Martin Vigoureux

(3) Briefly describe the review of this document that was performed by
the Document Shepherd.  If this version of the document is not ready
for publication, please explain why the document is being forwarded to
the IESG.

  The Document Shepherd has reviewed the draft and raised some 
  comments that have been addressed in the latest version. After the review,
  the Document Shepherd thinks that there is no outstanding issue with the
  draft and it is ready for publication.

(4) Does the document Shepherd have any concerns about the depth or
breadth of the reviews that have been performed?
 
  No.

(5) Do portions of the document need review from a particular or from
broader perspective, e.g., security, operational complexity, AAA, DNS,
DHCP, XML, or internationalization? If so, describe the review that
took place.
 
  No.

(6) Describe any specific concerns or issues that the Document Shepherd
has with this document that the Responsible Area Director and/or the
IESG should be aware of? For example, perhaps he or she is uncomfortable
with certain parts of the document, or has concerns whether there really
is a need for it. In any event, if the WG has discussed those issues and
has indicated that it still wishes to advance the document, detail those
concerns here.

  No.

(7) Has each author confirmed that any and all appropriate IPR
disclosures required for full conformance with the provisions of BCP 78
and BCP 79 have already been filed. If not, explain why.

  Yes.

(8) Has an IPR disclosure been filed that references this document?
If so, summarize any WG discussion and conclusion regarding the IPR
disclosures.

  None.

(9) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with others
being silent, or does the WG as a whole understand and agree with it? 

  There is good consensus from the WG.

(10) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in separate
email messages to the Responsible Area Director. (It should be in a
separate email because this questionnaire is publicly available.)

  No.

(11) Identify any ID nits the Document Shepherd has found in this
document. (See https://www.ietf.org/tools/idnits/ and the Internet-Drafts
Checklist). Boilerplate checks are not enough; this check needs to be
thorough.
 
  None.

(12) Describe how the document meets any required formal review
criteria, such as the MIB Doctor, media type, and URI type reviews.

  N/A.

(13) Have all references within this document been identified as
either normative or informative?

  Yes.

(14) Are there normative references to documents that are not ready for
advancement or are otherwise in an unclear state? If such normative
references exist, what is the plan for their completion?

  No.

(15) Are there downward normative references references (see RFC 3967)?
If so, list these downward references to support the Area Director in
the Last Call procedure.

  No.

(16) Will publication of this document change the status of any
existing RFCs? Are those RFCs listed on the title page header, listed
in the abstract, and discussed in the introduction? If the RFCs are not
listed in the Abstract and Introduction, explain why, and point to the
part of the document where the relationship of this document to the
other RFCs is discussed. If this information is not in the document,
explain why the WG considers it unnecessary.
 
  This document updates RFC4761. It is mentioned on the title page header,
  explicitly listed in the abstract, and discussed in the introduction.


(17) Describe the Document Shepherd's review of the IANA considerations
section, especially with regard to its consistency with the body of the
document. Confirm that all protocol extensions that the document makes
are associated with the appropriate reservations in IANA registries.
Confirm that any referenced IANA registries have been clearly
identified. Confirm that newly created IANA registries include a
detailed specification of the initial contents for the registry, that
allocations procedures for future registrations are defined, and a
reasonable name for the new registry has been suggested (see RFC 5226).

  No IANA requests from this document, the IANA section is well written.

(18) List any new IANA registries that require Expert Review for future
allocations. Provide any public guidance that the IESG would find
useful in selecting the IANA Experts for these new registries.
 
  None.

(19) Describe reviews and automated checks performed by the Document
Shepherd to validate sections of the document written in a formal
language, such as XML code, BNF rules, MIB definitions, etc.

  N/A.