802.1ad/D3 Ballot EMAIL BALLOT
9th November 2004
TO: Mick Seaman
Editor, P802.1ad
SUBJECT: <See above>
__XX___ I Approve (may attach non-binding comments below)
_____ I Disapprove (must attach binding comments below)
_____ I Abstain for the following reasons (may attach non-binding comments
below):
______ Lack of Time
______ Lack of Expertise
______ Other: _______________________________________________
_____________Tony Jeffree_______________________________
(Name)
_____________+44-161-973-4278_______________________________
(Telephone No.)
NAME: Tony Jeffree
COMMENT TYPE: N/A
CLAUSE: General
PAGE:
LINE:
COMMENT START:
While still in need of some work in places, I believe this document is
ready for WG balloting.
COMMENT END:
SUGGESTED CHANGES START:
Move to WG ballot after resolution of this round of TG balloting.
SUGGESTED CHANGES END:
NAME: Tony Jeffree
COMMENT TYPE: ER
CLAUSE: 1, 3, 5, 6, 8, 9, 13, G
PAGE:
LINE:
COMMENT START:
Many of the changes defined in these clauses are now incorporated into the
Q Revision draft.
COMMENT END:
SUGGESTED CHANGES START:
Amend these clauses such that the AD draft just contains those changes that
are additional to the ones incorporated into Q REV. TJ will work with the
Editor to provide the necessary text.
SUGGESTED CHANGES END:
802.1ad/D3 Ballot EMAIL BALLOT
9th November 2004
TO: Mick Seaman
Editor, P802.1ad
SUBJECT: [802.1] P802.1ad/D3 Ballot - Disapprove
_____ I Approve (may attach non-binding comments below)
__X__ I Disapprove (must attach binding comments below)
_____ I Abstain for the following reasons (may attach non-binding
comments
below):
______ Lack of Time
______ Lack of Expertise
______ Other: _______________________________________________
__Arjan de Heer____________
(Name)
___+31 356875721_____
(Telephone No.) Add sentence in the appropriate clause that by default the
bridge uses the 8P0D configuration as defined in tables 6-5 and 6-5.
-----------------------------------------------------------------------NAME: Arjan de Heer
COMMENT TYPE:T
CLAUSE: 3
PAGE: 8
LINE:
COMMENT START:
Allign definitions of Provider Network port, Customer Network port, Provider
Edge port, Customer Edge port.
Differentiating properties for these ports are: S-VLAN or C-VLAN component
port, serving multiple or a single customer service instance, connected to
provider or customer ports/equipment. Defintion for Customer Network port
looks good, rest of defintions should be alligned.
[Customer Network port: An S-VLAN component Port in a Provider Bridge that
receives and transmits frames for a single customer]
COMMENT END:
SUGGESTED CHANGES START:
Provider Network port: An S-VLAN component Port in a Provider Bridge that
receives and transmits frames for a single customer.
Provider Edge port: A C-VLAN component Port in a Provider Edge Bridge that
receives and transmits frames for single customer and is connected to a
Customer Network Port.
Customer Edge port: A C-VLAN component Port in a Provider Edge Bridge that
receives and transmits frames for a single customer and is connected to
customer owned equipment.
SUGGESTED CHANGES END:
NAME: Arjan de Heer
COMMENT TYPE:T
CLAUSE: 3, 5.7-10
PAGE:
LINE:
COMMENT START:
There are no definitions provided for a VLAN aware component. Currently only
a list of requirements are given for the VLAN aware component, while for C/S
VLAN a definition/description is given (first sentence 5.9/5.10) that refers
to VLAN aware component.
If my understanding is correct, a VLAN aware component is the part of the
baggy pants model between the ISS interfaces, i.e. all MAC method independent
functionality.
COMMENT END:
SUGGESTED CHANGES START:
Add defintions to clause 3:
VLAN aware component: MAC method independent functionality of a VLAN aware
bridge
C-VLAN aware component: VLAN aware component with the EISS supported by the
use of a C-Tag
S-VLAN aware component: VLAN aware component with the EISS supported by the
use of an S-Tag
And/Or add the defintions to clause 5.7
5.7 add: A VLAN aware component comprises all the MAC method independent
functionality of a VLAN aware bridge.
SUGGESTED CHANGES END:
NAME: Arjan de Heer
COMMENT TYPE: E
CLAUSE: 5.7-5.10
PAGE:
LINE:
COMMENT START:
For the VLAN aware component there are two sections 5.7 and 5.8 to describe
the mandatory requirements and the options. For the C/S VLAN aware component
the options are a sub section of the mandatory requirements sections.
COMMENT END:
SUGGESTED CHANGES START:
Make consistent [I have no preference on either different sections for
mandatory and options, or options a sub-section of mandatory requirements]
SUGGESTED CHANGES END:
NAME: Arjan de Heer
COMMENT TYPE:T
CLAUSE: 5.6
PAGE:
LINE:
COMMENT START:
Description talks about provider edge components. A provider edge component
is undefined, it is a (restricted) C-VLAN component.
COMMENT END:
SUGGESTED CHANGES START:
A provider Edge Bridge is a conformant provider Bridge with the capability to
include one or more C-VLAN components. Each C-VLAN component has a single
Provider Edge Port and a distinct Customer Edge Port. The Provider Edge Port
may only be connected to a Provider Network Port on an S-VLAN component. The
Customer Edge Port may be connected to customer owned ports.
[Alternatively provider edge component could be introduced in the text as a
special configuration of a C-VLAN component. ]
SUGGESTED CHANGES END:
NAME: Arjan de Heer
COMMENT TYPE: E
CLAUSE: 6
PAGE:
LINE:
COMMENT START:
Figure 6.1 shows the different parts of a bridge, it does not contain the
corresponding section numbers as in e.g. fig15-1.
COMMENT END:
SUGGESTED CHANGES START:
Add section numbers to fig6.1
SUGGESTED CHANGES END:
NAME: Arjan de Heer
COMMENT TYPE: T
CLAUSE: 6.8
PAGE:
LINE:
COMMENT START:
As I already read Steve Haddocks comment, I'll not repeat his comment here,
but I agree largely, however it is not clear from the current draft how to
get the functionality where the provider assigns an S-priority based on Cpriority. As I understand it, this is based on section 6.9, where the
'virtual MAC' is described. The provider edge port issues an
M_UNITDATA.request(sa,ma,sdu,p,fcs) resulting in a
M_UNITDATA.indication(sa,ma,sdu,p,fcs) at the customer network port. This ISS
instance does convey all information transparently including the priority
parameter. The Priority regeneration table (6-6) can than be used for the
mapping of the received priority into the S-priority.
COMMENT END:
SUGGESTED CHANGES START:
Add some text to describe how the customer can signal priority via C-tags, as
described above. (I am willing to provide some text, if the comment is
accepted...)
SUGGESTED CHANGES END:
NAME: Arjan de Heer
COMMENT TYPE: TR
CLAUSE: 6.7.3
PAGE: 25
LINE:
COMMENT START:
When discussing the DP encoding it was brought up that there are bridges out
that can support Drop Precedence encoding, but not completely the proposed
encoding. For these bridges to be able to support the DP encoding, for 5P3D
the meaning of PCP 0 and 1 should be reversed to: O->0DE, 1->0, consistent
with the other encodings where the lower numerical value identifies Drop
Eligibility set.
Given that there were no other people that could support a specific encoding
only and given that we already changed the priority order of the numerical
values, it is proposed to reverse the meaning of PCP 0 and 1.
The argument was made, not to do this, that as a consequence of this change
nodes that currently generate framew with PCP 0 (default), would generate
marked frames by default. There are two options: Either these frames are
generated by a bridge itself, or by an end-station.
In the latter case these nodes are sending in 8P0D encoding. In other words
at the edge of the 5P3D domain a translation has to be performed by
provisioning of tables 6-4 and 6-5.
In the former case these frames are generated by bridge software that can be
upgraded to send using PCP 1 instead of 0, whereas the interpretation of
these values in the bridges is performed in ASICs.
COMMENT END:
SUGGESTED CHANGES START:
In Table 6.4 change row 5P3D, last 4 colums 0->1, 1->0.
In Table 6.5 interchange row 5P3D, last 2 colums
SUGGESTED CHANGES END:
NAME: Arjan de Heer
COMMENT TYPE: T
CLAUSE: 6.7.3
PAGE: 25
LINE:
COMMENT START:
For the tables 6-4 and 6-5 it is not said that the default configuration is
the one defined for 8P0D. I don't know whether it should be mentioned here or
in another clause, but at least somewhere.
COMMENT END:
SUGGESTED CHANGES START:
Add sentence in the appropriate clause that by default the bridge uses the
8P0D configuration as defined in tables 6-5 and 6-5.
SUGGESTED CHANGES END:
P802.1ad/D3 Ballot EMAIL BALLOT
9th November 2004
TO: Mick Seaman
Editor, P802.1ad
SUBJECT: <See above>
_____ I Approve (may attach non-binding comments below)
__X__ I Disapprove (must attach binding comments below)
_____ I Abstain for the following reasons (may attach non-binding
comments below):
______ Lack of Time
______ Lack of Expertise
______ Other: _______________________________________________
_Paul Congdon________________
(Name)
_(916) 785-5753______________
(Telephone No.)
-----------------------------------------------------------------------INCLUDE COMMENTS BELOW THIS POINT
These comments are being submitted with the help of Anoop Ghanwani
NAME: Paul Congdon
COMMENT TYPE: E
CLAUSE: 3
PAGE: 5
LINE:
COMMENT START:
There are lots of definitions
Customer and Provider, but no
are or what is the difference
Provider themselves. Provide
and provider.
COMMENT END:
SUGGESTED CHANGES START:
Add definitions for the above
SUGGESTED CHANGES END:
that are prefixed with
definition of what these
between a Customer and
definitions for customer
terms.
NAME: Paul Congdon
COMMENT TYPE: T
CLAUSE: 6.6.1
PAGE: 23
LINE: 6
COMMENT START:
Provide clarification for what is meant by "comparable
parameters".
COMMENT END:
SUGGESTED CHANGES START:
I think "comparable parameters" refers only to traffic
class, and this is not something that appears in the
EM_UNITDATA primitives.
SUGGESTED CHANGES END:
NAME: Paul Congdon
COMMENT TYPE: E
CLAUSE: many (5.9, 8.3, 8.6.1, 11.2.4)
PAGE:
LINE:
COMMENT START:
VLAN translation table and VID translation table are
being used interchangeably.
COMMENT END:
SUGGESTED CHANGES START:
Use one.
SUGGESTED CHANGES END:
P802.1ad/D3 Ballot EMAIL BALLOT
9th November 2004
TO: Mick Seaman
Editor, P802.1ad
SUBJECT: <See above>
_____ I Approve (may attach non-binding comments below)
___x_ I Disapprove (must attach binding comments below)
_____ I Abstain for the following reasons (may attach non-binding comments
below):
______ Lack of Time
______ Lack of Expertise
______ Other: _______________________________________________
_______Dan Romascanu________________________
(Name)
_______+972-3-6458414______________________
(Telephone No.)
-----------------------------------------------------------------------NAME: Dan Romascanu
COMMENT TYPE: TR (Technical, Required)
CLAUSE: general
PAGE:
LINE:
COMMENT START:
This specification will bring significant changes and additions to the existing model of management, and
to the SNMP MIB modules used for management of bridges. At least one new MIB module will be needed
for MSTP. As the Bridge MIB in the IETF will no longer undertake new work, it was decided that the IEEE
802.1 will take charge of such work. However, the current version includes only a number of limited scope
notes in Section 12, and no SNMP modules definition.
COMMENT END:
SUGGESTED CHANGES START:
Does not apply in the scope of a single comment. The editors should find the appropriate resources to
create the relevant sections, or add content to the existing ones.
SUGGESTED CHANGES END:
P802.1ad/D3 Ballot EMAIL BALLOT
9th November 2004
TO: Mick Seaman
Editor, P802.1ad
SUBJECT: <See above>
_____ I Approve (may attach non-binding comments below)
__X__ I Disapprove (must attach binding comments below)
_____ I Abstain for the following reasons (may attach non-binding comments
below):
______ Lack of Time
______ Lack of Expertise
______ Other: _______________________________________________
__Stephen_Haddock_____________
(Name)
___408-579-2812_______________
(Telephone No.)
-----------------------------------------------------------------------NAME: Stephen Haddock
COMMENT TYPE: T
CLAUSE: 16.3
PAGE: 96
LINE:
COMMENT START:
More needs to be said on how Provider Bridges handle customer frames with
reserved addresses, particularly at Customer Edge Ports where it seems to me
the natural thing would be for the C-VLAN aware component to filter these
frames just as a VLAN Bridge would. This implies a Customer Edge Port would
either block all customer BPDUs, or would participate in the customer
spanning tree. There are alternate proposals where the C-VLAN aware
component does not filter reserved addresses, but I believe there are
further constraints necessary to allow this. For example I think it only
works for customer BPDUs if the service instance selected by the PVID for
the Customer Edge Port has full connectivity to all service access points
reachable by any service instances that can be selected at that Customer
Edge Port. If this is the model we choose then we need to enumerate any
relevant constraints.
COMMENT END:
SUGGESTED CHANGES START:
Replace the sentence "Frames received by Provider Bridge Ports and addressed
to the Bridge Group Address are subject to service instance selection and
relay in the same way as customer data frames." with a new paragraph as
follows:
"When frames received at a Customer Network Port contain a destination
address that is reserved for C-VLAN aware Bridges (table 8-1) but not S-VLAN
aware bridges (table 8-2), these frames are subject to service instance
selection and relay in the same way as customer data frames. When these
frames are received at a Customer Edge Port they are filtered by the C-VLAN
aware component of the Provider Edge Bridge. The C-VLAN aware component may
participate in protocols utilizing these addresses, and may generate frames
containing these addresses that are forwarded on an internal connection from
a Provider Edge Port to a Customer Network Port, and are then subject to
service instance selection and relay by the S-VLAN aware component."
SUGGESTED CHANGES END:
NAME: Stephen Haddock
COMMENT TYPE: E
CLAUSE: 16.1
PAGE: 93
LINE:
COMMENT START:
I'm confused by bullet b. Section 15.7 describes service selection and
identification for customer frames on ingress to the provider network. When
bullet b says "service instance identification for each customer frame on
egress that mean egress through a Provider Network Port or a Customer
Network Port?
COMMENT END:
SUGGESTED CHANGES START:
Change bullet b to "Service instance selection and identification for each
customer frame on ingress to the provider network (15.7)."
SUGGESTED CHANGES END:
NAME: Stephen Haddock
COMMENT TYPE: T
CLAUSE: 6.7.3
PAGE: 26
LINE:
COMMENT START:
The Use_DE bit parameter is not completely defined.
COMMENT END:
SUGGESTED CHANGES START:
In the last paragraph of the section, change "shall be manageable for each
Port" to "shall be manageable for each Port by means of a Use_DE parameter."
Add a sentence to the end of the paragraph: "If the Use_DE parameter is not
set, the DE bit shall be transmitted as zero and ignored on recieve."
SUGGESTED CHANGES END:
NAME: Stephen Haddock
COMMENT TYPE: E
CLAUSE: 6.7.1
PAGE: 23
LINE: first line of 6.7.1
COMMENT START:
Be more specific on the primitive being received from the ISS.
COMMENT END:
SUGGESTED CHANGES START:
Change "On receipt of a data indication from" to "On receipt of a
M_UNITDATA.indication primitive from"
SUGGESTED CHANGES END:
NAME: Stephen Haddock
COMMENT TYPE: E
CLAUSE: 6.7.2
PAGE: 24
LINE: first line of 6.7.2
COMMENT START:
Be more specific on the primitive being invoked.
COMMENT END:
SUGGESTED CHANGES START:
Change "On invocation of a data request primitive" to "On invocation of a
EM_UNITDATA.request primitive "
SUGGESTED CHANGES END:
NAME: Stephen Haddock
COMMENT TYPE: T
CLAUSE: 6.8
PAGE: 27
LINE:
COMMENT START:
This section creates a new option on a VLAN bridge (putting a priority-S-tag
on a frame) that I feel is unnecessary. It allows a customer to request a
priority of service for a frame when using a Port-based service interface to
a Provider Bridge (15.3). I feel the capability for a customer to request
priority is adequately covered by using a C-tagged service interface (15.4)
or a S-tagged service interface (15.5). Section 6.8 is confusing because we
end up with one leg of the baggy pants diagram that has two sets of
tagging/untagging functions. It's also unclear how such a port is to handle
received S-tagged frames (which you can argue it shouldn't if the Provider
Bridge it's connected to strips S-tags, but ...).
COMMENT END:
SUGGESTED CHANGES START:
Either
1) delete section 6.8,
or
2) add the diagram below showing how/where S-tagging functions occur in the
baggy pants diagram, and specify what happens to a received frame containing
an S-tag:
|
|
|
Relay
|
|
|
+-------------------------+-- EISS
|
|
|
C-tagging functions
|
|
(clause 6.7)
|
|
|
+-------------------------+-- ISS
|
|
|
Provider Bridge
|
|
priority shim
|
|
(clause 6.8)
|
|
|
+-------------------------+-- EISS
|
|
|
S-tagging functions
|
|
(clause 6.7)
|
|
|
+-------------------------+-- ISS
|
|
|
|
|
|
Media Access Method
Dependent Convergence
Functions
|
|
|
|
SUGGESTED CHANGES END:
NAME: Stephen Haddock
COMMENT TYPE: E
CLAUSE: 5.2
PAGE: 11
LINE: last line
COMMENT START:
Missing reference.
COMMENT END:
SUGGESTED CHANGES START:
Add "5.6" in "f) Provider Edge Bridge (5.6)"
SUGGESTED CHANGES END:
NAME: Stephen Haddock
COMMENT TYPE: E
CLAUSE: 5.4.1
PAGE: 12
LINE:
COMMENT START:
Circular reference.
COMMENT END:
SUGGESTED CHANGES START:
Modify to "A VLAN Bridge may implement any C-VLAN component option not
specifically prohibited by 5.9.1."
SUGGESTED CHANGES END:
NAME: Stephen Haddock
COMMENT TYPE: E
CLAUSE: 5.5
PAGE: 12
LINE:
COMMENT START:
The concept of a port being configured as both a Provider Network Port and a
Customer Network Port is confusing.
COMMENT END:
SUGGESTED CHANGES START:
Modify to "Each Port shall be capable of being configures as one of, and may
be capable of being configured as either of:"
SUGGESTED CHANGES END:
NAME: Stephen Haddock
COMMENT TYPE: T
CLAUSE: 5.6
PAGE: 13
LINE: first line
COMMENT START:
Can aggregate more than two MAC instances.
COMMENT END:
SUGGESTED CHANGES START:
Change "two instances of a MAC" to "two or more instances of a MAC".
SUGGESTED CHANGES END:
NAME: Stephen Haddock
COMMENT TYPE: E
CLAUSE: 5.6
PAGE: 13
LINE: last line of clause 5.6
COMMENT START:
Difficult to parse whether the Provider Edge Port is connected to the
Provider Edge Bridge or to a Customer Network Port.
COMMENT END:
SUGGESTED CHANGES START:
Modify to "Each Provider Edge Port on a Provider Edge component shall be
connected to a distinct Customer Network Port on the S-VLAN component, using
connections internal to the Provider Edge Bridge as specified in Clause
6.9."
SUGGESTED CHANGES END:
NAME: Stephen Haddock
COMMENT TYPE: E
CLAUSE: 6.9 and 15.4
PAGE: 28 and 89
LINE:
COMMENT START:
The concept being described in 6.9 would be more clear with an example.
COMMENT END:
SUGGESTED CHANGES START:
Add to the end of the first paragraph in 6.9: "An example of this is shown
in Figure 15-4."
In Figure 15-4, change the references in the two "pants legs" connected by
the internal LAN from "Clause 6.5" to "Clause 6.9".
SUGGESTED CHANGES END:
NAME: Stephen Haddock
COMMENT TYPE: E
CLAUSE: 5.7 and 5.8
PAGE: 13
LINE:
COMMENT START:
The conformance clauses would be easier to follow if they were "top-down".
The three types of bridges (VLAN, Provider, Provider Edge) refer to the two
bridge components (C-VLAN, S-VLAN) which in turn refer to the core component
(VLAN-aware).
COMMENT END:
SUGGESTED CHANGES START:
Move the VLAN-aware component requirements (5.7) and options (5.8) to after
the S-VLAN component conformance (5.10).
SUGGESTED CHANGES END:
NAME: Stephen Haddock
COMMENT TYPE: T
CLAUSE: 5.7 and 5.8
PAGE: 13
LINE:
COMMENT START:
802.1Q-2003 had requirement to conform to 802.1D (802.1Q-2003 clause 5.1-a)
and explicit option to conform to 802.1D options (802.1Q-2003 clause 5.2-k).
These were dropped from the lists in this draft. I believe they are still
necessary (for example, we still want to require a VLAN bridge to implement
Spanning Tree; now RSTP).
COMMENT END:
SUGGESTED CHANGES START:
Add these back into clauses 5.7 and 5.8 respectively, with the references
updated.
SUGGESTED CHANGES END:
NAME: Stephen Haddock
COMMENT TYPE: T
CLAUSE: 5.9 or 6.7.3 or 9.6
PAGE:
LINE:
COMMENT START:
I don't think we want to require VLAN bridges to be capable of encoding drop
precedence in the C-tag (since this would make previously conformant VLAN
bridges suddenly non-conformant). It should be required that VLAN bridges
be capable of carrying the priority parameter in the C-tag (which is
equivalent to implementing just the 8P0D rows of tables 6-4 and 6-5), and
optional that they are capable of carrying the drop precedence parameter
encoded with priority (implementing the remaining rows of tables 6-4 and
6-5). I'm not sure whether it is more appropriate to make this distinction
in the C-VLAN bridge component conformance clause (5.9), the encoding rules
(6.7.3), or the C-tag control information specification (9.6).
COMMENT END:
SUGGESTED CHANGES START:
In one of 5.9 or 6.7.3 or 9.6 specify that encoding drop precedence in a
C-tag is optional.
SUGGESTED CHANGES END:
NAME: Stephen Haddock
COMMENT TYPE: T
CLAUSE: 8.6.5
PAGE: 44
LINE:
COMMENT START:
If a VLAN translation table is used, S-VIDs must be translated on egress as
well as on ingress.
COMMENT END:
SUGGESTED CHANGES START:
Add the following sentence to 8.6.5:
"When a S-VLAN aware Bridge Port implements a VID Translation Table on
ingress as specified in 8.6.1, it shall provide for a reverse translation on
egress through that port."
SUGGESTED CHANGES END:
__X__ I Disapprove (must attach binding comments below)
Les Bell
+44-1442-438025
-----------------------------------------------------------------------INCLUDE COMMENTS BELOW THIS POINT
NAME: Les Bell
COMMENT TYPE: E
CLAUSE: 1.1
PAGE: 3
LINE:
COMMENT START:
Typo in bullet (x).
COMMENT END:
SUGGESTED CHANGES START:
Replace "connectivity provide to" with "connectivity provided to".
SUGGESTED CHANGES END:
NAME: Les Bell
COMMENT TYPE: E
CLAUSE: 5.6
PAGE: 13
LINE:
COMMENT START:
In the NOTE at the top of the page, an aggregation should not be limited to
two
independent instances of a MAC.
COMMENT END:
SUGGESTED CHANGES START:
Clarify that two, or more, independent instances of a MAC may be aggregated
as a
single Customer Edge Port.
SUGGESTED CHANGES END:
NAME: Les Bell
COMMENT TYPE: E
CLAUSE: 5.9
PAGE: 15
LINE:
COMMENT START:
Bullet (e) should provide a reference to the VLAN-translation table.
COMMENT END:
SUGGESTED CHANGES START:
Add the reference.
The best definition of the VLAN Table I could find is in the penultimate
paragraph of clause 8.6.1.
SUGGESTED CHANGES END:
NAME: Les Bell
COMMENT TYPE: E
CLAUSE: 5.10
PAGE: 16
LINE:
COMMENT START:
THe bullet numbering is non-standard.
COMMENT END:
SUGGESTED CHANGES START:
Renumber the bullets.
SUGGESTED CHANGES END:
NAME: Les Bell
COMMENT TYPE: E
CLAUSE: 6.4
PAGE: 18
LINE:
COMMENT START:
NOTE 1 does not require a number, as it is the only note in this clause.
COMMENT END:
SUGGESTED CHANGES START:
Remove the number of the note.
SUGGESTED CHANGES END:
NAME: Les Bell
COMMENT TYPE: E
CLAUSE: 6.5
PAGE: 21
LINE:
COMMENT START:
NOTE 3 does not require a number, as it is the only note in this clause.
COMMENT END:
SUGGESTED CHANGES START:
Remove the number of the note.
SUGGESTED CHANGES END:
NAME: Les Bell
COMMENT TYPE: E
CLAUSE: 6.7.1
PAGE: 24
LINE:
COMMENT START:
NOTE 2 does not require a number, as it is the only note in this clause.
COMMENT END:
SUGGESTED CHANGES START:
Remove the number of the note.
SUGGESTED CHANGES END:
NAME: Les Bell
COMMENT TYPE: E
CLAUSE: 6.10
PAGE: 28
LINE:
COMMENT START:
Typo, missing space.
COMMENT END:
SUGGESTED CHANGES START:
Replace "eachM_UNITDATA.request" with "each M_UNITDATA.request".
SUGGESTED CHANGES END:
NAME: Les Bell
COMMENT TYPE: E
CLAUSE: 8.2
PAGE: 34
LINE:
COMMENT START:
Figure 8-2 is annotated with the term "802.X" at the bottom of each port,
where
it connects to the LAN. It is not stated what this refers to.
COMMENT END:
SUGGESTED CHANGES START:
There should be a note clarifying what this refers to. I believe it is
intended
to refer to any of the IEEE 802 media types, e.g. 802.3, 802.5, 802.11, etc.
SUGGESTED CHANGES END:
NAME: Les Bell
COMMENT TYPE: E
CLAUSE: 8.3
PAGE: 35
LINE:
COMMENT START:
Typo.
COMMENT END:
SUGGESTED CHANGES START:
In the paragraph between bullet (c) and (d), replace "processes uses" with
"processes use".
SUGGESTED CHANGES END:
NAME: Les Bell
COMMENT TYPE: E
CLAUSE: 8.3
PAGE: 35, 37
LINE:
COMMENT START:
There are two NOTEs in this clause, so they should be numbered.
COMMENT END:
SUGGESTED CHANGES START:
Number them.
SUGGESTED CHANGES END:
NAME: Les Bell
COMMENT TYPE: T
CLAUSE: 8.6.1
PAGE: 41
LINE:
COMMENT START:
This clauses describes the discarding of untagged and priority-tagged frames
if
Acceptable Frame Types is set to 'Admit Only VLAN-Tagged frames', but it does
not describe the discarding of VLAN-Tagged frames when 'Admit Only Untagged
frames' is selected.
COMMENT END:
SUGGESTED CHANGES START:
Add a paragraph describing the discarding of VLAN-Tagged frames when 'Admit
Only
Untagged frames' is selected.
SUGGESTED CHANGES END:
NAME: Les Bell
COMMENT TYPE: E
CLAUSE: 8.6.1
PAGE: 41
LINE:
COMMENT START:
Missing word in the last paragraph on this page.
COMMENT END:
SUGGESTED CHANGES START:
Replace "The default value for is reset" with "The default value for this is
reset".
SUGGESTED CHANGES END:
NAME: Les Bell
COMMENT TYPE: E
CLAUSE: 8.7
PAGE: 46
LINE:
COMMENT START:
Incorrect reference at end of second paragraph on this page.
COMMENT END:
SUGGESTED CHANGES START:
Replace the second occurence of "(8.7.2)" on the penultimate line of the
paragraph with "(8.7.1)".
SUGGESTED CHANGES END:
NAME: Les Bell
COMMENT TYPE: E
CLAUSE: 8.9.3
PAGE: 54
LINE:
COMMENT START:
The table number is used by a previous table.
COMMENT END:
SUGGESTED CHANGES START:
Replace "Table 8-1" with "Table 8-4".
SUGGESTED CHANGES END:
NAME: Les Bell
COMMENT TYPE: E
CLAUSE: 8.9.8
PAGE: 60, 61
LINE:
COMMENT START:
The table numbers are used by previous tables.
COMMENT END:
SUGGESTED CHANGES START:
Replace "Table 8-1" with "Table 8-5".
Replace "Table 8-2" with "Table 8-6".
Replace "Table 8-3" with "Table 8-7".
SUGGESTED CHANGES END:
NAME: Les Bell
COMMENT TYPE: TR
CLAUSE: 8.13
PAGE: 64
LINE:
COMMENT START:
In keeping with previous versions of this standard, it should not mandate a
specific management protocol. Also, the specification is lacking detail in
this
clause.
COMMENT END:
SUGGESTED CHANGES START:
It may be better to say that the Bridge Management Entity should support the
management objects defined by:
- RFC 1493 (or its proposed update
http://www.ietf.org/internet-drafts/draft-ietf-bridge-bridgemib-smiv2-07.txt
)
- RFC 2674 (or its proposed update including 802.1v support, now expired, it
can
be found in the archive at
http://www.watersprings.org/pub/id/draft-ietf-bridge-ext-v2-02.txt )
- RSTP MIB http://www.ietf.org/internet-drafts/draft-ietf-bridge-rstpmib05.txt
- MSTP MIB (to be defined)
- Additional, new management parameters, as defined in clause 12, to manage
the
new features introduced by this document - this new MIB should also be
defined
by a new clause, or annex, in this document.
SUGGESTED CHANGES END:
NAME: Les Bell
COMMENT TYPE: TR
CLAUSE: 8.14.7
PAGE: 66
LINE:
COMMENT START:
This clause should refer to the Bridge Address defined in 8.14.8 as the MAC
destination address for management of the Bridge. It should not refer to an
IP
address, or SNMP.
COMMENT END:
SUGGESTED CHANGES START:
Refer to the Bridge Address as the address used to access the Bridge
Management
Entities.
References to an IP address and SNMP may be suggested in a NOTE, as an
example
of how to manage the Bridge via the Bridge Address.
SUGGESTED CHANGES END:
NAME: Les Bell
COMMENT TYPE: E
CLAUSE: 8.14.9
PAGE: 69
LINE:
COMMENT START:
The NOTE at the bottom of this page should be number 3.
COMMENT END:
SUGGESTED CHANGES START:
Replace "NOTE" with "NOTE 3".
SUGGESTED CHANGES END:
NAME: Les Bell
COMMENT TYPE: E
CLAUSE: 8.14.9
PAGE: 70
LINE:
COMMENT START:
The NOTE in the middle of this page should be number 4.
COMMENT END:
SUGGESTED CHANGES START:
Replace "NOTE" with "NOTE 4".
SUGGESTED CHANGES END:
NAME: Les Bell
COMMENT TYPE: E
CLAUSE: 8.14.10
PAGE: 71
LINE:
COMMENT START:
The NOTE, 2nd paragraph on this page, should not be numbered.
COMMENT END:
SUGGESTED CHANGES START:
Replace "NOTE 3" with "NOTE".
SUGGESTED CHANGES END:
NAME: Les Bell
COMMENT TYPE: T
CLAUSE: 9.6
PAGE: 75
LINE:
COMMENT START:
In Table 9-2, the VID value FFF (hex) has been reserved for implementation
use.
Previous discussions have also suggested using this value to indicate a
wildcard
match for any VID in management operations. If this value is to be used as a
wildcard, the Meaning/Use of this value must be updated to reflect this, in
this
table.
See also, the Editor's note in clause 8.9, page 49.
COMMENT END:
SUGGESTED CHANGES START:
Replace the Meaning/Use for the VID value FFF with the following paragraph:
Reserved for implementation use. This VID value shall not be configured as a
PVID or a member of a VID Set, or transmitted in a tag header. This VID
value
may be used to indicate a wildcard match for the VID in management operations
or
Filtering Database entries.
SUGGESTED CHANGES END:
NAME: Les Bell
COMMENT TYPE: TR
CLAUSE: 12
PAGE: 81
LINE:
COMMENT START:
This clause does not define any configuration for the Flow Meters (8.6.4).
COMMENT END:
SUGGESTED CHANGES START:
Add a sub-clause for configuration of the Flow Meters. This should include
per
port/service instance configuration of the meter criteria (DA, VID, PCP, DE,
mac_service_data_unit size), the triggering threshold, and the sampling rate.
SUGGESTED CHANGES END:
NAME: Les Bell
COMMENT TYPE: E
CLAUSE: 13.24.29
PAGE: 83
LINE:
COMMENT START:
Typo.
COMMENT END:
SUGGESTED CHANGES START:
In the second line of this paragraph, replace "even it has" with "even if it
has".
SUGGESTED CHANGES END:
NAME: Les Bell
COMMENT TYPE: TR
CLAUSE: 13.24.29
PAGE: 83
LINE:
COMMENT START:
The use of the restrictedRole parameter needs further clarification in the
case
where all potential Root Ports have restrictedRole set. In this case, the
Bridge will itself become the Root Bridge and there is the possibility of a
loop
being created, as updtRolesCist(), 13.26.25 (h), and updtRolesMsti(),
13.26.26
(h) currently would select all of these as Designated Ports.
COMMENT END:
SUGGESTED CHANGES START:
Clarify this scenario in this clause.
Modify 13.26.25 (h) and 13.26.26 (h) to ensure these ports are selected as
Alternate Ports, effectively isolating this Bridge from the network to
prevent
loops.
SUGGESTED CHANGES END:
NAME: Les Bell
COMMENT TYPE: E
CLAUSE: 15.7
PAGE: 91
LINE:
COMMENT START:
The NOTE on this page should be numbered, as there are further NOTEs in this
clause, on the next page.
COMMENT END:
SUGGESTED CHANGES START:
make this NOTE 1 and renumber the following NOTEs in this clause
appropriately.
SUGGESTED CHANGES END:
NAME: Les Bell
COMMENT TYPE: E
CLAUSE: 15.8
PAGE: 92
LINE:
COMMENT START:
Typo.
COMMENT END:
SUGGESTED CHANGES START:
In the first paragraph, fourth line, replace "a Port-based interfaces" with
"a
Port-based interface".
SUGGESTED CHANGES END:
NAME: Les Bell
COMMENT TYPE: E
CLAUSE: 16.5
PAGE: 96
LINE:
COMMENT START:
Typo.
COMMENT END:
SUGGESTED CHANGES START:
In NOTE 3, second line, replace "addressed this standard" with "addressed by
this standard".
SUGGESTED CHANGES END:
NAME: Les Bell
COMMENT TYPE: ER
CLAUSE: G.7
PAGE: 108
LINE:
COMMENT START:
The end of the first paragraph on this page introduces the Require Drop
Encoding
parameter. There is no explanation as to what this is, nor is it referenced
anywhere else in the document.
COMMENT END:
SUGGESTED CHANGES START:
Remove it.
SUGGESTED CHANGES END:
P802.1ad/D3 Ballot EMAIL BALLOT
9th November 2004
TO: Mick Seaman
Editor, P802.1ad
SUBJECT: <See above>
_____ I Approve (may attach non-binding comments below)
__X__ I Disapprove (must attach binding comments below)
_____ I Abstain for the following reasons (may attach non-binding comments
below):
______ Lack of Time
______ Lack of Expertise
______ Other: _______________________________________________
__Jim Burns_____________
(Name)
___603-778-2315_______________
(Telephone No.)
-----------------------------------------------------------------------NAME: Jim Burns
COMMENT TYPE: E
CLAUSE: 8.6.3 - Table 8-1
PAGE: 42
LINE:
COMMENT START:
I apologize, I suspect that I have missed something obvious and that my
novice-level of knowledge regarding vlan and provider bridging is agravating
the issue.
The 'IEEE Std. 802.1X PAE address (01-80-c2-00-00-00)' is specified as being
permanently configured in both the filtering database of C-VLAN aware bridges
as well as S-VLAN aware bridges. In addition, section 8.6 describes the
forwarding process as carrying out frame filtering on every reception port.
This makes sense in non-provider bridges as 802.1X is limited to a single
LAN.
There are exceptions to the filtering rules described for provider
bridges. For instance section 16.3 describes how customers may run MSTP and
RSTP tranparently: "Frames received by Provider Bridge Prots and addressed
to the Bridge Group Address are subject to service instance selection and
relay in the same way as customer data frames". I did not see a similar
exception for 802.1X.
In a provider bridge network when the C-VLAN aware portion of the
Provider Edge Bridge needs to carry out 802.1X with its counterpart (another
C-VLAN aware portion of another Provider Edge Bridge) through a network of
Provider Bridges, it will send a frame with a destination address of the
802.1X PAE group address. This frame shall need to traverse the network of
Provider Bridges. What prevents the Provider Bridge from filtering the
802.1X frames as described in this section (8.6.3)?
COMMENT END:
SUGGESTED CHANGES START:
Perhaps add a section for port access security in section 16 that describes
the exception for the 802.1X PAE address.
SUGGESTED CHANGES END:
P802.1ad/D3 Ballot EMAIL BALLOT
9th November 2004
TO: Mick Seaman
Editor, P802.1ad
SUBJECT: <See above>
_____ I Approve (may attach non-binding comments below)
__X__ I Disapprove (must attach binding comments below)
_____ I Abstain for the following reasons (may attach non-binding comments
below):
______ Lack of Time
______ Lack of Expertise
______ Other: _______________________________________________
__John_Messenger_____________
(Name)
___+44-1904-692700_______________
(Telephone No.)
-----------------------------------------------------------------------NAME: John Messenger
COMMENT TYPE: T
CLAUSE: 6.8
PAGE: 27
LINE:
COMMENT START:
If this lets a Customer Bridge put a provider S-Tag on a frame specifying
only a priority and not a S-VLAN-ID then I think it's a bad idea. The only
way to connect a Customer Bridge to a Provider Bridged LAN should be via an
intervening Provider Edge Bridge.
COMMENT END:
SUGGESTED CHANGES START:
Delete section 6.8.
SUGGESTED CHANGES END:
P802.1ad/D3 Ballot EMAIL BALLOT
9th November 2004
TO: Mick Seaman
Editor, P802.1ad
SUBJECT: <See above>
_____ I Approve (may attach non-binding comments below)
__X__ I Disapprove (must attach binding comments below)
_____ I Abstain for the following reasons (may attach non-binding comments
below):
______ Lack of Time
______ Lack of Expertise
______ Other: _______________________________________________
___Muneyoshi Suzuki_________________________
(Name)
___+81-422-59-2119__________________________
(Telephone No.)
-----------------------------------------------------------------------INCLUDE COMMENTS BELOW THIS POINT
NAME: Muneyoshi Suzuki
COMMENT TYPE: ER
CLAUSE: all
PAGE: all
LINE: all
COMMENT START:
"Service instance" is 74 times used in this draft. But, it seems to me,
"service instance" and "S-VLAN" are identical.
COMMENT END:
SUGGESTED CHANGES START:
If "service instance" does not mean "S-VLAN", it should be defined in
clause 3, because neither OSI definition nor 802 architecture standard
does not define it. Otherwise, terminology should be unified.
SUGGESTED CHANGES END:
NAME: Muneyoshi Suzuki
COMMENT TYPE: T
CLAUSE: 8.2
PAGE: 33-34
LINE:
COMMENT START:
Since new Bridge protocol architecture is introduced in Clause 6,
VLAN-aware Bridge architecture addressed in this clause should also
be consistent with Clause 6. However, relationships among MIF, MCF,
and MSF defined in clause 6 and Port and 802.1X described in Clause
8.2 are unclear.
COMMENT END:
SUGGESTED CHANGES START:
Clarification is needed especially relationships among MIF, MCF and
Port.
SUGGESTED CHANGES END:
NAME: Muneyoshi Suzuki
COMMENT TYPE: E
CLAUSE: 8.6.4
PAGE: 43
LINE: Table 8-1
COMMENT START:
01-80-C2-00-00-0E is taken by LLDP.
COMMENT END:
SUGGESTED CHANGES START:
Update table.
SUGGESTED CHANGES END:
NAME: Muneyoshi Suzuki
COMMENT TYPE: E
CLAUSE: 9.7
PAGE: 76
LINE: Figure 9-1
COMMENT START:
Figure title "C-TAG" is a typo.
COMMENT END:
SUGGESTED CHANGES START:
It is "S-TAG".
SUGGESTED CHANGES END:
NAME: Muneyoshi Suzuki
COMMENT TYPE: T
CLAUSE: 15.2
PAGE: 88
LINE: 17
COMMENT START:
"Customer instance" is undefined terminology.
COMMENT END:
SUGGESTED CHANGES START:
It should be defined in clause 3, because it is not defined in
OSI or 802 architecture standard. Otherwise, replace plain word
such as "customers" instead.
SUGGESTED CHANGES END:
NAME: Muneyoshi Suzuki
COMMENT TYPE: E
CLAUSE: 15.4
PAGE: 90
LINE: 1
COMMENT START:
"CVLAN" is a typo.
COMMENT END:
SUGGESTED CHANGES START:
It is "C-VLAN".
SUGGESTED CHANGES END:
NAME: Muneyoshi Suzuki
COMMENT TYPE: TR
CLAUSE: 15.4
PAGE: 90
LINE: 1-4
COMMENT START:
I'm not sure the reason why scheme addressed in this note is effective
for loopsprevention.
COMMENT END:
SUGGESTED CHANGES START:
Clarification is needed.
SUGGESTED CHANGES END:
NAME: Muneyoshi Suzuki
COMMENT TYPE: E
CLAUSE: 16.2
PAGE: 94
LINE: 9
COMMENT START:
")" in end of paragraph is a typo.
COMMENT END:
SUGGESTED CHANGES START:
Remove it.
SUGGESTED CHANGES END:
NAME: Muneyoshi Suzuki
COMMENT TYPE: ER
CLAUSE: 16.2
PAGE: 95
LINE: 26-34
COMMENT START:
"User VLAN" is 4 times used in this paragraph. It seems to me,
typos of "Customer VLAN".
COMMENT END:
SUGGESTED CHANGES START:
Replace "user" -> "customer". If user VALN is used different meaning of
C-VLAN, clarify meaning.
SUGGESTED CHANGES END:
P802.1ad/D3 Ballot EMAIL BALLOT
9th November 2004
TO: Mick Seaman
Editor, P802.1ad
SUBJECT: [802.1] P802.1ad/D3 Ballot - Disapprove
_____ I Approve (may attach non-binding comments below)
__X__ I Disapprove (must attach binding comments below)
_____ I Abstain for the following reasons (may attach non-binding
comments
below):
______ Lack of Time
______ Lack of Expertise
______ Other: _______________________________________________
__Glenn Parsons____________
(Name)
___613-763-7582_______________
(Telephone No.)
-----------------------------------------------------------------------NAME: Glenn Parsons
COMMENT TYPE: E
CLAUSE: all
PAGE: LINE: COMMENT START:
The use of change bars is inconsistent in this amendment. Some clauses
(e.g., 1.1 & 6.6) show the replacement text change barred from the
amended base standard. The final amendment should not include change
bars. However, it would be very helpful if the editor could provide
change barred text for sections that have changed from the base 802.1Q
standard (e.g., clauses 8 & 9)
COMMENT END:
SUGGESTED CHANGES START:
Remove all change bars, cross outs and underscore revision control
markers.
SUGGESTED CHANGES END:
NAME: Glenn Parsons
COMMENT TYPE: ER
CLAUSE: all
PAGE: LINE: COMMENT START:
Reference to other IEEE standards includes years and inconsistent
notation (e.g., 802.1Q-1998 or 802.1Q, 1998 Edition). The year is not
necessary in the body of the text. The year and title of the most
recent version of the standard at the publication of this amendment
should be included in the References clause 2.
COMMENT END:
SUGGESTED CHANGES START:
Remove all dates from references to IEEE 802.1Q, IEEE 802.1D, IEEE
802.3, and so forth
Show an updated clause 2 with at least:
IEEE 802.1D-2004
IEEE 802.1Q-2003
IEEE 802.3-2004
SUGGESTED CHANGES END:
NAME: Glenn Parsons
COMMENT TYPE: ER
CLAUSE: 2
PAGE: 4
LINE: 1
COMMENT START:
It would be appropriate to reference ITU-T SG15 work on Ethernet
architecture, services and interfaces since this is relevant to
provider bridges.
COMMENT END:
SUGGESTED CHANGES START:
Add the following references to the Bibliography clause:
ITU-T G.8010 (2003) - Architecture of Ethernet Layer Networks
ITU-T G.8011 (2004) - Ethernet over Transport - Ethernet services
framework
ITU-T G.8011.1 (2004) - Ethernet private line service
ITU-T G.8012 (2004) - Ethernet UNI and Ethernet over Transport NNI
ITU-T G.8021 (2004) - Characteristics of Ethernet transport network
equipment functional blocks
Note that if clause 15 is expanded towards supporting the definition of
a 'service', the inclusion of some of these in the References clause.
SUGGESTED CHANGES END:
NAME: Glenn Parsons
COMMENT TYPE: ER
CLAUSE: 5.2
PAGE: 11
LINE: 20
COMMENT START:
The list provided in this introduction seems to be a plausible
ordering, but the clauses for the enumerated list is not in the same
order.
COMMENT END:
SUGGESTED CHANGES START:
Reorder the subclauses in clause 5 to match the ordering presented in
5.2
Also add the subclause 5.6 to f)
SUGGESTED CHANGES END:
NAME: Glenn Parsons
COMMENT TYPE: ER
CLAUSE: 8
PAGE: 31
LINE: 1
COMMENT START:
No editor's note is present to indicate instructions on what to do with
clause 8 relative to the amended standard.
COMMENT END:
SUGGESTED CHANGES START:
Add instruction to the effect:
Delete the existing contents of Clause 8, and insert replacement
contents as shown
below.
SUGGESTED CHANGES END:
NAME: Glenn Parsons
COMMENT TYPE: E
CLAUSE: 8.1.1
PAGE: 31
LINE: 10
COMMENT START:
Reference clauses is inconsistent. All items in enumerated list should
have cross-references.
COMMENT END:
SUGGESTED CHANGES START:
Add references to all items in list
e.g., a) frame reception (8.5)
SUGGESTED CHANGES END:
NAME: Glenn Parsons
COMMENT TYPE: T
CLAUSE: 8.13
PAGE: 64
LINE:
COMMENT START:
This text is not an improvement on 802.1Q-2003. The SNMPv3 Bridge MIB
should be introduced here and given the collapse of IEEE MIB work in
the IETF should be included as an Annex to this document.
COMMENT END:
SUGGESTED CHANGES START:
Retain clause 8.13 from 802.1Q-2003. Add that an SNMPv3 Bridge MIB is
the preferred approach.
Further, add a new Annex that is the SNMPv3 Bridge MIB.
SUGGESTED CHANGES END:
NAME: Glenn Parsons
COMMENT TYPE: TR
CLAUSE: 12
PAGE: 81
LINE: 3
COMMENT START:
It is clear that amendments are needed to this clause, however, more
changes than those mentioned are required. At a minimum, given the
churn in subclauses, this needs revision. however, in addition,
provider bridge specific management should be considered.
COMMENT END:
SUGGESTED CHANGES START:
Revisit this entire clause for modifications based on the additions and
reordering in the rest of this amendment. In fact, it may be
appropriate to add a new clause on 'provider bridge management'.
SUGGESTED CHANGES END:
NAME: Glenn Parsons
COMMENT TYPE: ER
CLAUSE: 16
PAGE: 93
LINE: 10
COMMENT START:
Reference clauses is inconsistent. All items in enumerated list should
have cross-references. In addition, list is inserted into the middle
of the opening paragraph.
COMMENT END:
SUGGESTED CHANGES START:
Add references to all items in list
e.g., f) maintenance ... (clause 12)
And rejoin the opening paragraph.
SUGGESTED CHANGES END:
NAME: Glenn Parsons
COMMENT TYPE: ER
CLAUSE: 16
PAGE: 93
LINE: 1
COMMENT START:
Referenced subclauses throughout clause are incorrect as a result of
the additional text.
COMMENT END:
SUGGESTED CHANGES START:
Fix references, e.g.,
In 16.2: 16.3 -> 16.6
In 16.4: 16.5 -> 16.3
And rejoin the opening paragraph.
SUGGESTED CHANGES END:
NAME: Glenn Parsons
COMMENT TYPE: T
CLAUSE: 16.1
PAGE: 93
LINE: 10
COMMENT START:
The layout of this clause is inconsistent with clause 7. That is the
interelation of the principle elements is not shown. Further it is not
clear why other subclauses from 15 cloud not be added as elements.
COMMENT END:
SUGGESTED CHANGES START:
Include an relationship figure similar to Fig 7-1
SUGGESTED CHANGES END:
NAME: Glenn Parsons
COMMENT TYPE: TR
CLAUSE: 16.2
PAGE: 94
LINE: 1
COMMENT START:
This is not an architecture, but rather several example networks. If
an architecture is intended, it should be drawn and described more
clearly.
COMMENT END:
SUGGESTED CHANGES START:
Remove all instances of 'architecture' in titles and text.
Remove first paragraph.
SUGGESTED CHANGES END:
NAME: Glenn Parsons
COMMENT TYPE: TR
CLAUSE: A
PAGE: 99
LINE: 1
COMMENT START:
This amendment is incomplete without a PICS. The draft is sufficiently
stable to add PICS.
COMMENT END:
SUGGESTED CHANGES START:
Include updated PICS based on amendment. Add a new table A.16 Provider
Bridge support
SUGGESTED CHANGES END:
P802.1ad/D3 Ballot EMAIL BALLOT
9th November 2004
TO: Mick Seaman
Editor, P802.1ad
SUBJECT: [802.1] P802.1ad/D3 Ballot - Disapprove
_____ I Approve (may attach non-binding comments below)
__X__ I Disapprove (must attach binding comments below)
_____ I Abstain for the following reasons (may attach non-binding comments
below):
______ Lack of Time
______ Lack of Expertise
______ Other: _______________________________________________
__Osama Aboul-Magd_____________
(Name)
___613-763-5827_______________
(Telephone No.)
------------------------------------------------------------------------
NAME: Osama Aboul-Magd
COMMENT TYPE: TR
CLAUSE: 8.6.4
PAGE: 42
LINE: 1
COMMENT START:
This section seems to be mixing flow classification with flow metering. For
example the last sentence of the first paragraph implies that frames can be
discarded based on destination MAC address, VID, priority, etc. I believe
what is meant here is that frames can be classified and metered based on
those parameters. The other two parameters on the list (drop-eligible and
frame size) are traffic parameters that are useful for metering, but not used
for classification.
COMMENT END:
SUGGESTED CHANGES START:
Introduce
"incoming
criteria.
Priority,
a new section, 8.6.x on classification. This section may include
frames are classified before metering based on a number of
Classification criteria may include destination MAC address, VID,
or a suitable combination of these parameters"
SUGGESTED CHANGES END:
NAME: Osama Aboul-Magd
COMMENT TYPE: T
CLAUSE: 8.6.4
PAGE: 42
LINE:
COMMENT START:
Flow metering and actions are discussed in this section and are mentioned in
a number of other places. However there is no mention of any metering
algorithms or any reference other than the vague note at the bottom of
section 8.6.4.
COMMENT END:
SUGGESTED CHANGES START:
Consideration of different metering algorithms should be discussed with the
pros and cons of each.
SUGGESTED CHANGES END:
Osama,
Let me try my point again.
The specification does not detail anything about the behavior of the two pieces apart from overall
constraints and that one immediately follows another. So in spliting them apart we are (a) attempting to
teach the world something it largely already knows (b) actually starting down the path of restricting their
behavior - you classify frame to two distinct meters, then the meters cannot communicate to set a marker
based on their sum I presume. Other consequences might be deduced, correctly or incorrectly, from our
words. Do we want to get into that given that we currently have zero normative consequences (i.e. no
"shall", "should", or "may"), or do we want to say the absolute minimum to just indicate that the whole
functionality - classify, meter, mark - belongs (if implemented) at this point in the packet flow (and not
anywhere else)
There are other areas in the spec where we specify a function as a black box. In fact the whole of the
bridge model in clause 8 says that it does not constrain implementation but any equivalent external
behavior is valid. If we are not specifying behavior do we need break it down?
I don't want to make too big a deal of this. My only worry is that we are going to have a growing piece of
the text which is just unactionable advice. Applied to other things that could bloat the document. Every
time we get to maintain a document we find a certain amount of wisdom that has no conformance
implications, and is out of date. Usually it gets thrown away because no one much cares about it,
certainly not enough to maintain it.
The thing that could really change this (black box - say the minimum - versus detail the structure of the
box) is management. If we are to have management variables reporting the type (say) of a classifier or of
a meter then we should have the structure at this point, and mention the variables. Likewise if we are to
structure out classification-metering-marking then are we just going to come back to the next ballot with a
comment to provide such a management variable.
Given that this is a very small amount of text required, probably less than 15 lines total, could you draft a
paragraph or two that we could consider as a starting point in the meeting?
On the issue of comparisons and guides to meters etc. I am not saying that we really need an Annex on
the subject. What I am saying is that if we *are* going to have pure tutorial that does not lead onto
normative consequnces within the main body of the standard, then that material should be in an Annex.
However if we just want references that is far easier to do. We could just add a NOTE to clause 8.6.1. For
example:
"NOTE--Classifiers and meter that could be adapted for the purposes of this clause are described in
<ref>, <ref>, <ref>. See Annex Y (Bibliography)."
If you could supply the references that would be most useful. It would be nice to have them in two forms:
a) A short informal form, good for including in a paragraph in the main text.
b) Full descriptive reference form for the Bibliography.
Note that these would go in the Bibliography rather than in the References. That is because the
References (as per current IEEE directives) are for things that have to be used to meet normative
provisions of the standard, rather than general information. However I don't think that changes the
information that would be best in each reference. Chasing down and correcting references is one of an
editor's most thankless tasks, so I'd appreciate your help.
Mick
-----------------------------------------------------Original Message----From: IEEE 802.1 [mailto:hdk-0316.pflrk@att.net]On Behalf Of Osama Aboul-Magd
Sent: Wednesday, November 10, 2004 3:44 PM
To: STDS-802-1-L@listserv.ieee.org
Subject: Re: [802.1] P802.1ad/D3 Ballot - Flow Metering Considerations
Hi Mick,
Please see inline.
Regards;
Osama Aboul-Magd
ATI Strategic Standards and Protocols
Nortel Networks
P.O. Box 3511, Station C
Ottawa, Ontario, Canada
K1Y-4H7
Tel: +1 613 763 5827
e.mail:osama@nortelnetworks.com
-----Original Message----From: Mick Seaman [mailto:mick_seaman@ieee.org]
Sent: Wednesday, November 10, 2004 2:55 PM
To: Aboul-Magd, Osama [CAR:1A11:EXCH]; STDS-802-1-L@listserv.ieee.org
Subject: RE: P802.1ad/D3 Ballot - Flow Metering Considerations
Osama,
With reference to your comments on flow metering below.
1. There has been no proposal for a flow metering spec so going to a final level of granularity
here does not seem to serve any purpose, i.e. the classification then begs the question of what
the flow metering specification is. Separating the classification from the metering implies that
there is a known relationship between classifiers and meters, but if we have no spec for a meter
how can we judge the consequence of that partitioning?
[osama] The point I am raising here is totally orthogonal to a particular specification of a metering
algorithm. Classification and metering are two distinct functions and they should be treated as such.
Classification identifies frames that share some common feature between them, e.g. MAC address, VID,
etc. and are to be subjected to same metering function. The metering function is performed based on
some set of traffic parameters and frames are passed, marked, or dropped based on their compliance
with those parameters. I don't see why the high level functionality should be tight to a specific meter.
2. This is a standard not a tutorial, so a subject overview with no normative consequences is out
of place, however if someone were to produce such an overview it might find a place as Annex.
Do you have text for the group to consider?
[osama] Yes, I understand it is not a tutorial and I am not asking for one. I was just asking for some
references. However if the group feel that there is the need to have this info in an annex, I am more than
willing to draft some text.
Mick
NAME: Osama Aboul-Magd
COMMENT TYPE: TR
CLAUSE: 8.6.4
PAGE: 42
LINE: 1
COMMENT START:
This section seems to be mixing flow classification with flow metering.
For example the last sentence of the first paragraph implies that
frames can be discarded based on destination MAC address, VID,
priority, etc. I believe what is meant here is that frames can be
classified and metered based on those parameters. The other two
parameters on the list (drop-eligible and frame size) are traffic
parameters that are useful for metering, but not used for
classification.
COMMENT END:
SUGGESTED CHANGES START:
Introduce a new section, 8.6.x on classification. This section may
include "incoming frames are classified before metering based on a
number of criteria. Classification criteria may include destination MAC
address, VID, Priority, or a suitable combination of these parameters"
SUGGESTED CHANGES END:
NAME: Osama Aboul-Magd
COMMENT TYPE: T
CLAUSE: 8.6.4
PAGE: 42
LINE:
COMMENT START:
Flow metering and actions are discussed in this section and are
mentioned in a number of other places. However there is no mention of
any metering algorithms or any reference other than the vague note at
the bottom of section 8.6.4.
COMMENT END:
SUGGESTED CHANGES START:
Consideration of different metering algorithms should be discussed with
the pros and cons of each.
SUGGESTED CHANGES END:
NAME: Osama Aboul-Magd
COMMENT TYPE: TR
CLAUSE: 8.6.7
PAGE: 45
LINE: second paragraph
COMMENT START:
Couple of typos:
This paragraph implies the need for the H/W to be able to remove frames from
the middle of the queue. It further implies that the need to maintain a timer
per frame and compare it to some performance objective. I don't think this is
feasible and it adds tremendous complexity to the H/W. In all other data
networks, ATM, FR, IP etc, DE eligibility is only used for discarding frames
upon arrivals only. It has never been used to remove frames that are already
sitting in the queue.
COMMENT END:
SUGGESTED CHANGES START:
Remove the middle part of this section and replace with text that states that
"frames with their DE indication set are discarded upon arrival when the port
is congested". The use of the word "removal" should be avoided.
SUGGESTED CHANGES END:
NAME: Osama Aboul-Magd
COMMENT TYPE: T
CLAUSE: Annex G
PAGE: 103
LINE:
COMMENT START:
several traffic management terms have been used without the proper
definition. This includes "metering", "policing". Since those terms may have
different meanings to different people there is the need to formally define
those terms
COMMENT END:
SUGGESTED CHANGES START:
Include the definition of the different terms related to traffic management.
Those terms may include classification, traffic conditioning, metering
policing, expedited forwarding, assured forwarding, etc.
SUGGESTED CHANGES END:
NAME: Osama Aboul-Magd
COMMENT TYPE: TR
CLAUSE: Annex G
PAGE: 103
LINE: fourth paragraph
COMMENT START:
it is stated that "the specification mandates strict priority frame
transmission but permits the use of additional traffic class based
transmission selection algorithm". It seems that there is a contradiction
here. If strict priority is mandated, how class based scheduler can be added?
Does this mean that a vendor would have to implement two scheduler types?
COMMENT END:
SUGGESTED CHANGES START:
Remove this paragraph. Add a statement that transmission scheduling is an
implementation issue.
SUGGESTED CHANGES END:
NAME: Osama Aboul-Magd
COMMENT TYPE: TR
CLAUSE: Annex G.3
PAGE: 104
LINE: item "b" on integrated service support
COMMENT START:
I am assuming this is RSVP integrated services. IS is a very difficult
service to configure and includes many parameters that need to be signaled. I
suggest removing this part, otherwise the group must spell out how support of
IS will be accomplished
COMMENT END:
SUGGESTED CHANGES START:
Remove this item.
SUGGESTED CHANGES END:
NAME: Osama Aboul-Magd
COMMENT TYPE: TR
CLAUSE: Annex G
PAGE: 103
LINE:
COMMENT START:
I believe there is the need to introduce a QoS architecture that is similar
to that in the differentiated services where the different QoS components
including classification, metering, marking, dropping are introduced. Many
concepts in the draft are borrowed from the differentiated service
architecture
COMMENT END:
SUGGESTED CHANGES START:
I suggest the draft endorse differentiated service model, its definitions,
and concepts like PHB, EF, AF, etc.
Remove this item.
SUGGESTED CHANGES END:
NAME: Osama Aboul-Magd
COMMENT TYPE: TR
CLAUSE: Annex G.3
PAGE: 104
LINE: item "b" on integrated service support
COMMENT START:
I am assuming this is RSVP integrated services. IS is a very difficult
service to configure and includes many parameters that need to be signaled. I
suggest removing this part, otherwise the group must spell out how support of
IS will be accomplished
COMMENT END:
SUGGESTED CHANGES START:
Remove this item.
SUGGESTED CHANGES END:
P802.1ad/D3 Ballot EMAIL BALLOT
9th November 2004
TO: Mick Seaman
Editor, P802.1ad
SUBJECT: <See above>
_____ I Approve (may attach non-binding comments below)
__X__ I Disapprove (must attach binding comments below)
_____ I Abstain for the following reasons (may attach non-binding comments
below):
______ Lack of Time
______ Lack of Expertise
______ Other: _______________________________________________
Paul Bottorff
(Name)
408-495-3365
(Telephone No.)
-----------------------------------------------------------------------NAME: Paul Bottorff
COMMENT TYPE: T
CLAUSE: 5.9
PAGE: 15
LINE:
COMMENT START:
Section 5.9 seems to indicate that the C-VLAN component of a Provider Edge
Bridge would need to implement a full 802.1Q relay and filter. This makes the
"UNI Wart" a full bridge function making designs very complicated. The
requirement for relay and filter should be dropped from the conformance
requirements.
COMMENT END:
SUGGESTED CHANGES START:
Change bullet "a) comprise a single conformant VLAN-aware Bridge component"
to "a) conform to a VLAN-aware Bridge component requirements a-c and e-k."
SUGGESTED CHANGES END:
NAME: Paul Bottorff
COMMENT TYPE: T
CLAUSE: 8.6.4
PAGE: 42
LINE:
COMMENT START:
Flows may be either metered or marked. If the port is color un-aware then
frames appearing MAY be discarded, marked drop eligible, or marked noneligible. If the port is color aware then drop eligible and non-eligible
frames may be metered to determine if frames are to be dropped.
COMMENT END:
SUGGESTED CHANGES START:
Change title of 8.6.4 to Frame Metering and Marking. Replace "metering" with
"metering and marking".
SUGGESTED CHANGES END:
NAME: Paul Bottorff
COMMENT TYPE: T
CLAUSE: 8.6.4
PAGE: 42
LINE:
COMMENT START:
The frame marking could occur at the Customer Network Port or at the Customer
Edge Port. Both of these cases should be mentioned explicitly.
COMMENT END:
SUGGESTED CHANGES START:
Change "Bridge Port" in the first sentence to "Customer Network Port or
Customer Edge Port".
SUGGESTED CHANGES END:
NAME: Paul Bottorff
COMMENT TYPE: T
CLAUSE: 8.6.4
PAGE: 42
LINE:
COMMENT START:
The section on flow metering should specify a specific filter for use at the
Port. I would recommend doing this by cross reference to the MEF 5 Traffic
Management Specification.
COMMENT END:
SUGGESTED CHANGES START:
Add a reference to MEF 5 Traffic Management Specification: Phase 1 section
6.2.
SUGGESTED CHANGES END:
NAME: Paul Bottorff
COMMENT TYPE: T
CLAUSE: 12
PAGE: 81
LINE:
COMMENT START:
At very least the MIBs need to include information about the different types
of relays supported. There is at least a 802.1Q VLAN bridge relay, a 802.1ad
S-VLAN relay, and a 802.1ad C-VLAN relay. Further MIB extensions should be
provided to support configuration of bandwidth profiles for Edge Ports.
COMMENT END:
SUGGESTED CHANGES START:
SUGGESTED CHANGES END:
NAME: Paul Bottorff
COMMENT TYPE: T
CLAUSE: 15.4
PAGE: 89
LINE:
COMMENT START:
This section needs to say more about functions which are and are not
supported by the C-VLAN component of the Provider Edge Bridge. For instance
the text should describe how BPDUs are handled and what GARP frames effect.
COMMENT END:
SUGGESTED CHANGES START:
SUGGESTED CHANGES END:
P802.1ad/D3 Ballot EMAIL BALLOT
9th November 2004
TO: Mick Seaman
Editor, P802.1ad
SUBJECT: [802.1] P802.1ad/D3 Ballot - Disapprove
_____ I Approve (may attach non-binding comments below)
__X__ I Disapprove (must attach binding comments below)
_____ I Abstain for the following reasons (may attach non-binding comments
below):
______ Lack of Time
______ Lack of Expertise
______ Other: _______________________________________________
__Dinesh Mohan_____________
(Name)
___613-763-4794_______________
(Telephone No.)
NAME: Dinesh Mohan
COMMENT TYPE: ER
CLAUSE: 8.2
PAGE: 34
LINE: 3
COMMENT START:
Reference to EISS clauses is incorrect. Correct reference is 6.6 and 6.7
according to new organization of clauses.
COMMENT END:
SUGGESTED CHANGES START:
Change 6.4 and 6.5 to 6.6 and 6.7
SUGGESTED CHANGES END:
NAME: Dinesh Mohan
COMMENT TYPE: T
CLAUSE: 8.13
PAGE: 64
LINE:
COMMENT START:
Though SNMP seems most likely candidate for Bridge Management protocol, does
the management protocol need to be limited to SNMP? If interoperability is
the desire, which version of SNMP is to be recommended?
COMMENT END:
Hi,
I am "on loan from the
The purpose of this is
the responsibility for
the IETF Bridge-mib WG
IETF" as a "MIB Doctor" for the IEEE 802.1 WG.
to provide IETF-expert review of mib modules as
802.1-related MIB modules is transitioned from
to the IEEE 802.1 WG.
As a newbie to IEEE process, I am not quite sure how I should respond
to COMMENTS, but feel that my input might be helpful here.
It is important to distinguish the SMI, which is used to write MIB
modules, from SNMP, which is a protocol that is designed to carry
objects defined in MIB modules. The current version of SMI is SMIv2
(IETF STD 58) and the current version of SNMP is SNMPv3 (IETF STD 62).
The protocol used to transfer MIB module defined objects does not need
to be limited to SNMP, at least not for technical reasons. An
SMIv2-compliant mib module can be used by other protocols if desired.
Dan is correct about the current status of SNMP in the IETF, but I
think the motivation is more important to consider. All SNMP versions
prior to SNMPv3 have been declared "Historic" by the IETF because they
all provide a level of security that is considered inadequate to
address current threats to network management. SNMPv3 is the
recommended version of SNMPv3 because it provides security deemed
adequate to address current threats to network management.
David Harrington
dbharrington@comcast.net
Co-chair IETF SNMPv3 WG, concluded
Co-chair IETF Bridge-mib WG (concluding)
IETF MIB Doctor
________________________________
From: IEEE 802.1 [mailto:hdk-0316.pflrk@att.net] On Behalf Of
Romascanu, Dan (Dan)
Sent: Tuesday, November 09, 2004 5:47 PM
To: STDS-802-1-L@listserv.ieee.org
Subject: Re: [802.1] P802.1ad/D3 Ballot - Disapprove
SNMPv3 is the IETF standard version of SNMP. The previous
versions of the protocol are historic.
Regards,
Dan
NAME: Dinesh Mohan
COMMENT TYPE: T
CLAUSE: 8.13
PAGE: 64
LINE:
COMMENT START:
Though SNMP seems most likely candidate for Bridge
Management protocol, does the management protocol need to be limited
to SNMP? If interoperability is the desire, which version of SNMP is
to be recommended?
COMMENT END:
SUGGESTED CHANGES START:
The text of clause 8.13 in 802.1Q-2003 can be retained
with a note that SNMP is the recommended protocol in conjunction with
the MIBs. It would be also useful to indicate a preference for a
specific version SNMP e.g. SNMPv3
SUGGESTED CHANGES END:
SUGGESTED CHANGES START:
The text of clause 8.13 in 802.1Q-2003 can be retained with a note that SNMP
is the recommended protocol in conjunction with the MIBs. It would be also
useful to indicate a preference for a specific version SNMP e.g. SNMPv3
SUGGESTED CHANGES END:
NAME: Dinesh Mohan
COMMENT TYPE: E
CLAUSE: 11
PAGE: 80
LINE:
COMMENT START:
Couple of typos:
Line 1 indicates that no changes are needed in Clause 11 which is not correct
since some changes are being made.
Clause 11.2.4 Line 1: change "receives" to "received"
COMMENT END:
SUGGESTED CHANGES START:
Clause 11: remove 1st line
Clause 11.2.4 Line 1: Change "receives" to "received"
SUGGESTED CHANGES END:
NAME: Dinesh Mohan
COMMENT TYPE: T
CLAUSE: 11
PAGE: 80
LINE:
COMMENT START:
It is not entirely clear if the introduction of clause 11.2.4 is expected to
lead to some changes in clause 11.3 "conformance to GVRP"
COMMENT END:
SUGGESTED CHANGES START:
Please state if this amendment makes any changes to Clause 11.3 and 11.4
SUGGESTED CHANGES END:
NAME: Dinesh Mohan
COMMENT TYPE: TR
CLAUSE: 12
PAGE: 81
LINE: 3
COMMENT START:
Note mentions that the amendment makes no changes to clauses 12.1 through
12.8.1. However, it is clear that some changes would be required. Consider
the following examples:
Clause 12.2 - bullet c: reference to clause 8.7 would now refer to
clause 8.5
Clause 12.2 - bullet d: reference to clause 8.11 (which is also
incorrect) should change to 8.9
-
Clause 12.2 - bullet e: reference to 8.12 should be changed to 8.11
Clause 12.6.2: reference to user-priority would be lost since EISS
changed
Clause 12.6.2: reference to access priority would be lost since EISS
changed
Clause 12.6.2.4: reference to user priority regeneration table is
lost as per modified clause 8.5
COMMENT END:
SUGGESTED CHANGES START:
Remove statement indicating that no changes to clause 12.1 through 12.8.1.
Moreover this clause needs to be addressed for changes to synchronize with
amendments e.g. as per the above examples.
SUGGESTED CHANGES END:
Dinesh
P802.1ad/D3 Ballot EMAIL BALLOT
9th November 2004
TO: Mick Seaman
Editor, P802.1ad
SUBJECT: <See above>
_____ I Approve (may attach non-binding comments below)
__X__ I Disapprove (must attach binding comments below)
_____ I Abstain for the following reasons (may attach non-binding
comments
below):
______ Lack of Time
______ Lack of Expertise
______ Other: _______________________________________________
___Dirceu Cavendish_________________________
(Name)
___1-408-863-6041__________________________
(Telephone No.)
-----------------------------------------------------------------------INCLUDE COMMENTS BELOW THIS POINT
NAME: Dirceu Cavendish
COMMENT TYPE: TR
CLAUSE: all
PAGE: all
LINE: all
COMMENT START:
The provider bridge model is "buried" in sec 15. Yet, its concepts and
nomenclature (e.g. "CVLAN aware / S-VLAN aware bridge",
"customer/provider network port", etc) is everywhere in the text,
without explicit reference to the model(s). That makes the document VERY
hard to read. Worst of all, section 8 - principles of operation comes
with a bridge model (Fig. 8.2) that is not comprehensive enough to
include the concepts discussed in clause 8. So the reader is lost.
COMMENT END:
SUGGESTED CHANGES START:
For a start, include a comprehensive PB model in clause 8, under "bridge
architecture". I suggest the selection of one of figures from clause 15,
perhaps Fig. 15-4. Then, all concepts included in the model should be
listed with their definitions in clause 3 - Definition.
SUGGESTED CHANGES END:
NAME: Dirceu Cavendish
COMMENT TYPE: TR
CLAUSE: 6.10
PAGE: 28
LINE: all
COMMENT START:
I don't remember any discussion about making room for "additional
technology" text. So I don't know what is the rational for the section.
COMMENT END:
SUGGESTED CHANGES START:
Remove section 6.10
SUGGESTED CHANGES END:
NAME: Dirceu Cavendish
COMMENT TYPE: TR
CLAUSE: 8.2
PAGE: 33
LINE: all
COMMENT START:
Fig. 8-2 does not contain the concepts/elements of a Provider Bridge.
COMMENT END:
SUGGESTED CHANGES START:
Replace Fig. 8-2 with a PB model that includes the concepts discussed in
the following sub-sections (model of operation, etc...)
SUGGESTED CHANGES END:
NAME: Dirceu Cavendish
COMMENT TYPE: TR
CLAUSE: 8.6
PAGE: 40
LINE: all
COMMENT START:
COMMENT END:
SUGGESTED CHANGES START:
For consistency with subsequent subsection titles, replace "Ingress and
VLAN classification (8.6.1)" with "Ingress" in Fig. 8-8. Alternatively,
alter section 8.6.1 title according to figure...
SUGGESTED CHANGES END:
NAME: Dirceu Cavendish
COMMENT TYPE: TR
CLAUSE: 9.7
PAGE: 76
LINE: all
COMMENT START:
Typos on fig. of clause 9.7, change as below.
COMMENT END:
SUGGESTED CHANGES START:
Fig. caption - Fig 9-1 should be fig. 9-2; C-TAG TCI Format sound be
S-TAG TCI format.
SUGGESTED CHANGES END:
NAME: Dirceu Cavendish
COMMENT TYPE: TR
CLAUSE: 9.7
PAGE: 76
LINE: all
COMMENT START:
Given the widespread usage of QinQ solutions, QinQ frame format should
be reflected in more than a footnote...
COMMENT END:
SUGGESTED CHANGES START:
SUGGESTED CHANGES END:
NAME: Dirceu Cavendish
COMMENT TYPE: TR
CLAUSE: 15.5
PAGE: 90
LINE: all
COMMENT START:
Inconsistency between explanatory text of Fig. 15-7 and the figure.
COMMENT END:
SUGGESTED CHANGES START:
Change "Customer controlled Provider Bridge" label of rightmost bridge
to "Customer controlled Provider EDGE Bridge."
SUGGESTED CHANGES END:
NAME: Dirceu Cavendish
COMMENT TYPE: TR
CLAUSE: 15.6
PAGE: 90
LINE: all
COMMENT START:
Reference to "service instance" without its definition in clause 3.
COMMENT END:
SUGGESTED CHANGES START:
Define service instance, otherwise issues such as the number of service
instances supported by the provider bridge network can not be gauged. A
sharp conceptual definition of customer, provider, and service must be
included.
SUGGESTED CHANGES END:
P802.1ad/D3 Ballot EMAIL BALLOT
9th November 2004
TO: Mick Seaman
Editor, P802.1ad
SUBJECT: [802.1] P802.1ad/D3 Ballot - Approve
__X__ I Approve (may attach non-binding comments below)
_____ I Disapprove (must attach binding comments below)
_____ I Abstain for the following reasons (may attach non-binding comments
below):
______ Lack of Time
______ Lack of Expertise
______ Other: _______________________________________________
__Ali Sajassi_____________
(Name)
___408-853-5310_______________
(Telephone No.)
P802.1ad/D3 Ballot EMAIL BALLOT
9th November 2004
TO: Mick Seaman
Editor, P802.1ad
SUBJECT: <See above>
___X_ I Approve (may attach non-binding comments below)
_____ I Disapprove (must attach binding comments below)
_____ I Abstain for the following reasons (may attach non-binding comments
below):
______ Lack of Time
______ Lack of Expertise
______ Other: _______________________________________________
___David Frattura___________________________
(Name)
____212-946-9239____________________________
(Telephone No.)
-----Original Message----From: IEEE 802.1 [mailto:hdk-0316.pflrk@ATT.NET]
Sent: Wednesday, November 10, 2004 7:23 AM
To: STDS-802-1-L@listserv.ieee.org
Subject: [802.1] P802.1ad/D3 Ballot - Abstain
P802.1ad/D3 Ballot EMAIL BALLOT
9th November 2004
TO: Mick Seaman
Editor, P802.1ad
SUBJECT: <See above>
___X__ I Approve (may attach non-binding comments below)
_____ I Disapprove (must attach binding comments below)
____ I Abstain for the following reasons (may attach non-binding
comments
below):
_____ Lack of Time
______ Lack of Expertise
______ Other: _______________________________________________
Ran Ish-Shalom
(Name)
+1 978 287 9148______________________________
(Telephone No.)
-----------------------------------------------------------------------INCLUDE COMMENTS BELOW THIS POINT
802.1ad/D3 Ballot EMAIL BALLOT
9th November 2004
TO: Mick Seaman
Editor, P802.1ad
SUBJECT: <See above>
__X__ I Approve (may attach non-binding comments below)
_____ I Disapprove (must attach binding comments below)
_____ I Abstain for the following reasons (may attach non-binding comments
below):
______ Lack of Time
______ Lack of Expertise
______ Other: _______________________________________________
__Mick_Seaman_____________
(Name)
___415-722-6843_______________
(Telephone No.)
------------------------------------------------------------------------
NAME: Mick Seaman
COMMENT TYPE: E
CLAUSE:
PAGE:
LINE:
COMMENT START:
It's time to move this to the WG ballot cycle and put more of an onus on
commenters to provide text to meet their comments.
COMMENT END:
SUGGESTED CHANGES START:
Issue next revision for WG ballot.
SUGGESTED CHANGES END:
NAME: Mick Seaman
COMMENT TYPE: T
CLAUSE: 8.9
PAGE: 49
LINE:
COMMENT START:
As the editor's note says the changes to allow wild cards in filtering
entries are clearly required for operation at any scale. Actually they are
really independent of provider bridging and should get carried into .1Q rev,
which will make it a lot easier to organize changes to this text - there is
no real reason to couple the change to provider bridging.
COMMENT END:
SUGGESTED CHANGES START:
Put the wildcard filtering entry changes into .1Qrev, i.e. remove them from
.1ad.
SUGGESTED CHANGES END:
NAME: Mick Seaman
COMMENT TYPE: T
CLAUSE: 8.6.1
PAGE: 44
LINE:
COMMENT START:
The Enable Ingress Filtering control is not sufficient to enable the
provision of E-TREE services, as those require ingress control that is
independent of the Member Set - which is really an output member set. This
is really a deficiency in basic .1Q capabilities, as shared VLANs to support
E-TREE like configurations or "private VLANs" are explicitly in .1Q. We have
done without the explicit ingress control in the past because of the sigle
administrative control assumption for most LANs. My preference would be, as
this is a basic capability and not provider bridge specific, to fix this in
.1Qrev as an optional parameter along with Enable Ingress Filtering.
COMMENT END:
SUGGESTED CHANGES START:
Fix as suggested in .1Qrev, not in .1ad. If this is unacceptable, add an
optional configurable Ingress Member Set parameter to .1ad Clause 8.6.1. If
Enable Ingress Filtering is set, the frames accepted on ingress will be the
intersection of those admitted by this parameter and by the Member Set.
SUGGESTED CHANGES END: