LDP Extensions for Optimized MAC Address Withdrawal in a Hierarchical Virtual Private LAN Service (H-VPLS)
draft-ietf-l2vpn-vpls-ldp-mac-opt-13
Revision differences
Document history
Date | Rev. | By | Action |
---|---|---|---|
2014-09-10
|
13 | (System) | RFC Editor state changed to AUTH48-DONE from AUTH48 |
2014-08-26
|
13 | (System) | RFC Editor state changed to AUTH48 from RFC-EDITOR |
2014-08-20
|
13 | (System) | RFC Editor state changed to RFC-EDITOR from AUTH |
2014-08-18
|
13 | (System) | RFC Editor state changed to AUTH from EDIT |
2014-07-24
|
13 | (System) | IANA Action state changed to RFC-Ed-Ack from Waiting on RFC Editor |
2014-07-23
|
13 | (System) | IANA Action state changed to Waiting on RFC Editor from Waiting on Authors |
2014-07-03
|
13 | (System) | IANA Action state changed to Waiting on Authors from In Progress |
2014-07-01
|
13 | Cindy Morgan | IESG state changed to RFC Ed Queue from Approved-announcement sent |
2014-07-01
|
13 | (System) | RFC Editor state changed to EDIT |
2014-07-01
|
13 | (System) | Announcement was received by RFC Editor |
2014-06-30
|
13 | (System) | IANA Action state changed to In Progress |
2014-06-30
|
13 | Amy Vezza | IESG state changed to Approved-announcement sent from Approved-announcement to be sent |
2014-06-30
|
13 | Amy Vezza | IESG has approved the document |
2014-06-30
|
13 | Amy Vezza | Closed "Approve" ballot |
2014-06-30
|
13 | Adrian Farrel | IESG state changed to Approved-announcement to be sent from Approved-announcement to be sent::Point Raised - writeup needed |
2014-06-30
|
13 | Adrian Farrel | Ballot approval text was generated |
2014-06-30
|
13 | Adrian Farrel | Ballot writeup was changed |
2014-06-27
|
13 | Don Fedyk | IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed |
2014-06-27
|
13 | Don Fedyk | New version available: draft-ietf-l2vpn-vpls-ldp-mac-opt-13.txt |
2014-06-19
|
12 | Tero Kivinen | Closed request for Last Call review by SECDIR with state 'No Response' |
2014-06-12
|
12 | Robert Sparks | Request for Telechat review by GENART Completed: Ready. Reviewer: Robert Sparks. |
2014-06-12
|
12 | Cindy Morgan | IESG state changed to Approved-announcement to be sent::Point Raised - writeup needed from IESG Evaluation |
2014-06-12
|
12 | Benoît Claise | [Ballot comment] "Discussion with Sue about her OPS DIR review is still ongoing. Hope this will be fully resolved before the document is published." Below … [Ballot comment] "Discussion with Sue about her OPS DIR review is still ongoing. Hope this will be fully resolved before the document is published." Below is the latest update received: Status: Not ready, but 80%-90% there. Short time with author and review should fix. ================================== Why: Operations issues not 100%. However, a few rounds of text change discussions should fix. Will engage with authors to complete the discussion. What’s good: 3.0 Overview - nice addition, section 5.1 and 5.2 Status: Technical issues: Problem 1: Negotiation is outside your context (to be considered) Description: Negotiation being outside your context does not mean you cannot flag that a flush has been part of a negotiated Flush entity. Have all users of MAC flush set a flag bit if the setting is negotiated. This may help you debugging of this feature distribution. Status: Do not see where this was completely or answers. Answer may be no/yes in the text – but I cannot tell. Authors simply need to tell me if looked at it – said not useful or X is wrong with the idea. Where saw change: Section 3.0 – positive MAC flushes must be always be handled. Section 3.2 – operator can choose optimized flush. Section 5.1.2 – States it applies when optimized flush is supported/no-supported. 5.1.3 specifies actions for optimized Flush. [What’s missing]: Operation section really doesn’t tie together the above changes, and make it easier for the reader to find the solution to problem 1 stated above. Since the authors are very good at this technology and good authors, I think it is simply an oversight that they will fix. If the authors wish to engage with a round of text, I’m glad to work toward this with the authors. Problem 2: fix in 5.2.1 : Very nice work on clear specification. Kudos to the Authors on careful description. This will really help interoperability. Status: fixed Style: Author used their current form rather than a numbered form. OK with reviewer. Editorial: MS-PW – is not defined. I still think it would be useful. Style – OK with reviewer. Problem 3: negotiation – Fall Back: if one side negotiates and expects this option, and the other side does not. Status: Greatly improved. Still does not tie it together with Section 6, para 1-3. It is 90% of the way there, but it still leaves a medium level reader trying to connect the dots. Really, this is the same comment as problem 1. I think the authors are 80-90% the way there, but I really cannot tie section back to the appropriate answers in previous sections. Great progress toward this is made all over the document. An analogy – I can see lines and dots and most of the picture, but it is still fuzzy here and there. Answer: I think a few rounds with the authors. Note: I will help the authors to resolve this comment quickly. Please me let me know if the authors sent email and I missed it. Problem 4: IANA – Looks fixed to me. |
2014-06-12
|
12 | Benoît Claise | [Ballot Position Update] New position, No Objection, has been recorded for Benoit Claise |
2014-06-12
|
12 | Stephen Farrell | [Ballot comment] - general: This draft has some acronyms that conflict with other ITEF things, specifically TLS and MTU. Those might be worth emphasising but … [Ballot comment] - general: This draft has some acronyms that conflict with other ITEF things, specifically TLS and MTU. Those might be worth emphasising but I expect that you'd rather not, which is fine. I also found this a bit of a hard read, mostly due to a lack of background, so some of my comments may be off-base. - MTU-s - how "multi" tenant? Are there mutually mistrusting customers using the same node/host here? - Even with LDP authentication, isn't there the potential that an authenticated actor DoS'es others by causing their MAC addresses to be flushed? That seems to imply some form of authorization (e.g. mapping authenticated identities to MAC addresses) is required - is that defined somewhere else? If not, why doesn't it need to be defined here? If it does need to be defined here, you probably only need to say that such a mapping MUST be maintained. - section 3: I can't really parse this "This is accomplished by sending an LDP Address Withdraw Message from the PE that is no longer connected to the MTU-s with the primary PW, with the list of MAC addresses to be removed to all other PEs over the corresponding LDP sessions [RFC4762]." Could you break it up to make it clearer? |
2014-06-12
|
12 | Stephen Farrell | [Ballot Position Update] New position, No Objection, has been recorded for Stephen Farrell |
2014-06-11
|
12 | Joel Jaeggli | [Ballot Position Update] New position, No Objection, has been recorded for Joel Jaeggli |
2014-06-11
|
12 | Richard Barnes | [Ballot Position Update] New position, No Objection, has been recorded for Richard Barnes |
2014-06-11
|
12 | Pete Resnick | [Ballot Position Update] New position, No Objection, has been recorded for Pete Resnick |
2014-06-11
|
12 | Kathleen Moriarty | [Ballot Position Update] New position, No Objection, has been recorded for Kathleen Moriarty |
2014-06-11
|
12 | Alissa Cooper | [Ballot Position Update] New position, No Objection, has been recorded for Alissa Cooper |
2014-06-11
|
12 | Ted Lemon | [Ballot Position Update] New position, No Objection, has been recorded for Ted Lemon |
2014-06-10
|
12 | Alia Atlas | [Ballot Position Update] New position, Yes, has been recorded for Alia Atlas |
2014-06-10
|
12 | Brian Haberman | [Ballot Position Update] New position, No Objection, has been recorded for Brian Haberman |
2014-06-09
|
12 | Jari Arkko | [Ballot Position Update] New position, No Objection, has been recorded for Jari Arkko |
2014-06-09
|
12 | Spencer Dawkins | [Ballot Position Update] New position, No Objection, has been recorded for Spencer Dawkins |
2014-06-09
|
12 | Martin Stiemerling | [Ballot Position Update] New position, No Objection, has been recorded for Martin Stiemerling |
2014-06-06
|
12 | Gunter Van de Velde | Request for Telechat review by OPSDIR Completed: Not Ready. Reviewer: Susan Hares. |
2014-06-06
|
12 | Gunter Van de Velde | Request for Telechat review by OPSDIR is assigned to Susan Hares |
2014-06-06
|
12 | Gunter Van de Velde | Request for Telechat review by OPSDIR is assigned to Susan Hares |
2014-06-05
|
12 | Jean Mahoney | Request for Telechat review by GENART is assigned to Robert Sparks |
2014-06-05
|
12 | Jean Mahoney | Request for Telechat review by GENART is assigned to Robert Sparks |
2014-06-03
|
12 | (System) | IANA Review state changed to IANA OK - Actions Needed from Version Changed - Review Needed |
2014-06-03
|
12 | Barry Leiba | [Ballot Position Update] New position, No Objection, has been recorded for Barry Leiba |
2014-06-03
|
12 | Adrian Farrel | Ballot has been issued |
2014-06-03
|
12 | Adrian Farrel | [Ballot Position Update] New position, Yes, has been recorded for Adrian Farrel |
2014-06-03
|
12 | Adrian Farrel | Created "Approve" ballot |
2014-06-03
|
12 | Adrian Farrel | Ballot writeup was changed |
2014-06-03
|
12 | Adrian Farrel | Changed consensus to Yes from Unknown |
2014-06-03
|
12 | Adrian Farrel | Placed on agenda for telechat - 2014-06-12 |
2014-06-03
|
12 | Adrian Farrel | IESG state changed to IESG Evaluation from Waiting for AD Go-Ahead::AD Followup |
2014-06-03
|
12 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
2014-06-03
|
12 | Don Fedyk | IANA Review state changed to Version Changed - Review Needed from IANA OK - Actions Needed |
2014-06-03
|
12 | Don Fedyk | New version available: draft-ietf-l2vpn-vpls-ldp-mac-opt-12.txt |
2014-05-03
|
11 | Gunter Van de Velde | Request for Last Call review by OPSDIR Completed: Serious Issues. Reviewer: Susan Hares. |
2014-04-10
|
11 | Adrian Farrel | IESG state changed to Waiting for AD Go-Ahead::Revised I-D Needed from Waiting for AD Go-Ahead |
2014-04-08
|
11 | (System) | IESG state changed to Waiting for AD Go-Ahead from In Last Call |
2014-04-07
|
11 | Robert Sparks | Request for Last Call review by GENART Completed: Ready with Issues. Reviewer: Robert Sparks. |
2014-04-01
|
11 | (System) | IANA Review state changed to IANA OK - Actions Needed from IANA - Review Needed |
2014-04-01
|
11 | Amanda Baber | IESG/Authors/WG Chairs: IANA has reviewed draft-ietf-l2vpn-vpls-ldp-mac-opt-11. Authors should review the comments and/or questions below. Please report any inaccuracies and respond to any questions as soon … IESG/Authors/WG Chairs: IANA has reviewed draft-ietf-l2vpn-vpls-ldp-mac-opt-11. Authors should review the comments and/or questions below. Please report any inaccuracies and respond to any questions as soon as possible. IANA's reviewer has the following comments/questions: IANA understands that, upon approval of this document, there are two actions which IANA must complete. First, in the TLV Type Name Space registry in Label Distribution Protocol (LDP) Parameters at http://www.iana.org/assignments/ldp-namespaces Three new TLV Type Names are to be registered as follows: Value: [ TBD-at-registration ] Description: MAC Flush Parameters TLV Reference: [ RFC-to-be ] Value: [ TBD-at-registration ] Description: PBB BMAC List Sub-TLV Reference: [ RFC-to-be ] Value: [ TBD-at-registration ] Description: PBB ISID List Sub-TLV Reference: [ RFC-to-be ] IANA notes that the values for these new TLV Type Names are to be allocated from the unassigned range 0x0405-0x04FF. Second, a new registry called "MAC Flush Flags" will be created in the Label Distribution Protocol (LDP) Parameters page at http://www.iana.org/assignments/ldp-namespaces/ The registration procedure is Standards Action as defined by RFC 5226. There are initial registration in the new registry as follows: Bit number | Hex | Abbreviation | Description | Reference -----------+------+--------------+------------------+------------ 0 | 0x80 | C | Context | [This.I-D] 1 | 0x40 | N | Negative flush | [This.I-D] 2-7 | | | Unassigned | IANA understands that these are the only actions required to be completed upon approval of this document. Note: The actions requested in this document will not be completed until the document has been approved for publication as an RFC. This message is only to confirm what actions will be performed. |
2014-03-28
|
11 | Tina Tsou | Request for Last Call review by OPSDIR is assigned to Susan Hares |
2014-03-28
|
11 | Tina Tsou | Request for Last Call review by OPSDIR is assigned to Susan Hares |
2014-03-27
|
11 | Jean Mahoney | Request for Last Call review by GENART is assigned to Robert Sparks |
2014-03-27
|
11 | Jean Mahoney | Request for Last Call review by GENART is assigned to Robert Sparks |
2014-03-27
|
11 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Sam Hartman |
2014-03-27
|
11 | Tero Kivinen | Request for Last Call review by SECDIR is assigned to Sam Hartman |
2014-03-25
|
11 | Cindy Morgan | IANA Review state changed to IANA - Review Needed |
2014-03-25
|
11 | Cindy Morgan | The following Last Call announcement was sent out: From: The IESG To: IETF-Announce CC: Reply-To: ietf@ietf.org Sender: Subject: Last Call: (LDP Extensions for Optimized MAC … The following Last Call announcement was sent out: From: The IESG To: IETF-Announce CC: Reply-To: ietf@ietf.org Sender: Subject: Last Call: (LDP Extensions for Optimized MAC Address Withdrawal in H-VPLS) to Proposed Standard The IESG has received a request from the Layer 2 Virtual Private Networks WG (l2vpn) to consider the following document: - 'LDP Extensions for Optimized MAC Address Withdrawal in H-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 2014-04-08. 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 RFC4762 describes a mechanism to remove or unlearn MAC addresses that have been dynamically learned in a Virtual Private LAN Service (VPLS) Instance for faster convergence on topology change. The procedure also removes MAC addresses in the VPLS that do not require relearning due to such topology change. This document defines an enhancement to the MAC Address Withdrawal procedure with empty MAC List from RFC4762, which enables a Provider Edge(PE) device to remove only the MAC addresses that need to be relearned. Additional extensions to RFC4762 MAC Withdrawal procedures are specified to provide optimized MAC flushing for the Provider Backbone Bridging (PBB)VPLS specified in RFC7041. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-l2vpn-vpls-ldp-mac-opt/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-l2vpn-vpls-ldp-mac-opt/ballot/ The following IPR Declarations may be related to this I-D: http://datatracker.ietf.org/ipr/1749/ |
2014-03-25
|
11 | Cindy Morgan | IESG state changed to In Last Call from Last Call Requested |
2014-03-25
|
11 | Adrian Farrel | Last call was requested |
2014-03-25
|
11 | Adrian Farrel | Ballot approval text was generated |
2014-03-25
|
11 | Adrian Farrel | IESG state changed to Last Call Requested from AD Evaluation::AD Followup |
2014-03-25
|
11 | Adrian Farrel | Last call announcement was changed |
2014-03-25
|
11 | Adrian Farrel | Last call announcement was generated |
2014-03-25
|
11 | (System) | Sub state has been changed to AD Followup from Revised ID Needed |
2014-03-25
|
11 | Don Fedyk | New version available: draft-ietf-l2vpn-vpls-ldp-mac-opt-11.txt |
2014-03-11
|
10 | Adrian Farrel | AD review ========= Hi authors, I've picked up this document after we reshuffled the working groups. At this stage in the proceedings I normally do … AD review ========= Hi authors, I've picked up this document after we reshuffled the working groups. At this stage in the proceedings I normally do an AD review to try to catch issues that would otherwise show up in IETF last call, directorate reviews, or IESG evaluation. My intention is to fix them as early as possible so that everyone else gets a clean document to review and the process runs a bit more smoothly for you. On the other hand, I see that this document has been sitting post publication request for some time, and I don't want to hold it up any more. So I am splitting my comments into two sections: - things that absolutely need to be fixed before we can continue - other issues, typos, questions. I'd love for you to handle the second category now as well, but if you prefer you can just focus on the first category and we'll pick the others up in IETF last call. For the moment, I'll put the document into "Revised I-D Needed" state for the first category. When I see a revision (with or without fixes for the second category) I'll move the document along. As usual, all of my comments are open for discussion. Thanks for the work, Adrian ======= == Must Fix == Section 7 needs some work. - Please split it into 7.1 and 7.2 - Please identify exactly which registries you want code-points from - For the LDP TLV you need to say which range you want the assignment from (since there seems to be a set of sub-ranges that are preferred for different uses). - Are you asking for a new subregistry for the sub-TLVs (such as the "MAC Flush Parameters Sub-TLVs" registry)? If not, where are the allocations coming from? If so, what is the allocation policy for new allocations, and what does the registry table look like? - Do you need a registry for the flags in the MAC Flush Parameters TLV? == Other Issues === Terminology The RFC Editor will require that the first section of the document is the Introduction. Notwithstanding the pointers to other documents that define terminology, you need to expand some acronyms on first use. The Abstract must be treated as a completely standalone piece of text so expansions are needed there and on first use in the body of the text. I see: PE PW PBB MTU-s PE-rs LDP FEC MSTP Actually, once you move the Terminology section down, I think you'll find that you have many of the expansions in place. --- I wonder what value Figure 1 has given that Figure 2 illustrates the same point with the added value of showing the mesh as a real mesh. --- Section 4 This document describes the problems in detail with respective to various MAC flush actions described in section 2. s/document/section/ --- Section 5 This section describes the solution for the requirements described in section 3. s/3/4/? --- Section 5.1.1 The MAC Flush TLV SHOULD be placed after the existing TLVs in MAC Flush message in [RFC4762]. Are LDP TLVs order-sensitive, or is this a special requirement? --- If I read section 6 correctly, I see that you are comfortable with the "undesired" over-flushing that would result from a flush where the new TLV is not understood and the operator has "made a mistake" or chosen to not check that the TLV is supported. Do I have this right? --- Section 8 seems a bit light. A reference to RFC 5920 and RFC 6952 would not hurt. Maybe 5036, itself, should be mentioned. It seems to me that something you can usefully say is that the extensions defined here optimise the flushing and so the risk of security attacks is reduced. However, in the event that the configuration of support for the new TLV can be spoofed, sub-optimal behavior will be seen. Wrt the data plane, presumably, causing MAC flush when not needed is a bad thing? |
2014-03-11
|
10 | Adrian Farrel | IESG state changed to AD Evaluation::Revised I-D Needed from AD Evaluation |
2014-03-11
|
10 | Adrian Farrel | Ballot writeup was changed |
2014-03-11
|
10 | Adrian Farrel | Ballot writeup was generated |
2014-03-11
|
10 | Adrian Farrel | Draft Title: Requirements for Metro Ethernet Forum (MEF)Ethernet-Tree (E-Tree) Support in L2VPN Draft Name: draft-ietf-l2vpn-vpls-ldp-mac-opt-10 … Draft Title: Requirements for Metro Ethernet Forum (MEF)Ethernet-Tree (E-Tree) Support in L2VPN Draft Name: draft-ietf-l2vpn-vpls-ldp-mac-opt-10 (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? Proposed Standard This is the proper type of RFC as the document defines new protocol extensions and mac flush procedures for Virtual Private LAN Service (VPLS) and PBB-VPLS services upon access topology changes. (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 defines new procedures for MAC flushing in VPLS, H-VPLS and PBB- VPLS services upon access topology changes. These procedures cover additional additional scenarios to that covered RFC 4762 for H-VPLS. MAC flushing is a mechanism used to minimize traffic black-holing time when reachability to MAC addresses changes due to topology access changes. In particular, this document describes procedures for MTU-s initiated MAC flush when MTU-s is dual-homed to provider edges (PEs) over an active and standby Pseudowires, and the propagation of the MAC flush message over the VPLS core and processing at PEs. It also describes a new optimized MAC flush mechanism termed "negative flush" that enables PEs with instances of a VPLS instance to flush the MAC entries reachable via the PE where the topology change was experienced. This is opposed to the current procedure defined in RFC 4762 which cause all MAC addresses previously learned to be flushed except those that are learned from the PE that initiates the flush. Lastly, this document defines the MAC flush and optimized MAC flush for PBB-VPLS services. Working Group Summary: This document is an L2VPN Working Group document. It has gone through a few iterations that addressed comments received from the Working group and comments from the WG chairs. The draft got good support when it was adopted as a WG draft. The Working Group last call got no feedback from the Working Group and the only comments that needed to be addressed were those of the WG chairs. Document Quality: The document has OK quality. It is clear on the technical content and written with reasonable English and layout. The draft has authors from a couple companies that claim to have implemented the solution albeit no interoperability testing was done. Personnel: Document Shepherd: Nabil Bitar (nabil.n.bitar@verizon.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 full review of version 6 and version 8, and provided comments to the authors that were addressed in versions 7 and 8 and last in version 10, as described earlier. (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? The lack of feedback during the last call was a concern, but the document content is sound. The document had good support early on. It may be worthwhile undergoing routing directorate review as well. (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 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. There is an IP disclosure filed by Alcatel-Lucent against version 05 of this document. It is ID # 1749. There was no working group discussion about this 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? The current draft is supported by individuals that had authored and contributed to the draft. Few more supported the adoption of this draft as a Working Group draft early on. There was no objection raised against this document. (10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarize 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. None. (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 - all normative references are RFCs. (15) Are there downward normative 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. 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). The IANA registry identified is that of LDP. The document requests the allocation of a new LDP TLV named "MAC Flush Parameters" and two sub-TLVs. (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. This document requests code point for following LDP TLV: o MAC Flush Parameters TLV. Also this document requests two Sub-TLV values for o PBB BMAC List Sub-TLV 0x01 IANA TBA o PBB ISID List Sub-TLV 0x02 IANA TBA (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-03-11
|
10 | Adrian Farrel | IESG state changed to AD Evaluation from Publication Requested |
2014-03-05
|
10 | Cindy Morgan | Shepherding AD changed to Adrian Farrel |
2014-02-07
|
10 | Amy Vezza | Draft Title: Requirements for Metro Ethernet Forum (MEF)Ethernet-Tree (E-Tree) Support in L2VPN Draft Name: draft-ietf-l2vpn-vpls-ldp-mac-opt-10 … Draft Title: Requirements for Metro Ethernet Forum (MEF)Ethernet-Tree (E-Tree) Support in L2VPN Draft Name: draft-ietf-l2vpn-vpls-ldp-mac-opt-10 (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? Proposed Standard This is the proper type of RFC as the document defines new protocol extensions and mac flush procedures for Virtual Private LAN Service (VPLS) and PBB-VPLS services upon access topology changes. (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 defines new procedures for MAC flushing in VPLS, H-VPLS and PBB-VPLS services upon access topology changes. These procedures cover additional additional scenarios to that covered RFC 4762 for H-VPLS. MAC flushing is mechanism used to minimize traffic black-holing time when reachability to MAC addresses changes due to topology access changes. In particular, this document describes procedures for MTU-s initiated MAC flush when MTU-s is dual-homed to provider edges (PEs) over an active and standby Pseudowires, and the propagation of the MAC flush message over the VPLS core and processing at PEs. It also describes a new optimized MAC flush mechanism termed "negative flush" that enables PEs with instances of a VPLS instance to slush the MAC entries reachable via the PE where the topology change was experienced. This is apposed to the current procedure defined in RFC 4762 which cause all MAC addresses previously learned to be flushed except those that are learned from the PE that initiates the flush. Last, this document defines the MAC flush and optimized MAC flush for PBB-VPLS services. Working Group Summary: This document is an L2VPN Working Group document. It has gone through few iterations that addressed few comments received from the Working group and comments from the WG chairs. The draft has authors from a couple companies that claim to have implemented the solution albeit no interoperability testing was done. The draft got good support when it was adopted as WG draft. The last Working group cal got no feedback from the Working group and the only comments that needed toe addressed were those of the WG chairs. Document Quality: The document has OK quality. It is clear on the technical content and written with reasonable English and layout. Personnel: Document Shepherd: Nabil Bitar (nabil.n.bitar@verizon.com) Area Director: Stewart Bryant (stbryant@cisco.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 did a full review of version 6 and version 8, and provided comments to the authors that were addressed in versions 7 and 8 and last in version 10, as described earlier. (4) Does the document Shepherd have any concerns about the depth or breadth of the reviews that have been performed? The lack of feedback during the last call was a concern, but the document content is sound. The document had good support early on. It may be worthwhile undergoing routing directorate review as well. (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 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. There is an IP disclosure filed by Alcatel-Lucent against version 05 of this document. It is ID # 1749. There was no working grow discussion about this 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? The current draft is supported by individuals that had authored and contributed to the draft. Few more supported the adoption of this draft as a Working Group draft early on. There was no objection raised against this document. (10) Has anyone threatened an appeal or otherwise indicated extreme discontent? If so, please summarize 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. None. (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 - all normative references are RFCs. (15) Are there downward normative 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. 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). The IANA registry identified is that of LDP. The document requests the allocation of a new LDP TLV named "MAC Flush Parameters" and two sub-TLVs. (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. This document requests code point for following LDP TLV: o MAC Flush Parameters TLV. Also this document requests two Sub-TLV values for o PBB BMAC List Sub-TLV 0x01 IANA TBA o PBB ISID List Sub-TLV 0x02 IANA TBA (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-02-07
|
10 | Amy Vezza | Document shepherd changed to Dr. Nabil N. Bitar |
2014-02-07
|
10 | Amy Vezza | Intended Status changed to Proposed Standard |
2014-02-07
|
10 | Amy Vezza | IESG process started in state Publication Requested |
2014-02-07
|
10 | (System) | Earlier history may be found in the Comment Log for /doc/draft-pdutta-l2vpn-vpls-ldp-mac-opt/ |
2014-02-07
|
10 | Amy Vezza | Working group state set to Submitted to IESG for Publication |
2014-01-21
|
10 | Don Fedyk | New version available: draft-ietf-l2vpn-vpls-ldp-mac-opt-10.txt |
2013-11-27
|
09 | Don Fedyk | New version available: draft-ietf-l2vpn-vpls-ldp-mac-opt-09.txt |
2013-02-25
|
08 | Don Fedyk | New version available: draft-ietf-l2vpn-vpls-ldp-mac-opt-08.txt |
2012-09-09
|
07 | Pranjal Dutta | New version available: draft-ietf-l2vpn-vpls-ldp-mac-opt-07.txt |
2012-05-20
|
06 | Pranjal Dutta | New version available: draft-ietf-l2vpn-vpls-ldp-mac-opt-06.txt |
2012-04-11
|
(System) | Posted related IPR disclosure: Alcatel-Lucent's Statement about IPR related to draft-ietf-l2vpn-vpls-ldp-mac-opt-05 | |
2011-10-31
|
05 | (System) | New version available: draft-ietf-l2vpn-vpls-ldp-mac-opt-05.txt |
2011-06-24
|
04 | (System) | New version available: draft-ietf-l2vpn-vpls-ldp-mac-opt-04.txt |
2011-04-28
|
05 | (System) | Document has expired |
2010-10-25
|
03 | (System) | New version available: draft-ietf-l2vpn-vpls-ldp-mac-opt-03.txt |
2010-07-12
|
02 | (System) | New version available: draft-ietf-l2vpn-vpls-ldp-mac-opt-02.txt |
2010-03-08
|
01 | (System) | New version available: draft-ietf-l2vpn-vpls-ldp-mac-opt-01.txt |
2009-04-27
|
00 | (System) | New version available: draft-ietf-l2vpn-vpls-ldp-mac-opt-00.txt |