Requirements for Multicast Support in Virtual Private LAN Services
draft-ietf-l2vpn-vpls-mcast-reqts-07

[Ballot comment]
I have a number of comments, none of them is blocking, but I would suggest to consider them before the document is published.

1. Section 1.1:

> It is also necessary as customer routers are now likely to
  be running IP multicast protocols and those routers and connected to
  switches that will be handling large amounts of multicast traffic.

This phrase is incomplete, needs some edits to clarify syntax.

2. In section 1.2 and a couple of more places the word NOT is capitalized without being part of a capitalized key-word as per RFC 2119 - like in 'Also, this document does NOT aim to express ...'. I suggest to renounce this capitalization.

3. Section 5.1.1 refers to 'Ethernet control protocols employed by customers (e.g.  Spanning Tree Protocol [802.1D])' There is no such thing as 'Ethernet control protocols' and IEEE 802.1D does not apply to Ethernet only. I suggest to use a different terminology - for example 'layer 2 control plane protocols running on Local Area Networks (LAN) such as Ethernet (e.g.  Spanning Tree Protocol [802.1D])'

4. Sections 5.4 and 6.5.3 use the term 'standard SNMP MIB'. In the IETF management framework MIB modules are not necessarily used only with SNMP (SNMP being the protocol, and MIB modules being written in SMI). I suggest to use 'standard MIB modules' instead.

5. Section 6.5.3 includes:

> -  Multicast traffic statistics (total traffic forwarded, incoming,
      outgoing, dropped, etc., by period of time)

We usually discourage devices to make computation of statistic counters by period of time, retrieval by management aplications being a better solution for several reasons. I suggest to drop 'by period of time'

6. In section 6.5.4 I suggest to replace 'SNMP-trap' by 'SNMP Notification' which is the more recent and more general term used in SNMP.

7. I suggest to use the newer IEEE 802.1D-2004 revision of the standard as a reference rather than the 1998 revision

8. IEEE 802.1ag - CFM is not longer work on progress - it was approved as IEEE 802.1ag-2007. Please update the reference.

-------- Original Message --------
Subject: Moving draft-ietf-l2vpn-vpls-mcast-reqts-05.txt (Informational RFC) forward
Date: Fri, 25 Jul 2008 10:51:19 +0200
From: Mark Townsley
To: draft-ietf-l2vpn-vpls-mcast-reqts@tools.ietf.org, "l2vpn-chairs@tools.ietf.org" , Ron Bonica , Russ Housley , Tim Polk



This is part of a general review of documents on my plate in the IESG in
advance of the Dublin meeting.

I believe the authors have been working with the DISCUSS holders on some
of these issues. Yuji, could you provide an update on where we are in
your opinion?

Thanks,

- Mark


Discusses and Comments
Ron Bonica:
Discuss:
[2007-12-20] Maybe I missed it, but the document doesn't seem to address
MAC learning.

Comment:
[2007-12-20] You say "

"Furthermore, in some cases, IP service providers might expect
operational simplicity of VPLS.  That is, they avoid direct and
detailed knowledge of IP routing.  In this case, the multicast
delivery mechanism is expected to have not only efficiency but
also simplicity.  Generally speaking, there is a trade-off between
efficiency and simplicity in terms of bandwidth usage and state
maintenance, so the optimum trade-off will vary depending on the
requirements of each IP service provider."

The argument about "operational simplicity of VPLS" relative to layer 3
service is difficult to support, as instead of "direct and detailed
knowledge of IP routting", one has to deal with direct and detailed
knowledge of MAC addresses (including MAC address learning), and
layer 2.

Consider removing the entire paragraph


Also, you say:

"A solution SHOULD honor customer multicast domains."


Perhaps replace with "A solution SHOULD NOT alter customer multicast
domains' boundaries", as it is not clear what "honor .. multicast domains"
really means. Otherwise, clarify what "honor" means.

Also, you say:

