Seamless Integration of Ethernet VPN (EVPN) with Virtual Private LAN Service (VPLS) and Their Provider Backbone Bridge (PBB) Equivalents
draft-ietf-bess-evpn-vpls-seamless-integ-07
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2019-05-06
|
07 | (System) | RFC Editor state changed to AUTH48-DONE from AUTH48 |
2019-03-25
|
07 | (System) | RFC Editor state changed to AUTH48 from RFC-EDITOR |
2019-03-07
|
07 | (System) | RFC Editor state changed to RFC-EDITOR from EDIT |
2019-02-01
|
07 | (System) | IANA Action state changed to No IANA Actions from In Progress |
2019-02-01
|
07 | Ali Sajassi | New version available: draft-ietf-bess-evpn-vpls-seamless-integ-07.txt |
2019-02-01
|
07 | (System) | New version approved |
2019-02-01
|
07 | (System) | Request for posting confirmation emailed to previous authors: Jorge Rabadan , Samer Salam , Ali Sajassi , Nick Regno |
2019-02-01
|
07 | Ali Sajassi | Uploaded new revision |
2019-02-01
|
06 | (System) | IANA Action state changed to In Progress |
2019-02-01
|
06 | (System) | RFC Editor state changed to EDIT |
2019-02-01
|
06 | (System) | IESG state changed to RFC Ed Queue from Approved-announcement sent |
2019-02-01
|
06 | (System) | Announcement was received by RFC Editor |
2019-02-01
|
06 | Amy Vezza | IESG state changed to Approved-announcement sent from Approved-announcement to be sent |
2019-02-01
|
06 | Amy Vezza | IESG has approved the document |
2019-02-01
|
06 | Amy Vezza | Closed "Approve" ballot |
2019-02-01
|
06 | Martin Vigoureux | IESG state changed to Approved-announcement to be sent from IESG Evaluation::AD Followup |
2019-02-01
|
06 | Martin Vigoureux | Ballot approval text was generated |
2019-01-30
|
06 | Alissa Cooper | [Ballot comment] Thank you for addressing my DISCUSS. |
2019-01-30
|
06 | Alissa Cooper | [Ballot Position Update] Position for Alissa Cooper has been changed to No Objection from Discuss |
2019-01-22
|
06 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
2019-01-22
|
06 | (System) | IANA Review state changed to Version Changed - Review Needed from IANA OK - No Actions Needed |
2019-01-22
|
06 | Ali Sajassi | New version available: draft-ietf-bess-evpn-vpls-seamless-integ-06.txt |
2019-01-22
|
06 | (System) | New version approved |
2019-01-22
|
06 | (System) | Request for posting confirmation emailed to previous authors: Jorge Rabadan , Samer Salam , Ali Sajassi , Nick Regno |
2019-01-22
|
06 | Ali Sajassi | Uploaded new revision |
2019-01-10
|
05 | Cindy Morgan | IESG state changed to IESG Evaluation::Revised I-D Needed from IESG Evaluation |
2019-01-10
|
05 | Ignas Bagdonas | [Ballot Position Update] New position, No Objection, has been recorded for Ignas Bagdonas |
2019-01-09
|
05 | Adam Roach | [Ballot Position Update] New position, No Objection, has been recorded for Adam Roach |
2019-01-09
|
05 | Suresh Krishnan | [Ballot comment] * Section 3.3 MAC Mobility The handling of MAC mobility between the EVPN and VPLS PEs seems a bit, for a lack of … [Ballot comment] * Section 3.3 MAC Mobility The handling of MAC mobility between the EVPN and VPLS PEs seems a bit, for a lack of a better term, "not seamless" to me. While only using EVPN a MAC that has moved will get propagated out without *initiating* any sort of BUM traffic itself as described Section 15 of RFC7432. If I understand this document correctly, if a MAC moves onto a segment with a VPLS PE, traffic towards it will be blackholed until it initiates BUM traffic which is not the case when the MAC moves between EVPN PEs. Did I get this right? If so, I think this limitation needs to be highlighted a bit more prominently. |
2019-01-09
|
05 | Suresh Krishnan | [Ballot Position Update] New position, No Objection, has been recorded for Suresh Krishnan |
2019-01-09
|
05 | Warren Kumari | [Ballot comment] I'm staying out of the "what track should it be" discussion... Thanks to Linda Dunbar for the OpsDir review. |
2019-01-09
|
05 | Warren Kumari | [Ballot Position Update] New position, No Objection, has been recorded for Warren Kumari |
2019-01-09
|
05 | Ben Campbell | [Ballot comment] Thanks for the work on this. I support Alissa's discuss. §2: - The 2119/8174 keywords in this section are not used according to … [Ballot comment] Thanks for the work on this. I support Alissa's discuss. §2: - The 2119/8174 keywords in this section are not used according to the RFC 2119/RFC 8174 definitions. The RFCs talk about requirements on implementations to achieve interoperability. This speaks of requirements for the standards process. If the working group prefers to keep the use of keywords in this section, please add some additional text to the 2119/8174 boilerplate to explain the usage. (My other comments on the section assume that the normative keywords will remain.) - Req 2: "The solution MUST require no changes..." I suggest "MUST NOT require changes" - Req 5: This doesn't seem to state a solution requirement; rather, it describes an action that VPN instances may take. Is the solution requirement to allow this behavior? |
2019-01-09
|
05 | Ben Campbell | [Ballot Position Update] New position, No Objection, has been recorded for Ben Campbell |
2019-01-09
|
05 | Spencer Dawkins | [Ballot Position Update] New position, No Objection, has been recorded for Spencer Dawkins |
2019-01-09
|
05 | Deborah Brungard | [Ballot comment] I agree with the current status as PS. While it does not define new codepoints or protocol extensions, it defines new mechanisms which … [Ballot comment] I agree with the current status as PS. While it does not define new codepoints or protocol extensions, it defines new mechanisms which need to be supported by all (PBB-)EVPN nodes. The mechanisms are not supported by operational configuration, they are new mechanisms which need to be supported by the node itself. A BCP/Informational status would be appropriate if this document was only defining the procedures related to the VPLS or PBB-VPLS PEs. For those nodes, there is no change, as all the new mechanisms supporting seamless integration need to be supported on the EVPN nodes. |
2019-01-09
|
05 | Deborah Brungard | Ballot comment text updated for Deborah Brungard |
2019-01-09
|
05 | Deborah Brungard | [Ballot comment] I agree with the current status as PS. While it does not define new codepoints or protocol extensions, it defines new mechanisms which … [Ballot comment] I agree with the current status as PS. While it does not define new codepoints or protocol extensions, it defines new mechanisms which need to be supported by all (PBB-)EVPN nodes. The mechanisms are not supported by operational configuration, they are new mechanisms which need to be supported by the node itself. A BCP/Informational status would be appropriate if this document was only defining the procedures related to the VPLS or PBB-VPLS PEs. For those nodes, there is no change, as all the new mechanisms supporting seamless integration need to be supported on the EVPN nodes. |
2019-01-09
|
05 | Deborah Brungard | Ballot comment text updated for Deborah Brungard |
2019-01-09
|
05 | Deborah Brungard | [Ballot comment] I agree with the current status as PS. While it does not define new codepoints or protocol extensions, it defines new mechanisms which … [Ballot comment] I agree with the current status as PS. While it does not define new codepoints or protocol extensions, it defines new mechanisms which need to be supported by all (PBB-)EVPN nodes. The mechanisms are not supported by operational configuration, they are new mechanisms which need to be supported by the node itself. A BCP/Informational status would be appropriate if this document was only defining the procedures related to the VPLS or PBB-VPLS PEs. For those nodes, there is no change, as all the new mechanisms supporting seamless integration need to be supported on the EVPN nodes. |
2019-01-09
|
05 | Deborah Brungard | [Ballot Position Update] New position, Yes, has been recorded for Deborah Brungard |
2019-01-09
|
05 | Alexey Melnikov | [Ballot Position Update] New position, No Objection, has been recorded for Alexey Melnikov |
2019-01-09
|
05 | Alissa Cooper | [Ballot discuss] I agree with the Gen-ART reviewer that based on its content and the definitions provided in RFC 2026, this document should be … [Ballot discuss] I agree with the Gen-ART reviewer that based on its content and the definitions provided in RFC 2026, this document should be a BCP, not a Proposed Standard. I don't think the rationale provided to the OpsDir reviewer justifies it being a Proposed Standard. |
2019-01-09
|
05 | Alissa Cooper | [Ballot comment] Please fix the nits identified by the Gen-ART reviewer. |
2019-01-09
|
05 | Alissa Cooper | [Ballot Position Update] New position, Discuss, has been recorded for Alissa Cooper |
2019-01-07
|
05 | Alvaro Retana | [Ballot comment] It would be very nice to have references to (PBB-)EVPN and (PBB-)VPLS in the introduction. I think that all of these references should … [Ballot comment] It would be very nice to have references to (PBB-)EVPN and (PBB-)VPLS in the introduction. I think that all of these references should be Normative because they are "documents that must be read to understand or implement the technology". It looks like the references are made later in the text...but a couple are listed as only Informative. I don't think that the use of rfc2119 language in §2 (Requirements) is appropriate because (1) there isn't any Normative action from the requirements, and (2) these are resolved later in this document. I agree with others (Genart, Opsdir) in that this document reads more like a BCP or even an Informational document. [nit] s/(PBB-VPLS) solutions (PBB-)VPLS./(PBB-VPLS) solutions. |
2019-01-07
|
05 | Alvaro Retana | [Ballot Position Update] New position, No Objection, has been recorded for Alvaro Retana |
2019-01-07
|
05 | Benjamin Kaduk | [Ballot comment] Please be consistent about (non-)hyphenation of "VPLS A-D". Is "MP2P" really an intended acronym (vs., e.g., P2MP)? It does not appear in https://www.rfc-editor.org/materials/abbrev.expansion.txt … [Ballot comment] Please be consistent about (non-)hyphenation of "VPLS A-D". Is "MP2P" really an intended acronym (vs., e.g., P2MP)? It does not appear in https://www.rfc-editor.org/materials/abbrev.expansion.txt and is not defined, even though P2MP is, and MP2P is used some 8 times in the document. We probably need a definition and/or reference for "split-horizon". Section 2 6. The support of All-Active redundancy mode across both (PBB-)EVPN PEs and (PBB-)VPLS PEs is outside the scope of this document. The claim (not quoted) of "seamless" integration seems to only hold if All-Active redundancy mode is not in common use. Is it? Section 3.1 In this case, when a VPLS PE receives the EVPN IMET route, it MUST ignore it on the basis that it belongs to an unknown SAFI. [...] Is this "MUST" a new requirement imposed by this document, or a restatement of an existing requirement from elsewhere? Section 3.2 Please expand FEC on first usage (or define it in the terminology section). When we talk about "learned" C-MAC addresses from traffic on VPLS PWs and injecting those MAC addresses into bridge tables, RIB/FIB tables, and MAC-VRFs, are these learned C-MAC addresses coming from provider-owned equipment or customer equipment? Giving the customer the ability to inject MAC addresses without verification would probably merit a closer look (though I do note that the penultimate paragraph discusses the non-propagation of the learned addresses over the control plane). Section 3.4.2, 4.4.2 My understanding was that P2MP (PBB-)EVPN tunnels are a well-understood thing, in which case I would expect to see something more like "this document does not modify the operation of multicast P2MP EVPN tunnels" than "outside the scope of this document". Section 5 Does the extra state that (PBB-)EVPN PEs need to maintain (i.e., both the normal EVPN state and PWs to the VPLS PEs) pose any risk of DoS due to resource exhaustion? |
2019-01-07
|
05 | Benjamin Kaduk | [Ballot Position Update] New position, No Objection, has been recorded for Benjamin Kaduk |
2019-01-07
|
05 | Mirja Kühlewind | [Ballot comment] To me this documents reads more like an informational doc, providing guidance for operations but not specifying any new protocol or protocol extensions … [Ballot comment] To me this documents reads more like an informational doc, providing guidance for operations but not specifying any new protocol or protocol extensions or requirements that are mandatory to implement for interoperability. |
2019-01-07
|
05 | Mirja Kühlewind | [Ballot Position Update] New position, No Objection, has been recorded for Mirja Kühlewind |
2018-12-21
|
05 | Amy Vezza | Placed on agenda for telechat - 2019-01-10 |
2018-12-21
|
05 | Martin Vigoureux | IESG state changed to IESG Evaluation from Waiting for Writeup |
2018-12-21
|
05 | Martin Vigoureux | Ballot has been issued |
2018-12-21
|
05 | Martin Vigoureux | [Ballot Position Update] New position, Yes, has been recorded for Martin Vigoureux |
2018-12-21
|
05 | Martin Vigoureux | Created "Approve" ballot |
2018-12-21
|
05 | Martin Vigoureux | Ballot writeup was changed |
2018-12-21
|
05 | Martin Vigoureux | Ballot writeup was changed |
2018-12-19
|
05 | Pete Resnick | Request for Last Call review by GENART Completed: Ready with Issues. Reviewer: Pete Resnick. Sent review to list. |
2018-12-18
|
05 | Linda Dunbar | Request for Last Call review by OPSDIR Completed: Ready. Reviewer: Linda Dunbar. Sent review to list. |
2018-12-18
|
05 | (System) | IESG state changed to Waiting for Writeup from In Last Call |
2018-12-17
|
05 | (System) | IANA Review state changed to IANA OK - No Actions Needed from IANA - Review Needed |
2018-12-17
|
05 | Sabrina Tanamal | (Via drafts-lastcall@iana.org): IESG/Authors/WG Chairs: The IANA Functions Operator has reviewed draft-ietf-bess-evpn-vpls-seamless-integ-05, 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-evpn-vpls-seamless-integ-05, 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 |
2018-12-13
|
05 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Stephen Kent |
2018-12-13
|
05 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Stephen Kent |
2018-12-13
|
05 | Stephen Kent | Request for Last Call review by SECDIR Completed: Has Nits. Reviewer: Stephen Kent. |
2018-12-11
|
05 | Dan Harkins | Assignment of request for Last Call review by SECDIR to Dan Harkins was rejected |
2018-12-11
|
05 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Linda Dunbar |
2018-12-11
|
05 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Linda Dunbar |
2018-12-07
|
05 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Dan Harkins |
2018-12-07
|
05 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Dan Harkins |
2018-12-06
|
05 | Jean Mahoney | Request for Last Call review by GENART is assigned to Pete Resnick |
2018-12-06
|
05 | Jean Mahoney | Request for Last Call review by GENART is assigned to Pete Resnick |
2018-12-04
|
05 | Amy Vezza | IANA Review state changed to IANA - Review Needed |
2018-12-04
|
05 | Amy Vezza | The following Last Call announcement was sent out (ends 2018-12-18): From: The IESG To: IETF-Announce CC: draft-ietf-bess-evpn-vpls-seamless-integ@ietf.org, martin.vigoureux@nokia.com, Matthew Bocci , matthew.bocci@nokia.com, … The following Last Call announcement was sent out (ends 2018-12-18): From: The IESG To: IETF-Announce CC: draft-ietf-bess-evpn-vpls-seamless-integ@ietf.org, martin.vigoureux@nokia.com, Matthew Bocci , matthew.bocci@nokia.com, bess-chairs@ietf.org, bess@ietf.org Reply-To: ietf@ietf.org Sender: Subject: Last Call: ((PBB-)EVPN Seamless Integration with (PBB-)VPLS) to Proposed Standard The IESG has received a request from the BGP Enabled ServiceS WG (bess) to consider the following document: - '(PBB-)EVPN Seamless Integration with (PBB-)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 2018-12-18. 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 draft specifies procedures for backward compatibility of Ethernet VPN (EVPN) and Provider Backbone Bridge Ethernet VPN (PBB- EVPN) solutions with Virtual Private LAN Service (VPLS) and Provider Backbone Bridge VPLS (PBB-VPLS) solutions (PBB-)VPLS. It also provides mechanisms for seamless integration of these two technologies in the same MPLS/IP network on a per-VPN-instance basis. Implementation of this draft enables service providers to introduce (PBB-)EVPN PEs in their brown-field deployments of (PBB-)VPLS networks. The file can be obtained via https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-vpls-seamless-integ/ IESG discussion can be tracked via https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-vpls-seamless-integ/ballot/ The following IPR Declarations may be related to this I-D: https://datatracker.ietf.org/ipr/2472/ |
2018-12-04
|
05 | Amy Vezza | IESG state changed to In Last Call from Last Call Requested |
2018-12-04
|
05 | Martin Vigoureux | Last call was requested |
2018-12-04
|
05 | Martin Vigoureux | Ballot approval text was generated |
2018-12-04
|
05 | Martin Vigoureux | Ballot writeup was generated |
2018-12-04
|
05 | Martin Vigoureux | IESG state changed to Last Call Requested from AD Evaluation::AD Followup |
2018-12-04
|
05 | Martin Vigoureux | Last call announcement was generated |
2018-12-04
|
05 | Martin Vigoureux | Last call announcement was generated |
2018-11-27
|
05 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
2018-11-27
|
05 | Ali Sajassi | New version available: draft-ietf-bess-evpn-vpls-seamless-integ-05.txt |
2018-11-27
|
05 | (System) | New version approved |
2018-11-27
|
05 | (System) | Request for posting confirmation emailed to previous authors: Jorge Rabadan , Samer Salam , Ali Sajassi , Nick Regno |
2018-11-27
|
05 | Ali Sajassi | Uploaded new revision |
2018-08-19
|
04 | Martin Vigoureux | IESG state changed to AD Evaluation::Revised I-D Needed from AD Evaluation |
2018-06-19
|
04 | Martin Vigoureux | IESG state changed to AD Evaluation from Publication Requested |
2018-05-28
|
04 | Min Ye | Request for Last Call review by RTGDIR Completed: Ready. Reviewer: Yingzhen Qu. |
2018-05-07
|
04 | Min Ye | Request for Last Call review by RTGDIR is assigned to Yingzhen Qu |
2018-05-07
|
04 | Min Ye | Request for Last Call review by RTGDIR is assigned to Yingzhen Qu |
2018-05-07
|
04 | Martin Vigoureux | Requested Last Call review by RTGDIR |
2018-04-26
|
04 | Matthew Bocci | Tag Doc Shepherd Follow-up Underway cleared. |
2018-04-26
|
04 | Matthew Bocci | Changed consensus to Yes from Unknown |
2018-04-26
|
04 | Matthew Bocci | Intended Status changed to Proposed Standard from None |
2018-04-26
|
04 | Matthew Bocci | draft-ietf-bess-evpn-vpls-seamless-integ-04.txt Document Shepherd Write-Up (1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is this the … draft-ietf-bess-evpn-vpls-seamless-integ-04.txt Document Shepherd Write-Up (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. This is appropriate as the draft describes a set of specific procedures and protocol that must be followed in order to achieve "seamless" integration between EVPN and VPLS. The intended status is properly indicated. (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 draft specifies procedures for backward compatibility of the (PBB-)EVPN solution with (PBB-)VPLS and provides mechanisms for seamless integration of the two technologies in the same MPLS/IP network on a per-VPN-instance basis. Implementation of this draft enables service providers to introduce (PBB-)EVPN PEs in their brown- field deployments of (PBB-)VPLS networks. Working Group Summary The document was developed to provide mechanisms to enable EVPN and traditional VPLS to work together in the same network in as seamless a way as practicable. This is important for service providers migrating from old VPLS deployments to new technologies such as EVPN. There is one IPR declaration on the draft . Document Quality I have no concerns about the quality of the document. I believe it represents WG consensus, and it has been widely reviewed and discussed over a number of years. The document does not specify any MIB changes or additions which would need review. Personnel The document shepherd is Matthew Bocci (matthew.bocci@nokia.com). The responsible Area Director is Martin Vigoureux (martin.vigoureux@nokia.com). (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 reviewed v03 of the document. I had no significant technical comments, but I did make some editorial comments that were resolved in v04. (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? No concerns. The document has received adequate review. The document has been developed within the WG and reviewed over a period of a number of IETFs. (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 further review required. (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 specific concerns. (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. Each author listed in the Authors Addresses section has personally indicated that they are not aware of any IPR that has not already been declared in accordance with BCP 78 and 79. (8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures. There is one IPR declaration on the draft submitted in 2014. There was no discussion of this at the time of WG last call, although the declaration was made several years ago. (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? I am comfortable that the document represents WG consensus and has been reviewed by a reasonable number of active WG participants. It received a number of comments and significant discussion in WG last call that were addressed by the authors. There were no objections during last call, and comments were constructive and supportive of moving the draft forward. (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.) None indicated. (11) Identify any ID nits the Document Shepherd has found in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough. ID-Nits passes. (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews. There are no relevant formal review criteria. (13) Have all references within this document been identified as either normative or informative? Yes. All references are explicitly identified as informative or normative. (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 does not change the status of any existing RFCs. (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). There are no IANA actions. (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. There are no IANA actions. (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. There are no sections containing formal language that needs reviewing. |
2018-04-26
|
04 | Matthew Bocci | Responsible AD changed to Martin Vigoureux |
2018-04-26
|
04 | Matthew Bocci | IETF WG state changed to Submitted to IESG for Publication from WG Consensus: Waiting for Write-Up |
2018-04-26
|
04 | Matthew Bocci | IESG state changed to Publication Requested |
2018-04-26
|
04 | Matthew Bocci | IESG process started in state Publication Requested |
2018-04-26
|
04 | Matthew Bocci | Tag Doc Shepherd Follow-up Underway set. |
2018-04-26
|
04 | Matthew Bocci | IETF WG state changed to WG Consensus: Waiting for Write-Up from WG Document |
2018-04-26
|
04 | Matthew Bocci | Changed document writeup |
2018-04-25
|
04 | Ali Sajassi | New version available: draft-ietf-bess-evpn-vpls-seamless-integ-04.txt |
2018-04-25
|
04 | (System) | New version approved |
2018-04-25
|
04 | (System) | Request for posting confirmation emailed to previous authors: Jorge Rabadan , Samer Salam , Ali Sajassi , Nick Regno |
2018-04-25
|
04 | Ali Sajassi | Uploaded new revision |
2018-04-18
|
03 | Ali Sajassi | New version available: draft-ietf-bess-evpn-vpls-seamless-integ-03.txt |
2018-04-18
|
03 | (System) | New version approved |
2018-04-18
|
03 | (System) | Request for posting confirmation emailed to previous authors: Jorge Rabadan , Samer Salam , Ali Sajassi , Nick Regno |
2018-04-18
|
03 | Ali Sajassi | Uploaded new revision |
2018-03-28
|
02 | Ali Sajassi | New version available: draft-ietf-bess-evpn-vpls-seamless-integ-02.txt |
2018-03-28
|
02 | (System) | New version approved |
2018-03-28
|
02 | (System) | Request for posting confirmation emailed to previous authors: Jorge Rabadan , Samer Salam , Ali Sajassi , Nick Regno |
2018-03-28
|
02 | Ali Sajassi | Uploaded new revision |
2018-03-17
|
01 | Stephane Litkowski | Added to session: IETF-101: bess Tue-1550 |
2018-02-15
|
01 | Matthew Bocci | Notification list changed to Matthew Bocci <matthew.bocci@nokia.com> |
2018-02-15
|
01 | Matthew Bocci | Document shepherd changed to Matthew Bocci |
2018-02-14
|
01 | Ali Sajassi | New version available: draft-ietf-bess-evpn-vpls-seamless-integ-01.txt |
2018-02-14
|
01 | (System) | New version approved |
2018-02-14
|
01 | (System) | Request for posting confirmation emailed to previous authors: Jorge Rabadan , Samer Salam , bess-chairs@ietf.org, Ali Sajassi , Nick Regno |
2018-02-14
|
01 | Ali Sajassi | Uploaded new revision |
2015-10-14
|
00 | (System) | Notify list changed from "Martin Vigoureux" to (None) |
2015-02-21
|
00 | Martin Vigoureux | Notification list changed to "Martin Vigoureux" <martin.vigoureux@alcatel-lucent.com> |
2015-02-21
|
00 | Martin Vigoureux | Document shepherd changed to Martin Vigoureux |
2015-02-21
|
00 | Martin Vigoureux | This document now replaces draft-sajassi-bess-evpn-vpls-seamless-integ instead of None |
2015-02-21
|
00 | Ali Sajassi | New version available: draft-ietf-bess-evpn-vpls-seamless-integ-00.txt |