Provider Backbone Bridging Combined with Ethernet VPN (PBB-EVPN)
RFC 7623
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2015-10-14 |
10 | (System) | Notify list changed from sajassi@cisco.com, lizho.jin@gmail.com, nabil.n.bitar@verizon.com, aisaac71@bloomberg.net, ssalam@cisco.com, wim.henderickx@alcatel-lucent.be, "Giles Heron" <giheron@cisco.com> to lizho.jin@gmail.com |
2015-09-21 |
10 | (System) | RFC published |
2015-09-18 |
10 | (System) | RFC Editor state changed to AUTH48-DONE from AUTH48 |
2015-08-03 |
10 | (System) | RFC Editor state changed to AUTH48 from RFC-EDITOR |
2015-07-27 |
10 | (System) | RFC Editor state changed to RFC-EDITOR from EDIT |
2015-06-01 |
10 | (System) | IANA Action state changed to No IC from In Progress |
2015-06-01 |
10 | (System) | IANA Action state changed to In Progress |
2015-06-01 |
10 | Amy Vezza | IESG state changed to RFC Ed Queue from Approved-announcement sent |
2015-06-01 |
10 | (System) | RFC Editor state changed to EDIT |
2015-06-01 |
10 | (System) | Announcement was received by RFC Editor |
2015-06-01 |
10 | Amy Vezza | IESG state changed to Approved-announcement sent from Approved-announcement to be sent |
2015-06-01 |
10 | Amy Vezza | IESG has approved the document |
2015-06-01 |
10 | Amy Vezza | Closed "Approve" ballot |
2015-06-01 |
10 | Amy Vezza | Ballot writeup was changed |
2015-05-29 |
10 | Alvaro Retana | Ballot approval text was generated |
2015-05-17 |
10 | Alvaro Retana | IESG state changed to Approved-announcement to be sent from Approved-announcement to be sent::AD Followup |
2015-05-14 |
10 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
2015-05-14 |
10 | Ali Sajassi | IANA Review state changed to Version Changed - Review Needed from IANA OK - No Actions Needed |
2015-05-14 |
10 | Ali Sajassi | New version available: draft-ietf-l2vpn-pbb-evpn-10.txt |
2015-03-26 |
09 | Alia Atlas | Shepherding AD changed to Alvaro Retana |
2015-02-08 |
09 | Adrian Farrel | IESG state changed to Approved-announcement to be sent::Revised I-D Needed from Approved-announcement to be sent::Point Raised - writeup needed |
2015-02-05 |
09 | Christer Holmberg | Assignment of request for Last Call review by GENART to Christer Holmberg was rejected |
2015-02-05 |
09 | Gunter Van de Velde | Request for Last Call review by OPSDIR Completed: Ready. Reviewer: Melinda Shore. |
2015-02-05 |
09 | Cindy Morgan | IESG state changed to Approved-announcement to be sent::Point Raised - writeup needed from IESG Evaluation |
2015-02-05 |
09 | Alia Atlas | [Ballot Position Update] New position, No Objection, has been recorded for Alia Atlas |
2015-02-05 |
09 | Jari Arkko | [Ballot comment] Question. Section 8 discusses ARP snooping. Is there a need to discuss IGMP and MLD snooping as well (e.g., by referring to RFC … [Ballot comment] Question. Section 8 discusses ARP snooping. Is there a need to discuss IGMP and MLD snooping as well (e.g., by referring to RFC 4541). Note that MLD snooping might affect how packets are forwarded for neighbour discovery in IPv6. |
2015-02-05 |
09 | Jari Arkko | [Ballot Position Update] New position, No Objection, has been recorded for Jari Arkko |
2015-02-05 |
09 | Martin Stiemerling | [Ballot Position Update] New position, No Objection, has been recorded for Martin Stiemerling |
2015-02-05 |
09 | Stephen Farrell | [Ballot Position Update] New position, No Objection, has been recorded for Stephen Farrell |
2015-02-04 |
09 | Spencer Dawkins | [Ballot comment] Would expanding "PBB-EVPN" in the title be helpful to anyone except me? :-) In section 3, I read Single-Active Redundancy Mode: When … [Ballot comment] Would expanding "PBB-EVPN" in the title be helpful to anyone except me? :-) In section 3, I read Single-Active Redundancy Mode: When only a single PE, among a group of PEs attached to an Ethernet segment, is allowed to forward traffic to/from that Ethernet Segment, then the Ethernet segment is defined to be operating in Single-Active redundancy mode. All-Active Redundancy Mode: When all PEs attached to an Ethernet segment are allowed to forward traffic to/from that Ethernet Segment, then the Ethernet segment is defined to be operating in All-Active redundancy mode. and wondered if it would ever be the case that some, but not all, PEs were allowed to forward traffic. I noticed a "the the". |
2015-02-04 |
09 | Spencer Dawkins | [Ballot Position Update] New position, No Objection, has been recorded for Spencer Dawkins |
2015-02-04 |
09 | Richard Barnes | [Ballot Position Update] New position, No Objection, has been recorded for Richard Barnes |
2015-02-04 |
09 | Kathleen Moriarty | [Ballot comment] Thanks to Adrian for connecting in the SecDir review. I responded to the thread he restarted as a result of it being included … [Ballot comment] Thanks to Adrian for connecting in the SecDir review. I responded to the thread he restarted as a result of it being included in Adrian's comments already. This may be a repeat to that thread for some. My take on the review is that Catherine was asking if the advantages added by this draft also result in some security improvements over the referenced security considerations section. The referenced section mentions a problem with duplicate MAC addresses and this draft in section 10.1, 10.2, and 10.3 discuss the aggregation of MACs - does this also lead to a security advantage in that the prior concern is mitigated? Then does the advantage in 10.5 that provides more granular forwarding policy support also have a security advantage? If so, it would be good to state this, if not, a simple sentence that says no additional security considerations are added in this draft would be helpful. Here is a link to Catherine's review: https://www.ietf.org/mail-archive/web/secdir/current/msg05400.html |
2015-02-04 |
09 | Kathleen Moriarty | [Ballot Position Update] New position, No Objection, has been recorded for Kathleen Moriarty |
2015-02-04 |
09 | Alissa Cooper | [Ballot Position Update] New position, No Objection, has been recorded for Alissa Cooper |
2015-02-04 |
09 | Pete Resnick | [Ballot Position Update] New position, No Objection, has been recorded for Pete Resnick |
2015-02-04 |
09 | Brian Haberman | [Ballot Position Update] New position, No Objection, has been recorded for Brian Haberman |
2015-02-03 |
09 | Ted Lemon | [Ballot Position Update] New position, No Objection, has been recorded for Ted Lemon |
2015-02-02 |
09 | Adrian Farrel | Changed consensus to Yes from Unknown |
2015-02-01 |
09 | Joel Jaeggli | [Ballot comment] from Melinda Shore's ops-dir review: I have reviewed this document as part of the Operational directorate's ongoing effort to review all IETF documents … [Ballot comment] from Melinda Shore's ops-dir review: I have reviewed this document as part of the Operational directorate's ongoing effort to review all IETF documents being processed by the IESG. These comments were written with the intent of improving the operational aspects of the IETF drafts. Comments that are not addressed in last call may be included in AD reviews during the IESG review. Document editors and WG chairs should treat these comments just like any other last call comments. Summary: this document is ready This draft describes a mechanism for reducing the number of BGP MAC advertisement routes, provide MAC address mobility, and several other MAC handling enhancements, using Ethernet Provider Backbone Bridging combined with Ethernet VPN. This work appears to provide significant improvements to both network resource usage and in MAC address manageability. Overall the document is a bit thin on material on network management, although the material describing the behavior of the mechanisms being used in the context of different kinds of failures is quite good. The document is very clearly written and the material describing protocol operation/behavior is much appreciated. The PBB-EVPN mechanism appears to be an enormous win for very large data centers. Passed the nits tool with only a warning about the publication year not matching the current year. This document was a pleasure to read. Melinda _______________________________________________ OPS-DIR mailing list OPS-DIR@ietf.org https://www.ietf.org/mailman/listinfo/ops-dir |
2015-02-01 |
09 | Joel Jaeggli | [Ballot Position Update] New position, No Objection, has been recorded for Joel Jaeggli |
2015-01-27 |
09 | Barry Leiba | Notification list changed to sajassi@cisco.com, lizho.jin@gmail.com, nabil.n.bitar@verizon.com, aisaac71@bloomberg.net, ssalam@cisco.com, draft-ietf-l2vpn-pbb-evpn.all@tools.ietf.org, wim.henderickx@alcatel-lucent.be, "Giles Heron" <giheron@cisco.com> from sajassi@cisco.com, lizho.jin@gmail.comlizhong, nabil.n.bitar@verizon.com, aisaac71@bloomberg.net, ssalam@cisco.com, draft-ietf-l2vpn-pbb-evpn.all@tools.ietf.org, wim.henderickx@alcatel-lucent.be … Notification list changed to sajassi@cisco.com, lizho.jin@gmail.com, nabil.n.bitar@verizon.com, aisaac71@bloomberg.net, ssalam@cisco.com, draft-ietf-l2vpn-pbb-evpn.all@tools.ietf.org, wim.henderickx@alcatel-lucent.be, "Giles Heron" <giheron@cisco.com> from sajassi@cisco.com, lizho.jin@gmail.comlizhong, nabil.n.bitar@verizon.com, aisaac71@bloomberg.net, ssalam@cisco.com, draft-ietf-l2vpn-pbb-evpn.all@tools.ietf.org, wim.henderickx@alcatel-lucent.be, "Giles Heron" <giheron@cisco.com> |
2015-01-27 |
09 | Barry Leiba | [Ballot comment] Thanks for doing this without filling the document with 2119 key words. I think it works well without them. Two small comments: 1. … [Ballot comment] Thanks for doing this without filling the document with 2119 key words. I think it works well without them. Two small comments: 1. Very minor: It probably would be best to change the document's title to "Provider Backbone Bridging Combined with Ethernet VPN (PBB-EVPN)". 2. I think the reference to [PBB] has to be normative; how is it not? |
2015-01-27 |
09 | Barry Leiba | [Ballot Position Update] New position, No Objection, has been recorded for Barry Leiba |
2015-01-26 |
09 | Adrian Farrel | [Ballot comment] There was a security directorate review from Catherine Meadows <catherine.meadows@nrl.navy.mil> > I don’t see any security concerns with this draft, but I do … [Ballot comment] There was a security directorate review from Catherine Meadows <catherine.meadows@nrl.navy.mil> > I don’t see any security concerns with this draft, but I do have some > comments on the Security Considerations section. > It is very short, and all it says that the security considerations in the > EVPN draft apply directly to this draft. I assume that it is also the case > that this draft introduces no new security considerations. If so, you > should say so, and you should also say why. Also, I was wondering if > the mechanisms introduced in this draft, by introducing a greater > degree of organization in the delivery of MAC addresses, makes it > easier to detect duplicated MACs, which were mentioned as a security > risk in the Security Considerations of the EVPN draft. If this is the case, > it would be a good thing to mention here. > > I’d consider the draft somewhere between ready with nits and ready > with issues. I don’t see any real security issues here, just a Security > Considerations section that needs to be expanded a little, but this > seems to be a little more than what the secdir guidelines would call a > nit. This all seems a bit non-specific, but I have asked the authors to have a look and see whether they can generate a response and maybe suggest some text. At the same time, this document is not defining any new protocol per se, so I find it hard to suggest what extra could be written. |
2015-01-26 |
09 | Adrian Farrel | Ballot comment text updated for Adrian Farrel |
2015-01-26 |
09 | Adrian Farrel | Ballot has been issued |
2015-01-26 |
09 | Adrian Farrel | [Ballot Position Update] New position, Yes, has been recorded for Adrian Farrel |
2015-01-26 |
09 | Adrian Farrel | Created "Approve" ballot |
2015-01-26 |
09 | Adrian Farrel | IESG state changed to IESG Evaluation from Waiting for AD Go-Ahead |
2015-01-26 |
09 | (System) | IANA Review state changed to IANA OK - No Actions Needed from IANA - Review Needed |
2015-01-26 |
09 | Pearl Liang | IESG/Authors/WG Chairs: IANA has reviewed draft-ietf-l2vpn-pbb-evpn-09, which is currently in Last Call, and has the following comments: We understand that, upon approval of this document, … IESG/Authors/WG Chairs: IANA has reviewed draft-ietf-l2vpn-pbb-evpn-09, which is currently in Last Call, and has the following comments: We understand that, upon approval of this document, there are no IANA Actions that need completion. While it is helpful for the IANA Considerations section of the document to remain in place upon publication, if the authors prefer to remove it, IANA doesn't object. If this assessment is not accurate, please respond as soon as possible. |
2015-01-26 |
09 | (System) | IESG state changed to Waiting for AD Go-Ahead from In Last Call |
2015-01-22 |
09 | Tero Kivinen | Request for Last Call review by SECDIR Completed: Has Issues. Reviewer: Catherine Meadows. |
2015-01-22 |
09 | Adrian Farrel | Placed on agenda for telechat - 2015-02-05 |
2015-01-13 |
09 | Jonathan Hardwick | Request for Early review by RTGDIR Completed: Ready. Reviewer: John Drake. |
2015-01-04 |
09 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Melinda Shore |
2015-01-04 |
09 | Gunter Van de Velde | Request for Last Call review by OPSDIR is assigned to Melinda Shore |
2015-01-02 |
09 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Catherine Meadows |
2015-01-02 |
09 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Catherine Meadows |
2015-01-02 |
09 | Jonathan Hardwick | Request for Early review by RTGDIR is assigned to John Drake |
2015-01-02 |
09 | Jonathan Hardwick | Request for Early review by RTGDIR is assigned to John Drake |
2014-12-29 |
09 | Jean Mahoney | Request for Last Call review by GENART is assigned to Christer Holmberg |
2014-12-29 |
09 | Jean Mahoney | Request for Last Call review by GENART is assigned to Christer Holmberg |
2014-12-29 |
09 | Amy Vezza | IANA Review state changed to IANA - Review Needed |
2014-12-29 |
09 | Amy Vezza | The following Last Call announcement was sent out: From: The IESG <iesg-secretary@ietf.org> To: IETF-Announce <ietf-announce@ietf.org> Reply-To: ietf@ietf.org Sender: <iesg-secretary@ietf.org> Subject: Last Call: <draft-ietf-l2vpn-pbb-evpn-09.txt> (PBB-EVPN) to … The following Last Call announcement was sent out: From: The IESG <iesg-secretary@ietf.org> To: IETF-Announce <ietf-announce@ietf.org> Reply-To: ietf@ietf.org Sender: <iesg-secretary@ietf.org> Subject: Last Call: <draft-ietf-l2vpn-pbb-evpn-09.txt> (PBB-EVPN) to Proposed Standard The IESG has received a request from an individual submitter to consider the following document: - 'PBB-EVPN' <draft-ietf-l2vpn-pbb-evpn-09.txt> 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 2015-01-26. 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 discusses how Ethernet Provider Backbone Bridging (PBB) can be combined with Ethernet VPN (EVPN) in order to reduce the number of BGP MAC advertisement routes by aggregating Customer/Client MAC (C-MAC) addresses via Provider Backbone MAC address (B-MAC), provide client MAC address mobility using C-MAC aggregation, confine the scope of C-MAC learning to only active flows, offer per site policies and avoid C-MAC address flushing on topology changes. The combined solution is referred to as PBB-EVPN. Conventions The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-l2vpn-pbb-evpn/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-l2vpn-pbb-evpn/ballot/ The following IPR Declarations may be related to this I-D: http://datatracker.ietf.org/ipr/1908/ |
2014-12-29 |
09 | Amy Vezza | IESG state changed to In Last Call from Last Call Requested |
2014-12-29 |
09 | Amy Vezza | Last call announcement was changed |
2014-12-28 |
09 | Adrian Farrel | Ballot writeup was changed |
2014-12-28 |
09 | Adrian Farrel | Ballot writeup was changed |
2014-12-28 |
09 | Adrian Farrel | Last call was requested |
2014-12-28 |
09 | Adrian Farrel | Ballot approval text was generated |
2014-12-28 |
09 | Adrian Farrel | IESG state changed to Last Call Requested from AD Evaluation |
2014-12-28 |
09 | Adrian Farrel | Last call announcement was changed |
2014-12-28 |
09 | Adrian Farrel | Last call announcement was generated |
2014-12-28 |
09 | Adrian Farrel | Last call announcement was generated |
2014-12-28 |
09 | Adrian Farrel | AD Review ===== Sorry for sitting on this so long: a number of other things got in the way. I have done my usual AD … AD Review ===== Sorry for sitting on this so long: a number of other things got in the way. I have done my usual AD review and don't have anything substantial. I'll start the IETF last call (longer than 2 weeks because of the holiday season) and you can fix any nits when convenient. Thanks for the work, Adrian === The RFC editor will require that the Contributors section is moved to the end per the latest version of their style guide. I don't think you need to do that now unless you have the document open for edits. --- 7.4.1 uses AC without expansion. --- Section 9.3 was a good read :-) --- Section 10 needs to point at Section 4 (not Section 3). I don't really like the title of Section 10 - too much of a sales pitch. Maybe... 10. Assessing PBB-EVPN Against the Requirements In this section, we discuss how the PBB-EVPN solution addresses the requirements set forth in section 4 above. Although I did wonder why the sub-sections in section 10 were not in one-to-one correspondence with those in section 4. --- The figures seem to be numbered 1, 2, 8, 7, 9 which may be seen as a trifle idiosyncratic. --- Ali and Lizhong had an email exchange with a nit to be fixed. |
2014-12-10 |
09 | Adrian Farrel | Ballot writeup was generated |
2014-12-05 |
09 | Adrian Farrel | IESG state changed to AD Evaluation from Publication Requested |
2014-12-01 |
09 | Adrian Farrel | IETF WG state changed to Submitted to IESG for Publication from WG Document |
2014-12-01 |
09 | Adrian Farrel | Draft Title: PBB-EVPN Draft Name: draft-ietf-l2vpn-pbb-evpn-09 (1) What type of RFC is being requested (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or Historic)? Why is … Draft Title: PBB-EVPN Draft Name: draft-ietf-l2vpn-pbb-evpn-09 (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 the proper type of RFC as this is a key EVPN draft - providing enhanced scaling by combining PBB and EVPN. The type of RFC is indicated in the title page header. (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 discusses how Ethernet Provider Backbone Bridging (PBB) can be combined with Ethernet VPN (EVPN) in order to reduce the number of BGP MAC advertisement routes by aggregating Customer/Client MAC (C-MAC) addresses via Provider Backbone MAC address (B-MAC), provide client MAC address mobility using C-MAC aggregation, confine the scope of C-MAC learning to only active flows, offer per site policies and avoid C-MAC address flushing on topology changes. The combined solution is referred to as PBB-EVPN. Working Group Summary: This document was an L2VPN Working Group document, and w reviewed in the working group through multiple iterations of the draft. The document passed WG last call in the L2VPN WG but is being advanced as AD Sponsored because that WG has closed. Document Quality: The document is of roughly average length (22 pages). It is well structured, but needs to be read in the context of the base EVPN RFC (draft-ietf-l2vpn-evpn-11- should be an RFC soon), and requires knowledge of Ethernet bridging (including PBB). The document has been through multiple revisions and is now sufficiently stable to progress to RFC, and more importantly to be used as a reference for creating interoperable implementations (in fact PBB EVPN has already been implemented by multiple vendors with more implementations in progress). Personnel: Document Shepherd: Giles Heron (giheron@cisco.com) Area Director: Adrian Farrel (adrian@olddog.co.uk) (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 did a thorough review of the text of version -07 of the draft, leading to the authors issuing version -08 with a large number of fixes. The Document Shepherd then reviewed version -08 of the draft, following which the authors issued version -09 with more fixes. The shepherd also did a scan through the mail archives and previous IETF meeting minutes to review debates on the draft. (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. From a security perspective the solution inherits the characteristics of the base EVPN draft (draft-ietf-l2vpn-evpn-11) (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? Yes. (8) Has an IPR disclosure been filed that references this document? If so, summarize any WG discussion and conclusion regarding the IPR disclosures. No IPR has been filed against this draft. However IPR was previously filed by Juniper, Cisco and Alcatel-Lucent (ID #1751, 1910, 2362 and 2363) against the base EVPN spec (draft-ietf-l2vpn-evpn-11). (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? The L2VPN WG consensus was previously noted as solid. 17 individuals supported the draft during WG LC, with nobody giving a differing opinion. There was much more discussion/debate around the base EVPN draft (draft-ietf-l2vpn-evpn-11) than around this draft. (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 http://www.ietf.org/tools/idnits/ and the Internet-Drafts Checklist). Boilerplate checks are not enough; this check needs to be thorough. No nits. (12) Describe how the document meets any required formal review criteria, such as the MIB Doctor, media type, and URI type reviews. No formal review required. (13) Have all references within this document been identified as either normative or informative? Yes. The Document Shepherd checked all this as part of the document review. (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 - there is only one normative reference (to the base EVPN spec - draft-ietf-l2vpn-evpn-11, which is already with the IESG). (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 - we would anticipate the base EVPN spec (draft-ietf-l2vpn-evpn-11) will be published before this doc (since it has been with the IESG for over 4 months). (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. No - no impact on status of 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 considerations beyond those noted in the base EVPN spec (draft-ietf-l2vpn-evpn-11). (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. No new registries. (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. No sections written in a formal language. |
2014-12-01 |
09 | Adrian Farrel | Notification list changed to sajassi@cisco.com, lizho.jin@gmail.comlizhong, nabil.n.bitar@verizon.com, aisaac71@bloomberg.net, ssalam@cisco.com, draft-ietf-l2vpn-pbb-evpn.all@tools.ietf.org, wim.henderickx@alcatel-lucent.be, "Giles Heron" <giheron@cisco.com> from sajassi@cisco.com, lizho.jin@gmail.comlizhong, nabil.n.bitar@verizon.com, aisaac71@bloomberg.net, ssalam@cisco.com, draft-ietf-l2vpn-pbb-evpn.all@tools.ietf.org, wim.henderickx@alcatel-lucent.be |
2014-12-01 |
09 | Adrian Farrel | Document shepherd changed to Giles Heron |
2014-12-01 |
09 | Adrian Farrel | Assigned to Routing Area |
2014-12-01 |
09 | Adrian Farrel | Note added 'This document passed WG last call in the L2VPN working group and is being advanced as AD sponsored because that WG has now … Note added 'This document passed WG last call in the L2VPN working group and is being advanced as AD sponsored because that WG has now been closed.' |
2014-12-01 |
09 | Adrian Farrel | Intended Status changed to Proposed Standard |
2014-12-01 |
09 | Adrian Farrel | IESG process started in state Publication Requested |
2014-12-01 |
09 | (System) | Earlier history may be found in the Comment Log for /doc/draft-sajassi-l2vpn-pbb-evpn/ |
2014-11-20 |
09 | Cindy Morgan | Changed field(s): group,abstract |
2014-10-24 |
09 | Ali Sajassi | New version available: draft-ietf-l2vpn-pbb-evpn-09.txt |
2014-10-19 |
08 | Ali Sajassi | New version available: draft-ietf-l2vpn-pbb-evpn-08.txt |
2014-06-19 |
07 | Ali Sajassi | New version available: draft-ietf-l2vpn-pbb-evpn-07.txt |
2013-10-21 |
06 | Ali Sajassi | New version available: draft-ietf-l2vpn-pbb-evpn-06.txt |
2013-07-15 |
05 | Ali Sajassi | New version available: draft-ietf-l2vpn-pbb-evpn-05.txt |
2013-02-25 |
04 | Ali Sajassi | New version available: draft-ietf-l2vpn-pbb-evpn-04.txt |
2012-06-20 |
03 | Ali Sajassi | New version available: draft-ietf-l2vpn-pbb-evpn-03.txt |
2012-03-30 |
02 | Ali Sajassi | New version available: draft-ietf-l2vpn-pbb-evpn-02.txt |
2012-03-11 |
01 | Ali Sajassi | New version available: draft-ietf-l2vpn-pbb-evpn-01.txt |
2012-02-27 |
00 | Ali Sajassi | New version available: draft-ietf-l2vpn-pbb-evpn-00.txt |