"Multicast forwarding restoration time MUST NOT be greater than the
restoration time of a customer's Layer-3 multicast protocols.  For
example, if a customer uses PIM with default configuration, hello
hold timer is 105 seconds, and solutions are required to detect a
failure no later than this period."

The above mixes *restoration* time at layer 3 with *detection* time
at the VPLS infrastructure. Does not seems to be correct.


Also, you say:

Therefore, in addition to the L2VPN discovery requirements in
[RFC4665], a multicast VPLS solution SHOULD provide a method that
dynamically allows multicast membership information to be discovered
by PEs.  Such membership information is, for example, a set of
multicast addresses.  What information is provided dynamically is
solution specific."


This paragraph mixes several issues that should probably be unbundled.
First of all, unless a solution supports (A), as defined in 3.2,
there is little point in PEs' dynamically discovering multicast
membership info. So, "SHOULD" be conditioned on supporting (A).

Second in one scenario a PE discovers multicast membership info
from only the sites connected to that PE, while in another scenario
in addition to the previous scenario the PE discovers multicast
membership info from other PEs as well. The spec needs to spell
out what exactly it means by "dynamically allow multicast
membership information to be discovered by PEs".

Russ Housley:
Discuss:
[2007-12-20]
The Gen-ART Review by Christian Vogt has received no response.
It can be found at:

  http://www.alvestrand.no/ietf/gen/reviews/
  draft-ietf-l2vpn-vpls-mcast-reqts-05-vogt.txt

I am especially interested in a response to Christian's third comment.

Tim Polk:
Discuss:
[2008-03-11] [This is a revised discuss, integrating Sam Hartman's
issues and my own into a single
discuss to support AD transition.]

This discuss elaborates on issues raised in Steve Hanna's security
directorate review; that
review also needs to be examined in its entirety.

The following issue from the secdir review is blocking:
>Unfortunately, the document does not contain a systematic
>security analysis of the problem. The Security Considerations
>section consists of two brief paragraphs. These paragraphs refer
>to other sections in the document where security requirements
>are listed and to RFC 4665, which also lists security requirements.
>However, I could not find any methodical threat analysis listing
>the possible threats relevant to the system and stating which
>ones are protected against and which are not.

>Without a thorough threat analysis, I have little confidence
>that the authors have thought carefully about the possible
>threats to the system. I would expect this to lead to large
>gaps in the security requirements and this seems to be borne
>out in practice. For example, there is no discussion of
>threats due to compromise of components within the service
>provider network.

>Even more troublesome, I think that a single node at a customer
>site (presumably untrusted) can mount dangerous attacks.
>For example, a node that joins many multicast groups can
>cause a large amount of state to be maintained in the L2VPN.

Please provide a threat analysis and please work to address or
document the specific security concerns cited.

Section 6.6 provides a list of mechanisms a VPLS solution
SHOULD include.  There is no apparent relationship between the
requirements, and each is listed with a caveat regarding its application
(e.g., "if examined").  The net effect is that list appears to be nearly
empty under some circumstances: if multicast IP addresses are not
used for forwarding, and neither Ethernet multicast control frames
or IP multicast control packets are examined, only the first and last
bullets would apply.

First, are there implicit relationships that should be highlighted to
clarify the
overall effect? For example, if a VPLS solution always examines either
Ethernet
multicast control frames or IP multicast control packets, the net effect
is very
different.  If such relationships exist they should be specifed.

The SHOULD list is followed by several paragraphs with MAY
requirements.  Again, the
net effect is that a VPLS solution might provide none of these
mechanisms.  The security
considerations section needs to elaborate on the consequences of a VPLS
solution
that omits these security mechanisms.

-------- Original Message --------
Subject: Moving draft-ietf-pwe3-tdm-mib-10.txt (Proposed Standard) forward
Date: Fri, 25 Jul 2008 11:48:24 +0200
From: Mark Townsley
To: draft-ietf-pwe3-tdm-mib@tools.ietf.org, "pwe3-chairs@tools.ietf.org" , Dan Romascanu , Ron Bonica , Pasi Eronen , Tim Polk




