Skip to main content

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