Updated Processing of Control Flags for BGP Virtual Private LAN Service (VPLS)
draft-ietf-bess-bgp-vpls-control-flags-08
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2019-06-11
|
08 | (System) | RFC Editor state changed to AUTH48-DONE from AUTH48 |
2019-06-05
|
08 | (System) | RFC Editor state changed to AUTH48 from RFC-EDITOR |
2019-05-31
|
08 | (System) | RFC Editor state changed to RFC-EDITOR from EDIT |
2019-04-24
|
08 | (System) | RFC Editor state changed to EDIT |
2019-04-24
|
08 | (System) | IESG state changed to RFC Ed Queue from Approved-announcement sent |
2019-04-24
|
08 | (System) | Announcement was received by RFC Editor |
2019-04-23
|
08 | (System) | IANA Action state changed to No IANA Actions from In Progress |
2019-04-23
|
08 | (System) | IANA Action state changed to In Progress |
2019-04-23
|
08 | Amy Vezza | IESG state changed to Approved-announcement sent from Approved-announcement to be sent |
2019-04-23
|
08 | Amy Vezza | IESG has approved the document |
2019-04-23
|
08 | Amy Vezza | Closed "Approve" ballot |
2019-04-23
|
08 | Martin Vigoureux | IESG state changed to Approved-announcement to be sent from Approved-announcement to be sent::AD Followup |
2019-04-23
|
08 | Martin Vigoureux | Ballot approval text was generated |
2019-04-19
|
08 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
2019-04-19
|
08 | Ravi Singh | New version available: draft-ietf-bess-bgp-vpls-control-flags-08.txt |
2019-04-19
|
08 | (System) | New version approved |
2019-04-19
|
08 | (System) | Request for posting confirmation emailed to previous authors: Senad Palislamovic , bess-chairs@ietf.org, Ravi Singh , Kireeti Kompella |
2019-04-19
|
08 | Ravi Singh | Uploaded new revision |
2019-04-11
|
07 | Cindy Morgan | IESG state changed to Approved-announcement to be sent::Revised I-D Needed from IESG Evaluation |
2019-04-10
|
07 | Adam Roach | [Ballot Position Update] New position, No Objection, has been recorded for Adam Roach |
2019-04-10
|
07 | Alvaro Retana | [Ballot Position Update] New position, No Objection, has been recorded for Alvaro Retana |
2019-04-10
|
07 | Suresh Krishnan | [Ballot comment] * Section 6 I think this network diagram would be useful in understanding Section 5 and should be moved before the discussions in … [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. |
2019-04-10
|
07 | Suresh Krishnan | [Ballot Position Update] New position, No Objection, has been recorded for Suresh Krishnan |
2019-04-10
|
07 | Alissa Cooper | [Ballot Position Update] New position, No Objection, has been recorded for Alissa Cooper |
2019-04-10
|
07 | Alexey Melnikov | [Ballot Position Update] New position, No Objection, has been recorded for Alexey Melnikov |
2019-04-09
|
07 | Deborah Brungard | [Ballot Position Update] New position, No Objection, has been recorded for Deborah Brungard |
2019-04-09
|
07 | Benjamin Kaduk | [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 … [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? |
2019-04-09
|
07 | Benjamin Kaduk | [Ballot Position Update] New position, No Objection, has been recorded for Benjamin Kaduk |
2019-04-08
|
07 | Roman Danyliw | [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 … [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/ |
2019-04-08
|
07 | Roman Danyliw | [Ballot Position Update] New position, No Objection, has been recorded for Roman Danyliw |
2019-04-08
|
07 | Ignas Bagdonas | [Ballot comment] Please normalize the name of extended community throughout the document - it is "Layer2 Info Extended Community". s4, last paragraph: How should the … [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? |
2019-04-08
|
07 | Ignas Bagdonas | Ballot comment text updated for Ignas Bagdonas |
2019-04-08
|
07 | Ignas Bagdonas | [Ballot Position Update] Position for Ignas Bagdonas has been changed to No Objection from No Record |
2019-04-08
|
07 | Ignas Bagdonas | [Ballot comment] Please normalize the name of extended community throughout the document - it is "Layer2 Info Extended Community". |
2019-04-08
|
07 | Ignas Bagdonas | Ballot comment text updated for Ignas Bagdonas |
2019-04-08
|
07 | Magnus Westerlund | [Ballot Position Update] New position, No Objection, has been recorded for Magnus Westerlund |
2019-04-07
|
07 | Barry Leiba | [Ballot comment] — Section 3.1 — but the PW MUST NOT be prevented from coming up due to this mismatch. So, the PW … [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)? |
2019-04-07
|
07 | Barry Leiba | [Ballot Position Update] New position, No Objection, has been recorded for Barry Leiba |
2019-04-06
|
07 | Éric Vyncke | [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 … [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. |
2019-04-06
|
07 | Éric Vyncke | [Ballot Position Update] New position, No Objection, has been recorded for Éric Vyncke |
2019-04-04
|
07 | Jean Mahoney | Request for Last Call review by GENART Completed: Ready. Reviewer: Meral Shirazipour. |
2019-04-04
|
07 | Mirja Kühlewind | [Ballot comment] Given this document updates the normative behaviour of RFC 4761, I would have expected to see some discussion about interoperability. Is the … [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. |
2019-04-04
|
07 | Mirja Kühlewind | Ballot comment text updated for Mirja Kühlewind |
2019-04-04
|
07 | Mirja Kühlewind | [Ballot comment] Given this document updates the normative behaviour of RFC 4761, I would have expected to see some discussion about interoperability. Is the … [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. |
2019-04-04
|
07 | Mirja Kühlewind | [Ballot Position Update] New position, No Objection, has been recorded for Mirja Kühlewind |
2019-04-04
|
07 | Amy Vezza | Placed on agenda for telechat - 2019-04-11 |
2019-04-04
|
07 | Martin Vigoureux | IESG state changed to IESG Evaluation from Waiting for Writeup |
2019-04-04
|
07 | Martin Vigoureux | Ballot has been issued |
2019-04-04
|
07 | Martin Vigoureux | [Ballot Position Update] New position, Yes, has been recorded for Martin Vigoureux |
2019-04-04
|
07 | Martin Vigoureux | Created "Approve" ballot |
2019-04-04
|
07 | Martin Vigoureux | Ballot writeup was changed |
2019-04-01
|
07 | (System) | IESG state changed to Waiting for Writeup from In Last Call |
2019-03-31
|
07 | Jouni Korhonen | Request for Last Call review by OPSDIR Completed: Ready. Reviewer: Jouni Korhonen. Sent review to list. |
2019-03-25
|
07 | Watson Ladd | Request for Last Call review by SECDIR Completed: Ready. Reviewer: Watson Ladd. Sent review to list. |
2019-03-21
|
07 | (System) | IANA Review state changed to IANA OK - No Actions Needed from IANA - Review Needed |
2019-03-21
|
07 | Sabrina Tanamal | (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 … (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 |
2019-03-14
|
07 | Jean Mahoney | Request for Last Call review by GENART is assigned to Meral Shirazipour |
2019-03-14
|
07 | Jean Mahoney | Request for Last Call review by GENART is assigned to Meral Shirazipour |
2019-03-14
|
07 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Watson Ladd |
2019-03-14
|
07 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Watson Ladd |
2019-03-13
|
07 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Jouni Korhonen |
2019-03-13
|
07 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Jouni Korhonen |
2019-03-11
|
07 | Amy Vezza | IANA Review state changed to IANA - Review Needed |
2019-03-11
|
07 | Amy Vezza | 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, … 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/ |
2019-03-11
|
07 | Amy Vezza | IESG state changed to In Last Call from Last Call Requested |
2019-03-11
|
07 | Amy Vezza | Last call announcement was changed |
2019-03-11
|
07 | Martin Vigoureux | Last call was requested |
2019-03-11
|
07 | Martin Vigoureux | Ballot writeup was generated |
2019-03-11
|
07 | Martin Vigoureux | IESG state changed to Last Call Requested from AD Evaluation::AD Followup |
2019-03-11
|
07 | Martin Vigoureux | Last call announcement was generated |
2019-03-06
|
07 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
2019-03-06
|
07 | Ravi Singh | New version available: draft-ietf-bess-bgp-vpls-control-flags-07.txt |
2019-03-06
|
07 | (System) | New version approved |
2019-03-06
|
07 | (System) | Request for posting confirmation emailed to previous authors: bess-chairs@ietf.org, Ravi Singh , Kireeti Kompella , Senad Palislamovic |
2019-03-06
|
07 | Ravi Singh | Uploaded new revision |
2019-02-19
|
06 | Min Ye | Request for Last Call review by RTGDIR Completed: Has Issues. Reviewer: Acee Lindem. |
2019-02-01
|
06 | Martin Vigoureux | Ballot approval text was generated |
2019-01-29
|
06 | Min Ye | Request for Last Call review by RTGDIR is assigned to Acee Lindem |
2019-01-29
|
06 | Min Ye | Request for Last Call review by RTGDIR is assigned to Acee Lindem |
2019-01-29
|
06 | Mach Chen | 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 … 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. |
2019-01-29
|
06 | Martin Vigoureux | Requested Last Call review by RTGDIR |
2019-01-29
|
06 | Martin Vigoureux | IESG state changed to AD Evaluation::Revised I-D Needed from AD Evaluation |
2018-12-20
|
06 | Martin Vigoureux | IESG state changed to AD Evaluation from Publication Requested |
2018-11-15
|
06 | Stephane Litkowski | 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 … 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. |
2018-11-15
|
06 | Stephane Litkowski | Responsible AD changed to Martin Vigoureux |
2018-11-15
|
06 | Stephane Litkowski | IETF WG state changed to Submitted to IESG for Publication from WG Consensus: Waiting for Write-Up |
2018-11-15
|
06 | Stephane Litkowski | IESG state changed to Publication Requested |
2018-11-15
|
06 | Stephane Litkowski | IESG process started in state Publication Requested |
2018-11-15
|
06 | Mach Chen | Changed document writeup |
2018-08-17
|
06 | Ravi Singh | New version available: draft-ietf-bess-bgp-vpls-control-flags-06.txt |
2018-08-17
|
06 | (System) | New version approved |
2018-08-17
|
06 | (System) | Request for posting confirmation emailed to previous authors: Ravi Singh , Kireeti Kompella , Senad Palislamovic |
2018-08-17
|
06 | Ravi Singh | Uploaded new revision |
2018-07-02
|
05 | Ravi Singh | New version available: draft-ietf-bess-bgp-vpls-control-flags-05.txt |
2018-07-02
|
05 | (System) | New version approved |
2018-07-02
|
05 | (System) | Request for posting confirmation emailed to previous authors: Ravi Singh , Kireeti Kompella , Senad Palislamovic |
2018-07-02
|
05 | Ravi Singh | Uploaded new revision |
2018-05-14
|
04 | Stephane Litkowski | Notification list changed to Mach Chen <mach.chen@huawei.com> |
2018-05-14
|
04 | Stephane Litkowski | Document shepherd changed to Mach Chen |
2018-05-14
|
04 | Stephane Litkowski | IETF WG state changed to WG Consensus: Waiting for Write-Up from WG Document |
2018-02-16
|
04 | Ravi Singh | New version available: draft-ietf-bess-bgp-vpls-control-flags-04.txt |
2018-02-16
|
04 | (System) | New version approved |
2018-02-16
|
04 | (System) | Request for posting confirmation emailed to previous authors: Ravi Singh , Kireeti Kompella , Senad Palislamovic |
2018-02-16
|
04 | Ravi Singh | Uploaded new revision |
2017-07-18
|
03 | Ravi Singh | New version available: draft-ietf-bess-bgp-vpls-control-flags-03.txt |
2017-07-18
|
03 | (System) | New version approved |
2017-07-18
|
03 | (System) | Request for posting confirmation emailed to previous authors: Ravi Singh , Kireeti Kompella , Senad Palislamovic |
2017-07-18
|
03 | Ravi Singh | Uploaded new revision |
2017-07-17
|
02 | (System) | Document has expired |
2017-01-09
|
02 | Ravi Singh | New version available: draft-ietf-bess-bgp-vpls-control-flags-02.txt |
2017-01-09
|
02 | (System) | New version approved |
2017-01-09
|
02 | (System) | Request for posting confirmation emailed to previous authors: "Ravi Singh" , "Senad Palislamovic" , "Kireeti Kompella" |
2017-01-09
|
02 | Ravi Singh | Uploaded new revision |
2017-01-09
|
01 | (System) | Document has expired |
2016-07-08
|
01 | Ravi Singh | New version available: draft-ietf-bess-bgp-vpls-control-flags-01.txt |
2016-04-06
|
00 | Martin Vigoureux | Changed consensus to Yes from Unknown |
2016-04-06
|
00 | Martin Vigoureux | Intended Status changed to Proposed Standard from None |
2016-01-06
|
00 | Martin Vigoureux | This document now replaces draft-singh-bess-bgp-vpls-control-flags instead of None |
2016-01-05
|
00 | Ravi Singh | New version available: draft-ietf-bess-bgp-vpls-control-flags-00.txt |