This is part of a general review of documents on my plate in the IESG in
advance of the Dublin meeting.  I am giving advice here on how to move
forward based on the current read of the tracker. See DISCUSS and
COMMENT actions cc'd from the tracker below.

Authors, it seems pretty clear to me that the security considerations
section needs a rewrite, for style as well as specific errors below.

I'm moving the document to Revised ID needed as I believe that it will
need a new version in order to be approved. Lead editors, please work
individually with discuss holders to better understand their positions,
so that the next version can be approved.



Ron Bonica:
Comment:
[2008-07-02] support Dan's discuss

Pasi Eronen:
Comment:
[2008-07-01] Editorial suggestions from Scott Kelly's SecDir review:
- I would suggest adding a sentence to the introduction which
articulates the background the reader is assumed to have, for
example, what RFCs they are expected to be conversant with,
in order to understand the content of this document.
- TDM should be expanded with first use

Tim Polk:
Comment:
[2008-07-01] As noted in Scott Kelly's secdir review and Dan's
preliminary discuss, the replacement of
parentheses with double quotes is somewhat confusing.  Since Dan is
already holding a discuss,
I am balloting NoObj but would like to note that I support Dan's position.

Dan Romascanu:
Discuss:
[2008-07-02] 1. The Security Considerations section is departing from
the text at http://www.ops.ietf.org/mib-security.html, by replacing in a
few places brackets by double quotes. These changes which are
non-conformant with RFC4181 are making the texts confusing, which was
also remarked in the Security Review. I suggest to stick to the
guidelines and to use the standard text.

2.
pwTDMCfgEntry  OBJECT-TYPE
  SYNTAX            PwTDMCfgEntry
  MAX-ACCESS        not-accessible
  STATUS            current
  DESCRIPTION
      "These parameters define the characteristics of a
        TDM PW. They are grouped here to ease NMS burden.
        Once an entry is created here it may be re-used
        by many PWs.
        Unless otherwise specified, all objects in this table
        MUST NOT be changed after row activation (see [PWMIB])
        if the row index is in use by an entry in pwTDMTable.
        Rows must persist after reboot."


The last sentence contradicts the fact that this table has a StorageType
object.

[Ballot discuss]
[This is a revised discuss, integrating Sam Hartman's issues and my own into a single
discuss to support AD transition.]

This discuss elaborates on issues raised in Steve Hanna's security directorate review; that
review also needs to be examined in its entirety.

The following issue from the secdir review is blocking:
>Unfortunately, the document does not contain a systematic
>security analysis of the problem. The Security Considerations
>section consists of two brief paragraphs. These paragraphs refer
>to other sections in the document where security requirements
>are listed and to RFC 4665, which also lists security requirements.
>However, I could not find any methodical threat analysis listing
>the possible threats relevant to the system and stating which
>ones are protected against and which are not.

>Without a thorough threat analysis, I have little confidence
>that the authors have thought carefully about the possible
>threats to the system. I would expect this to lead to large
>gaps in the security requirements and this seems to be borne
>out in practice. For example, there is no discussion of
>threats due to compromise of components within the service
>provider network.

>Even more troublesome, I think that a single node at a customer
>site (presumably untrusted) can mount dangerous attacks.
>For example, a node that joins many multicast groups can
>cause a large amount of state to be maintained in the L2VPN.

Please provide a threat analysis and please work to address or
document the specific security concerns cited.

Section 6.6 provides a list of mechanisms a VPLS solution
SHOULD include.  There is no apparent relationship between the
requirements, and each is listed with a caveat regarding its application
(e.g., "if examined").  The net effect is that list appears to be nearly
empty under some circumstances: if multicast IP addresses are not
used for forwarding, and neither Ethernet multicast control frames
or IP multicast control packets are examined, only the first and last
bullets would apply.

First, are there implicit relationships that should be highlighted to clarify the
overall effect? For example, if a VPLS solution always examines either Ethernet
multicast control frames or IP multicast control packets, the net effect is very
different.  If such relationships exist they should be specifed.

