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 C-priority. 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 that are prefixed with
Customer and Provider, but no definition of what these
are or what is the difference between a Customer and
Provider themselves. Provide definitions for customer
and provider.
COMMENT END:
SUGGESTED CHANGES START:
Add definitions for the above terms.
SUGGESTED CHANGES END:
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 |