The SHOULD list is followed by several paragraphs with MAY requirements.  Again, the
net effect is that a VPLS solution might provide none of these mechanisms.  The security
considerations section needs to elaborate on the consequences of a VPLS solution
that omits these security mechanisms.

[Ballot discuss]
[This is a revised discuss, integrating Sam Hartman's issues and my own into a single
discuss to support AD transition.]

This discuss elaborates on issues raised in Steve Hanna's security directorate review; that
review also needs to be examined in its entirety.

The following issue from the secdir review is blocking:
>Unfortunately, the document does not contain a systematic
>security analysis of the problem. The Security Considerations
>section consists of two brief paragraphs. These paragraphs refer
>to other sections in the document where security requirements
>are listed and to RFC 4665, which also lists security requirements.
>However, I could not find any methodical threat analysis listing
>the possible threats relevant to the system and stating which
>ones are protected against and which are not.

>Without a thorough threat analysis, I have little confidence
>that the authors have thought carefully about the possible
>threats to the system. I would expect this to lead to large
>gaps in the security requirements and this seems to be borne
>out in practice. For example, there is no discussion of
>threats due to compromise of components within the service
>provider network.

>Even more troublesome, I think that a single node at a customer
>site (presumably untrusted) can mount dangerous attacks.
>For example, a node that joins many multicast groups can
>cause a large amount of state to be maintained in the L2VPN.

Please provide a threat analysis and please work to address or
document the specific security concerns cited.

Section 6.6 provides a list of mechanisms a VPLS solution
SHOULD include.  There is no apparent relationship between the
requirements, and each is listed with a caveat regarding its application
(e.g., "if examined").  The net effect is that list appears to be nearly
empty under some circumstances: if multicast IP addresses are not
used for forwarding, and neither Ethernet multicast control frames
or IP multicast control packets are examined, only the first and last
bullets would apply.

First, are there implicit relationships that should be highlighted to clarify the overall effect? For
example, if a VPLS solution always examines either Ethernet multicast control frames or IP
multicast control packets, the net effect is very different.  If such relationships exist they
should be specifed.

The SHOULD list is followed by several paragraphs with MAY requirements.  Again, the net effect is that a VPLS solution might provide none of these mechanisms.  The security considerations section needs to elaborate on the consequences of a VPLS solution that omits
these security mechanisms.

[Ballot comment]
You say "

"Furthermore, in some cases, IP service providers might expect
operational simplicity of VPLS.  That is, they avoid direct and
detailed knowledge of IP routing.  In this case, the multicast
delivery mechanism is expected to have not only efficiency but
also simplicity.  Generally speaking, there is a trade-off between
efficiency and simplicity in terms of bandwidth usage and state
maintenance, so the optimum trade-off will vary depending on the
requirements of each IP service provider."

The argument about "operational simplicity of VPLS" relative to layer 3
service is difficult to support, as instead of "direct and detailed
knowledge of IP routting", one has to deal with direct and detailed
knowledge of MAC addresses (including MAC address learning), and
layer 2.

Consider removing the entire paragraph


Also, you say:

  "A solution SHOULD honor customer multicast domains."


Perhaps replace with "A solution SHOULD NOT alter customer multicast domains' boundaries", as it is not clear what "honor .. multicast domains"
really means. Otherwise, clarify what "honor" means.

Also, you say:

"Multicast forwarding restoration time MUST NOT be greater than the
restoration time of a customer's Layer-3 multicast protocols.  For
example, if a customer uses PIM with default configuration, hello
hold timer is 105 seconds, and solutions are required to detect a
failure no later than this period."

The above mixes *restoration* time at layer 3 with *detection* time
at the VPLS infrastructure. Does not seems to be correct.


Also, you say:

Therefore, in addition to the L2VPN discovery requirements in
[RFC4665], a multicast VPLS solution SHOULD provide a method that
dynamically allows multicast membership information to be discovered
by PEs.  Such membership information is, for example, a set of
multicast addresses.  What information is provided dynamically is
solution specific."


This paragraph mixes several issues that should probably be unbundled.
First of all, unless a solution supports (A), as defined in 3.2,
there is little point in PEs' dynamically discovering multicast
membership info. So, "SHOULD" be conditioned on supporting (A).

Second in one scenario a PE discovers multicast membership info
from only the sites connected to that PE, while in another scenario
in addition to the previous scenario the PE discovers multicast
membership info from other PEs as well. The spec needs to spell
out what exactly it means by "dynamically allow multicast
membership information to be discovered by PEs".

[Ballot discuss]
This discuss elaborates on issues raised in Steve Hanna's security directorate review; that
review also needs to be examined in its entirety.

Section 6.6 provides a list of mechanisms a VPLS solution SHOULD include.  There is no apparent
relationship between the requirements, and each is listed with a caveat regarding its application
(e.g., "if examined").  The net effect is that list appears to be nearly empty under some
circumstances: if multicast IP addresses are not used for forwarding, and neither Ethernet
multicast control frames or IP multicast control packets are examined, only the first and last bullets would apply.

First, are there implicit relationships that should be highlighted to clarify the overall effect?  For
example, if a VPLS solution always examines either Ethernet multicast control frames or IP
multicast control packets, the net effect is very different.  If such relationships exist they
should be specifed.

The SHOULD list is followed by several paragraphs with MAY requirements.  Again, the net effect is that a VPLS solution might provide none of these mechanisms.  The security considerations section needs to elaborate on the consequences of a VPLS solution that omits
these security mechanisms.

[Ballot discuss]
This discuss elaborates on issues raised in Steve Hanna's security directorate review; that
review also needs to be examined in its entirety.

Section 6.6 provides a list of mechanisms a VPLS solution SHOULD include.  There is no apparent
relationship between the requirements, and each is listed with a caveat regarding its application
(e.g., "if examined").  The net effect is that list appears to be nearly empty under some
circumstances: if multicast IP addresses are not used for forwarding, and neither Ethernet
multicast control frames or IP multicast control packets are examined, only the first and last bullets would apply.

First, are there implicit relationships that should be highlighted to clarify the overall effect?  For
example, if a VPLS solution always examines either Ethernet multicast control frames or IP
multicast control packets, the net effect is very different.  If such relationships exist they
should be specifed.

The SHOULD list is followed by several paragraphs with MAY requirements.  The consequences
of these

[Ballot discuss]
The Gen-ART Review by Christian Vogt has received no response.
  It can be found at:

    http://www.alvestrand.no/ietf/gen/reviews/
    draft-ietf-l2vpn-vpls-mcast-reqts-05-vogt.txt

  I am especially interested in a response to Christian's third comment.

[Ballot discuss]
The security directorate review from Stephen Hanna has received no response.
Please respond.
I consider the following blocking:
>Unfortunately, the document does not contain a systematic
>security analysis of the problem. The Security Considerations
>section consists of two brief paragraphs. These paragraphs refer
>to other sections in the document where security requirements
>are listed and to RFC 4665, which also lists security requirements.
>However, I could not find any methodical threat analysis listing
>the possible threats relevant to the system and stating which
>ones are protected against and which are not.

>Without a thorough threat analysis, I have little confidence
>that the authors have thought carefully about the possible
>threats to the system. I would expect this to lead to large
>gaps in the security requirements and this seems to be borne
>out in practice. For example, there is no discussion of
>threats due to compromise of components within the service
>provider network.

>Even more troublesome, I think that a single node at a customer
>site (presumably untrusted) can mount dangerous attacks.
>For example, a node that joins many multicast groups can
>cause a large amount of state to be maintained in the L2VPN.



Please provide a threat analysis and please work to address or
document the specific security concerns cited.

PROTO Write-up

(1.a) Who is the Document Shepherd for this document? Has the
Document Shepherd personally reviewed this version of the
document and, in particular, does he or she believe this
version is ready for forwarding to the IESG for publication?

Shane Amante (shane@castlepoint.net) is the Document Shepherd. I have reviewed the document and it is ready for publication.


(1.b) Has the document had adequate review both from key WG members
and from key non-WG members? Does the Document Shepherd have
any concerns about the depth or breadth of the reviews that
have been performed?

The document has been reviewed by the WG, during the WG Last Call, and through IETF L2VPN WG meetings. There were some comments received during WG Last Call with respect to allowing: proxying certain multicast control protocols, circumstances under which frame reordering cannot be prevented (when switching over from one tree to another) and allowing multicast service activation at a customer IP address level (in addition to a MAC address level). All of these comments have been addressed satisfactorily by the authors in the current, published version of this document.

I have no concerns about the state of readiness of this document.


(1.c) Does the Document Shepherd have concerns that the document
needs more review from a particular or broader perspective,
e.g., security, operational complexity, someone familiar with
AAA, internationalization, or XML?

Several Service Providers and Vendors have contributed to and reviewed the requirements contained in this document. I have no concerns about this document, and believe it does not require further reviews from a broader perspective.


(1.d) Does the Document Shepherd have any specific concerns or
issues 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. Has an IPR disclosure related to this document
been filed? If so, please include a reference to the
disclosure and summarize the WG discussion and conclusion on
this issue.

I have no specific concerns about this document, nor are there any concerns that should be conveyed to the IESG or the Responsible AD.


(1.e) 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?

This document is well understood and has broad support by the L2VPN WG. This document is widely recognized by the WG as a valuable contribution intended to shape L2VPN WG mutlicast solutions.


(1.f) 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
entered into the ID Tracker.)

No one has indicated to the WG Chairs or to the WG Mailing List any intention to appeal the publication of this document.


(1.g) Has the Document Shepherd personally verified that the
document satisfies all ID nits? (See
http://www.ietf.org/ID-Checklist.html and
http://tools.ietf.org/tools/idnits/.) Boilerplate checks are
not enough; this check needs to be thorough. Has the document
met all formal review criteria it needs to, such as the MIB
Doctor, media type, and URI type reviews? If the document
does not already indicate its intended status at the top of
the first page, please indicate the intended status here.

Yes. There are two outdated references and one obsolete reference in the current version (-04) of the document. The authors will correct these references during the Author Review period, given by the RFC-Editor.


(1.h) Has the document split its references into normative and
informative?

Yes.

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
strategy for their completion? Are there normative references
that are downward references, as described in [RFC3967]? If
so, list these downward references to support the Area
Director in the Last Call procedure for them [RFC3967].

No.


(1.i) Has the Document Shepherd verified that the document's IANA
Considerations section exists and is consistent with the body
of the document?

Yes. There are no IANA Considerations for this document, which is reasonable given its intended purpose.


If the document specifies protocol
extensions, are reservations requested in appropriate IANA
registries? Are the IANA registries clearly identified? If
the document creates a new registry, does it define the
proposed initial contents of the registry and an allocation
procedure for future registrations? Does it suggest a
reasonable name for the new registry? See [RFC2434]. If the
document describes an Expert Review process, has the Document
Shepherd conferred with the Responsible Area Director so that
the IESG can appoint the needed Expert during IESG Evaluation?

(1.j) Has the Document Shepherd verified that sections of the
document that are written in a formal language, such as XML
code, BNF rules, MIB definitions, etc., validate correctly in
an automated checker?

Yes.


(1.k) 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 provides functional requirements for network solutions
that support multicast over Virtual Private LAN Service (VPLS). It
specifies requirements both from the end user and service provider
standpoints. It is intended that potential solutions will use these
requirements as guidelines.


Working Group Summary
This document has been reviewed by carriers and experts in the L2VPN WG and there are no outstanding issues.


Document Quality
This memo is straightforward and well written. No issues are anticipated.


Personnel
Who is the Document Shepherd for this document?
Shane Amante (shane@castlepoint.net)

Who is the Responsible Area Director?
Mark Townsley (townsley@cisco.com)