802grouper.ieee.org/groups/802/1/files/public/docs2004/ad-c… · Web view9th November 2004. TO: Mick Seaman. Editor, P802.1ad. SUBJECT: XX_ I Approve (may

802.1ad/D3 Ballot EMAIL BALLOT9th November 2004TO: Mick SeamanEditor, P802.1adSUBJECT: <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 commentsbelow):______ Lack of Time______ Lack of Expertise______ Other: _______________________________________________

_____________Tony Jeffree_______________________________(Name)_____________+44-161-973-4278_______________________________(Telephone No.)

NAME: Tony JeffreeCOMMENT TYPE: N/ACLAUSE: GeneralPAGE:LINE:COMMENT START:

While still in need of some work in places, I believe this document isready 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 JeffreeCOMMENT TYPE: ERCLAUSE: 1, 3, 5, 6, 8, 9, 13, GPAGE:LINE:COMMENT START:

Many of the changes defined in these clauses are now incorporated into theQ Revision draft.

COMMENT END:SUGGESTED CHANGES START:

Amend these clauses such that the AD draft just contains those changes thatare additional to the ones incorporated into Q REV. TJ will work with theEditor to provide the necessary text.


802.1ad/D3 Ballot EMAIL BALLOT9th November 2004TO: Mick SeamanEditor, P802.1adSUBJECT: [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-bindingcommentsbelow):______ 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 HeerCOMMENT TYPE:TCLAUSE: 3PAGE: 8LINE:

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 HeerCOMMENT TYPE:TCLAUSE: 3, 5.7-10PAGE: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 bridgeC-VLAN aware component: VLAN aware component with the EISS supported by the use of a C-TagS-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.75.7 add: A VLAN aware component comprises all the MAC method independent functionality of a VLAN aware bridge.SUGGESTED CHANGES END:

NAME: Arjan de HeerCOMMENT TYPE: ECLAUSE: 5.7-5.10PAGE: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 HeerCOMMENT TYPE:TCLAUSE: 5.6PAGE: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 HeerCOMMENT TYPE: ECLAUSE: 6PAGE: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.1SUGGESTED CHANGES END:

NAME: Arjan de HeerCOMMENT TYPE: TCLAUSE: 6.8PAGE: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 HeerCOMMENT TYPE: TR

CLAUSE: 6.7.3PAGE: 25LINE:

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


NAME: Arjan de HeerCOMMENT TYPE: TCLAUSE: 6.7.3PAGE: 25LINE:

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 BALLOT9th November 2004TO: Mick SeamanEditor, P802.1adSUBJECT: <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-bindingcomments 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 CongdonCOMMENT TYPE: ECLAUSE: 3PAGE: 5LINE:COMMENT START:There are lots of definitions that are prefixed withCustomer and Provider, but no definition of what theseare or what is the difference between a Customer andProvider themselves. Provide definitions for customerand provider.COMMENT END:SUGGESTED CHANGES START:Add definitions for the above terms.SUGGESTED CHANGES END:

NAME: Paul CongdonCOMMENT TYPE: TCLAUSE: 6.6.1PAGE: 23LINE: 6COMMENT START:Provide clarification for what is meant by "comparableparameters".COMMENT END:SUGGESTED CHANGES START:I think "comparable parameters" refers only to trafficclass, and this is not something that appears in theEM_UNITDATA primitives.SUGGESTED CHANGES END:

NAME: Paul CongdonCOMMENT TYPE: ECLAUSE: many (5.9, 8.3, 8.6.1, 11.2.4)PAGE:

LINE:COMMENT START:VLAN translation table and VID translation table arebeing 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.



_____ 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 commentsbelow):______ Lack of Time______ Lack of Expertise______ Other: _______________________________________________

__Stephen_Haddock_____________(Name)___408-579-2812_______________(Telephone No.)------------------------------------------------------------------------

NAME: Stephen HaddockCOMMENT TYPE: TCLAUSE: 16.3PAGE: 96LINE:COMMENT START:More needs to be said on how Provider Bridges handle customer frames withreserved addresses, particularly at Customer Edge Ports where it seems to methe natural thing would be for the C-VLAN aware component to filter theseframes just as a VLAN Bridge would. This implies a Customer Edge Port wouldeither block all customer BPDUs, or would participate in the customerspanning tree. There are alternate proposals where the C-VLAN awarecomponent does not filter reserved addresses, but I believe there arefurther constraints necessary to allow this. For example I think it onlyworks for customer BPDUs if the service instance selected by the PVID forthe Customer Edge Port has full connectivity to all service access pointsreachable by any service instances that can be selected at that CustomerEdge Port. If this is the model we choose then we need to enumerate anyrelevant constraints.COMMENT END:SUGGESTED CHANGES START:Replace the sentence "Frames received by Provider Bridge Ports and addressedto the Bridge Group Address are subject to service instance selection andrelay in the same way as customer data frames." with a new paragraph asfollows:

"When frames received at a Customer Network Port contain a destinationaddress that is reserved for C-VLAN aware Bridges (table 8-1) but not S-VLANaware bridges (table 8-2), these frames are subject to service instanceselection and relay in the same way as customer data frames. When theseframes are received at a Customer Edge Port they are filtered by the C-VLANaware component of the Provider Edge Bridge. The C-VLAN aware component mayparticipate in protocols utilizing these addresses, and may generate framescontaining these addresses that are forwarded on an internal connection froma Provider Edge Port to a Customer Network Port, and are then subject toservice instance selection and relay by the S-VLAN aware component."SUGGESTED CHANGES END:

NAME: Stephen HaddockCOMMENT TYPE: ECLAUSE: 16.1PAGE: 93LINE:COMMENT START:I'm confused by bullet b. Section 15.7 describes service selection andidentification for customer frames on ingress to the provider network. Whenbullet b says "service instance identification for each customer frame onegress that mean egress through a Provider Network Port or a CustomerNetwork Port?COMMENT END:SUGGESTED CHANGES START:Change bullet b to "Service instance selection and identification for eachcustomer frame on ingress to the provider network (15.7)."SUGGESTED CHANGES END:

NAME: Stephen HaddockCOMMENT TYPE: TCLAUSE: 6.7.3PAGE: 26LINE: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 eachPort" 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 notset, the DE bit shall be transmitted as zero and ignored on recieve."SUGGESTED CHANGES END:

NAME: Stephen HaddockCOMMENT TYPE: ECLAUSE: 6.7.1PAGE: 23LINE: first line of 6.7.1COMMENT 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 aM_UNITDATA.indication primitive from"SUGGESTED CHANGES END:

NAME: Stephen HaddockCOMMENT TYPE: ECLAUSE: 6.7.2

PAGE: 24LINE: first line of 6.7.2COMMENT 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 aEM_UNITDATA.request primitive "SUGGESTED CHANGES END:

NAME: Stephen HaddockCOMMENT TYPE: TCLAUSE: 6.8PAGE: 27LINE:COMMENT START:This section creates a new option on a VLAN bridge (putting a priority-S-tagon a frame) that I feel is unnecessary. It allows a customer to request apriority of service for a frame when using a Port-based service interface toa Provider Bridge (15.3). I feel the capability for a customer to requestpriority 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 weend up with one leg of the baggy pants diagram that has two sets oftagging/untagging functions. It's also unclear how such a port is to handlereceived S-tagged frames (which you can argue it shouldn't if the ProviderBridge it's connected to strips S-tags, but ...).COMMENT END:SUGGESTED CHANGES START:Either1) delete section 6.8,or2) add the diagram below showing how/where S-tagging functions occur in thebaggy pants diagram, and specify what happens to a received frame containingan 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 | | |


NAME: Stephen HaddockCOMMENT TYPE: ECLAUSE: 5.2PAGE: 11LINE: last lineCOMMENT START:Missing reference.COMMENT END:SUGGESTED CHANGES START:Add "5.6" in "f) Provider Edge Bridge (5.6)"SUGGESTED CHANGES END:

NAME: Stephen HaddockCOMMENT TYPE: ECLAUSE: 5.4.1PAGE: 12LINE:COMMENT START:Circular reference.COMMENT END:SUGGESTED CHANGES START:Modify to "A VLAN Bridge may implement any C-VLAN component option notspecifically prohibited by 5.9.1."SUGGESTED CHANGES END:

NAME: Stephen HaddockCOMMENT TYPE: ECLAUSE: 5.5PAGE: 12LINE:COMMENT START:The concept of a port being configured as both a Provider Network Port and aCustomer Network Port is confusing.COMMENT END:SUGGESTED CHANGES START:Modify to "Each Port shall be capable of being configures as one of, and maybe capable of being configured as either of:"SUGGESTED CHANGES END:

NAME: Stephen HaddockCOMMENT TYPE: TCLAUSE: 5.6PAGE: 13

LINE: first lineCOMMENT 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 HaddockCOMMENT TYPE: ECLAUSE: 5.6PAGE: 13LINE: last line of clause 5.6COMMENT START:Difficult to parse whether the Provider Edge Port is connected to theProvider 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 beconnected to a distinct Customer Network Port on the S-VLAN component, usingconnections internal to the Provider Edge Bridge as specified in Clause6.9."SUGGESTED CHANGES END:

NAME: Stephen HaddockCOMMENT TYPE: ECLAUSE: 6.9 and 15.4PAGE: 28 and 89LINE: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 shownin Figure 15-4."

In Figure 15-4, change the references in the two "pants legs" connected bythe internal LAN from "Clause 6.5" to "Clause 6.9".SUGGESTED CHANGES END:

NAME: Stephen HaddockCOMMENT TYPE: ECLAUSE: 5.7 and 5.8PAGE: 13LINE: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 twobridge 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 afterthe S-VLAN component conformance (5.10).


NAME: Stephen HaddockCOMMENT TYPE: TCLAUSE: 5.7 and 5.8PAGE: 13LINE: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 stillnecessary (for example, we still want to require a VLAN bridge to implementSpanning Tree; now RSTP).COMMENT END:SUGGESTED CHANGES START:Add these back into clauses 5.7 and 5.8 respectively, with the referencesupdated.SUGGESTED CHANGES END:

NAME: Stephen HaddockCOMMENT TYPE: TCLAUSE: 5.9 or 6.7.3 or 9.6PAGE:LINE:COMMENT START:I don't think we want to require VLAN bridges to be capable of encoding dropprecedence in the C-tag (since this would make previously conformant VLANbridges suddenly non-conformant). It should be required that VLAN bridgesbe capable of carrying the priority parameter in the C-tag (which isequivalent to implementing just the 8P0D rows of tables 6-4 and 6-5), andoptional that they are capable of carrying the drop precedence parameterencoded with priority (implementing the remaining rows of tables 6-4 and6-5). I'm not sure whether it is more appropriate to make this distinctionin 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 aC-tag is optional.SUGGESTED CHANGES END:

NAME: Stephen HaddockCOMMENT TYPE: TCLAUSE: 8.6.5PAGE: 44LINE:COMMENT START:If a VLAN translation table is used, S-VIDs must be translated on egress aswell 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 oningress 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 BellCOMMENT TYPE: ECLAUSE: 1.1PAGE: 3LINE:COMMENT START:Typo in bullet (x).COMMENT END:SUGGESTED CHANGES START:Replace "connectivity provide to" with "connectivity provided to".SUGGESTED CHANGES END:

NAME: Les BellCOMMENT TYPE: ECLAUSE: 5.6PAGE: 13LINE:COMMENT START:In the NOTE at the top of the page, an aggregation should not be limited to twoindependent instances of a MAC.COMMENT END:SUGGESTED CHANGES START:Clarify that two, or more, independent instances of a MAC may be aggregated as asingle Customer Edge Port.SUGGESTED CHANGES END:

NAME: Les BellCOMMENT TYPE: ECLAUSE: 5.9PAGE: 15LINE: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 penultimateparagraph of clause 8.6.1.SUGGESTED CHANGES END:

NAME: Les BellCOMMENT TYPE: ECLAUSE: 5.10PAGE: 16LINE:COMMENT START:THe bullet numbering is non-standard.COMMENT END:

SUGGESTED CHANGES START:Renumber the bullets.SUGGESTED CHANGES END:

NAME: Les BellCOMMENT TYPE: ECLAUSE: 6.4PAGE: 18LINE: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 BellCOMMENT TYPE: ECLAUSE: 6.5PAGE: 21LINE: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 BellCOMMENT TYPE: ECLAUSE: 6.7.1PAGE: 24LINE: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 BellCOMMENT TYPE: ECLAUSE: 6.10PAGE: 28LINE:COMMENT START:Typo, missing space.COMMENT END:SUGGESTED CHANGES START:Replace "eachM_UNITDATA.request" with "each M_UNITDATA.request".SUGGESTED CHANGES END:

NAME: Les BellCOMMENT TYPE: ECLAUSE: 8.2PAGE: 34LINE:COMMENT START:

Figure 8-2 is annotated with the term "802.X" at the bottom of each port, whereit 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 intendedto refer to any of the IEEE 802 media types, e.g. 802.3, 802.5, 802.11, etc.SUGGESTED CHANGES END:

NAME: Les BellCOMMENT TYPE: ECLAUSE: 8.3PAGE: 35LINE: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 BellCOMMENT TYPE: ECLAUSE: 8.3PAGE: 35, 37LINE: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 BellCOMMENT TYPE: TCLAUSE: 8.6.1PAGE: 41LINE:COMMENT START:This clauses describes the discarding of untagged and priority-tagged frames ifAcceptable Frame Types is set to 'Admit Only VLAN-Tagged frames', but it doesnot describe the discarding of VLAN-Tagged frames when 'Admit Only Untaggedframes' is selected.COMMENT END:SUGGESTED CHANGES START:Add a paragraph describing the discarding of VLAN-Tagged frames when 'Admit OnlyUntagged frames' is selected.SUGGESTED CHANGES END:

NAME: Les BellCOMMENT TYPE: ECLAUSE: 8.6.1PAGE: 41LINE:

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 isreset".SUGGESTED CHANGES END:

NAME: Les BellCOMMENT TYPE: ECLAUSE: 8.7PAGE: 46LINE: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 theparagraph with "(8.7.1)".SUGGESTED CHANGES END:

NAME: Les BellCOMMENT TYPE: ECLAUSE: 8.9.3PAGE: 54LINE: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 BellCOMMENT TYPE: ECLAUSE: 8.9.8PAGE: 60, 61LINE: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 BellCOMMENT TYPE: TRCLAUSE: 8.13PAGE: 64LINE:COMMENT START:In keeping with previous versions of this standard, it should not mandate aspecific management protocol. Also, the specification is lacking detail in thisclause.COMMENT END:

SUGGESTED CHANGES START:It may be better to say that the Bridge Management Entity should support themanagement objects defined by:- RFC 1493 (or its proposed updatehttp://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 canbe found in the archive athttp://www.watersprings.org/pub/id/draft-ietf-bridge-ext-v2-02.txt )- RSTP MIB http://www.ietf.org/internet-drafts/draft-ietf-bridge-rstpmib-05.txt- MSTP MIB (to be defined)- Additional, new management parameters, as defined in clause 12, to manage thenew features introduced by this document - this new MIB should also be definedby a new clause, or annex, in this document.SUGGESTED CHANGES END:

NAME: Les BellCOMMENT TYPE: TRCLAUSE: 8.14.7PAGE: 66LINE:COMMENT START:This clause should refer to the Bridge Address defined in 8.14.8 as the MACdestination address for management of the Bridge. It should not refer to an IPaddress, or SNMP.COMMENT END:SUGGESTED CHANGES START:Refer to the Bridge Address as the address used to access the Bridge ManagementEntities.

References to an IP address and SNMP may be suggested in a NOTE, as an exampleof how to manage the Bridge via the Bridge Address.SUGGESTED CHANGES END:

NAME: Les BellCOMMENT TYPE: ECLAUSE: 8.14.9PAGE: 69LINE: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 BellCOMMENT TYPE: ECLAUSE: 8.14.9PAGE: 70LINE: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 BellCOMMENT TYPE: ECLAUSE: 8.14.10PAGE: 71LINE: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 BellCOMMENT TYPE: TCLAUSE: 9.6PAGE: 75LINE: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 wildcardmatch for any VID in management operations. If this value is to be used as awildcard, the Meaning/Use of this value must be updated to reflect this, in thistable.

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 aPVID or a member of a VID Set, or transmitted in a tag header. This VID valuemay be used to indicate a wildcard match for the VID in management operations orFiltering Database entries.SUGGESTED CHANGES END:

NAME: Les BellCOMMENT TYPE: TRCLAUSE: 12PAGE: 81LINE: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 perport/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 BellCOMMENT TYPE: ECLAUSE: 13.24.29PAGE: 83LINE:COMMENT START:Typo.COMMENT END:SUGGESTED CHANGES START:In the second line of this paragraph, replace "even it has" with "even if ithas".SUGGESTED CHANGES END:

NAME: Les BellCOMMENT TYPE: TRCLAUSE: 13.24.29PAGE: 83LINE:COMMENT START:The use of the restrictedRole parameter needs further clarification in the casewhere all potential Root Ports have restrictedRole set. In this case, theBridge will itself become the Root Bridge and there is the possibility of a loopbeing 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 asAlternate Ports, effectively isolating this Bridge from the network to preventloops.SUGGESTED CHANGES END:

NAME: Les BellCOMMENT TYPE: ECLAUSE: 15.7PAGE: 91LINE:COMMENT START:The NOTE on this page should be numbered, as there are further NOTEs in thisclause, 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 BellCOMMENT TYPE: ECLAUSE: 15.8PAGE: 92LINE: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 BellCOMMENT TYPE: ECLAUSE: 16.5PAGE: 96LINE:COMMENT START:Typo.COMMENT END:SUGGESTED CHANGES START:In NOTE 3, second line, replace "addressed this standard" with "addressed bythis standard".SUGGESTED CHANGES END:

NAME: Les BellCOMMENT TYPE: ERCLAUSE: G.7PAGE: 108LINE:COMMENT START:The end of the first paragraph on this page introduces the Require Drop Encodingparameter. There is no explanation as to what this is, nor is it referencedanywhere else in the document.COMMENT END:SUGGESTED CHANGES START:Remove it.SUGGESTED CHANGES END:



__X__ I Disapprove (must attach binding comments below)_____ I Abstain for the following reasons (may attach non-binding commentsbelow):______ Lack of Time______ Lack of Expertise______ Other: _______________________________________________

__Jim Burns_____________(Name)___603-778-2315_______________(Telephone No.)------------------------------------------------------------------------

NAME: Jim BurnsCOMMENT TYPE: ECLAUSE: 8.6.3 - Table 8-1PAGE: 42LINE: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:


_____ 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 commentsbelow):______ Lack of Time______ Lack of Expertise______ Other: _______________________________________________

__John_Messenger_____________(Name)___+44-1904-692700_______________(Telephone No.)------------------------------------------------------------------------

NAME: John MessengerCOMMENT TYPE: TCLAUSE: 6.8PAGE: 27LINE: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:



_____ I Abstain for the following reasons (may attach non-binding commentsbelow):______ Lack of Time______ Lack of Expertise______ Other: _______________________________________________

___Muneyoshi Suzuki_________________________(Name)___+81-422-59-2119__________________________(Telephone No.)------------------------------------------------------------------------INCLUDE COMMENTS BELOW THIS POINT

NAME: Muneyoshi SuzukiCOMMENT TYPE: ERCLAUSE: allPAGE: allLINE: allCOMMENT 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 inclause 3, because neither OSI definition nor 802 architecture standarddoes not define it. Otherwise, terminology should be unified.SUGGESTED CHANGES END:

NAME: Muneyoshi SuzukiCOMMENT TYPE: TCLAUSE: 8.2PAGE: 33-34LINE:COMMENT START:Since new Bridge protocol architecture is introduced in Clause 6,VLAN-aware Bridge architecture addressed in this clause should alsobe consistent with Clause 6. However, relationships among MIF, MCF,and MSF defined in clause 6 and Port and 802.1X described in Clause8.2 are unclear.COMMENT END:SUGGESTED CHANGES START:Clarification is needed especially relationships among MIF, MCF andPort.SUGGESTED CHANGES END:

NAME: Muneyoshi SuzukiCOMMENT TYPE: ECLAUSE: 8.6.4PAGE: 43LINE: Table 8-1COMMENT START:01-80-C2-00-00-0E is taken by LLDP.COMMENT END:SUGGESTED CHANGES START:Update table.


NAME: Muneyoshi SuzukiCOMMENT TYPE: ECLAUSE: 9.7PAGE: 76LINE: Figure 9-1COMMENT START:Figure title "C-TAG" is a typo.COMMENT END:SUGGESTED CHANGES START:It is "S-TAG".SUGGESTED CHANGES END:

NAME: Muneyoshi SuzukiCOMMENT TYPE: TCLAUSE: 15.2PAGE: 88LINE: 17COMMENT START:"Customer instance" is undefined terminology.COMMENT END:SUGGESTED CHANGES START:It should be defined in clause 3, because it is not defined inOSI or 802 architecture standard. Otherwise, replace plain wordsuch as "customers" instead.SUGGESTED CHANGES END:

NAME: Muneyoshi SuzukiCOMMENT TYPE: ECLAUSE: 15.4PAGE: 90LINE: 1COMMENT START:"CVLAN" is a typo.COMMENT END:SUGGESTED CHANGES START:It is "C-VLAN".SUGGESTED CHANGES END:

NAME: Muneyoshi SuzukiCOMMENT TYPE: TRCLAUSE: 15.4PAGE: 90LINE: 1-4COMMENT START:I'm not sure the reason why scheme addressed in this note is effectivefor loopsprevention.COMMENT END:SUGGESTED CHANGES START:Clarification is needed.SUGGESTED CHANGES END:

NAME: Muneyoshi SuzukiCOMMENT TYPE: ECLAUSE: 16.2PAGE: 94LINE: 9COMMENT START:")" in end of paragraph is a typo.COMMENT END:SUGGESTED CHANGES START:Remove it.SUGGESTED CHANGES END:

NAME: Muneyoshi SuzukiCOMMENT TYPE: ERCLAUSE: 16.2PAGE: 95LINE: 26-34COMMENT 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 ofC-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:


Remove all change bars, cross outs and underscore revision control markers.


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:


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


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:


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.


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:


Reorder the subclauses in clause 5 to match the ordering presented in 5.2 Also add the subclause 5.6 to f)


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:


Add instruction to the effect: Delete the existing contents of Clause 8, and insert replacement contents as shown below.


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:


Add references to all items in list e.g., a) frame reception (8.5)


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:


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.


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:


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'.



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:


Add references to all items in list e.g., f) maintenance ... (clause 12)

And rejoin the opening paragraph.



Referenced subclauses throughout clause are incorrect as a result of the additional text.

COMMENT END:


Fix references, e.g., In 16.2: 16.3 -> 16.6 In 16.4: 16.5 -> 16.3

And rejoin the opening paragraph.


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:


Include an relationship figure similar to Fig 7-1


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:


Remove all instances of 'architecture' in titles and text. Remove first paragraph.


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:


Include updated PICS based on amendment. Add a new table A.16 Provider Bridge support



9th November 2004

TO: Mick Seaman

Editor, P802.1ad

SUBJECT: [802.1] P802.1ad/D3 Ballot - Disapprove


__X__ I Disapprove (must attach binding comments below)


below):

______ Lack of Time


______ 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:


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"



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.


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:[email protected]]On Behalf Of Osama Aboul-MagdSent: Wednesday, November 10, 2004 3:44 PMTo: [email protected]: Re: [802.1] P802.1ad/D3 Ballot - Flow Metering Considerations

Hi Mick, Please see inline. Regards; Osama Aboul-MagdATI Strategic Standards and ProtocolsNortel NetworksP.O. Box 3511, Station COttawa, Ontario, CanadaK1Y-4H7Tel: +1 613 763 5827e.mail:[email protected]

-----Original Message-----From: Mick Seaman [mailto:[email protected]] Sent: Wednesday, November 10, 2004 2:55 PMTo: Aboul-Magd, Osama [CAR:1A11:EXCH]; [email protected]: 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.

MickNAME: Osama Aboul-MagdCOMMENT TYPE: TRCLAUSE: 8.6.4PAGE: 42LINE: 1COMMENT 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-MagdCOMMENT TYPE: TCLAUSE: 8.6.4PAGE: 42LINE: 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:


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:


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.



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:


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.



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:


Remove this paragraph. Add a statement that transmission scheduling is an implementation issue.



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:


Remove this item.



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:


I suggest the draft endorse differentiated service model, its definitions, and concepts like PHB, EF, AF, etc.

Remove this item.



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:


Remove this item.



_____ 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 commentsbelow):______ Lack of Time______ Lack of Expertise______ Other: _______________________________________________

Paul Bottorff (Name)408-495-3365 (Telephone No.)------------------------------------------------------------------------

NAME: Paul BottorffCOMMENT TYPE: TCLAUSE: 5.9PAGE: 15LINE: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 BottorffCOMMENT TYPE: TCLAUSE: 8.6.4PAGE: 42LINE: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 non-eligible. 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 BottorffCOMMENT TYPE: TCLAUSE: 8.6.4PAGE: 42LINE: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 BottorffCOMMENT TYPE: TCLAUSE: 8.6.4PAGE: 42LINE: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 BottorffCOMMENT TYPE: TCLAUSE: 12PAGE: 81LINE: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 BottorffCOMMENT TYPE: TCLAUSE: 15.4PAGE: 89LINE: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:


9th November 2004

TO: Mick Seaman

Editor, P802.1ad

SUBJECT: [802.1] P802.1ad/D3 Ballot - Disapprove



below):

______ Lack of Time


______ 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:


Change 6.4 and 6.5 to 6.6 and 6.7


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 IETF" as a "MIB Doctor" for the IEEE 802.1 WG.The purpose of this is to provide IETF-expert review of mib modules asthe responsibility for 802.1-related MIB modules is transitioned fromthe IETF Bridge-mib WG to the IEEE 802.1 WG.

As a newbie to IEEE process, I am not quite sure how I should respondto COMMENTS, but feel that my input might be helpful here.

It is important to distinguish the SMI, which is used to write MIBmodules, from SNMP, which is a protocol that is designed to carryobjects 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 needto be limited to SNMP, at least not for technical reasons. AnSMIv2-compliant mib module can be used by other protocols if desired.

Dan is correct about the current status of SNMP in the IETF, but Ithink the motivation is more important to consider. All SNMP versionsprior to SNMPv3 have been declared "Historic" by the IETF because theyall provide a level of security that is considered inadequate toaddress current threats to network management. SNMPv3 is therecommended version of SNMPv3 because it provides security deemedadequate to address current threats to network management.

David [email protected] IETF SNMPv3 WG, concludedCo-chair IETF Bridge-mib WG (concluding)IETF MIB Doctor

________________________________

From: IEEE 802.1 [mailto:[email protected]] On Behalf OfRomascanu, Dan (Dan) Sent: Tuesday, November 09, 2004 5:47 PM To: [email protected] Subject: Re: [802.1] P802.1ad/D3 Ballot - Disapprove

SNMPv3 is the IETF standard version of SNMP. The previousversions 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 BridgeManagement protocol, does the management protocol need to be limitedto SNMP? If interoperability is the desire, which version of SNMP is

to be recommended?

COMMENT END:


The text of clause 8.13 in 802.1Q-2003 can be retainedwith a note that SNMP is the recommended protocol in conjunction withthe MIBs. It would be also useful to indicate a preference for aspecific version SNMP e.g. SNMPv3



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


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:


Clause 11: remove 1st line

Clause 11.2.4 Line 1: Change "receives" to "received"


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:


Please state if this amendment makes any changes to Clause 11.3 and 11.4SUGGESTED 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:


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.


Dinesh


_____ 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-bindingcommentsbelow):______ Lack of Time______ Lack of Expertise______ Other: _______________________________________________

___Dirceu Cavendish_________________________(Name)___1-408-863-6041__________________________

(Telephone No.)------------------------------------------------------------------------INCLUDE COMMENTS BELOW THIS POINT

NAME: Dirceu CavendishCOMMENT TYPE: TRCLAUSE: allPAGE: allLINE: allCOMMENT START:The provider bridge model is "buried" in sec 15. Yet, its concepts andnomenclature (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 VERYhard to read. Worst of all, section 8 - principles of operation comeswith a bridge model (Fig. 8.2) that is not comprehensive enough toinclude 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 "bridgearchitecture". I suggest the selection of one of figures from clause 15,perhaps Fig. 15-4. Then, all concepts included in the model should belisted with their definitions in clause 3 - Definition.SUGGESTED CHANGES END:

NAME: Dirceu CavendishCOMMENT TYPE: TRCLAUSE: 6.10PAGE: 28LINE: allCOMMENT START:I don't remember any discussion about making room for "additionaltechnology" text. So I don't know what is the rational for the section.COMMENT END:SUGGESTED CHANGES START:Remove section 6.10SUGGESTED CHANGES END:

NAME: Dirceu CavendishCOMMENT TYPE: TRCLAUSE: 8.2PAGE: 33LINE: allCOMMENT 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 inthe following sub-sections (model of operation, etc...)SUGGESTED CHANGES END:

NAME: Dirceu CavendishCOMMENT TYPE: TRCLAUSE: 8.6PAGE: 40LINE: all

COMMENT START:COMMENT END:SUGGESTED CHANGES START:For consistency with subsequent subsection titles, replace "Ingress andVLAN 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 CavendishCOMMENT TYPE: TRCLAUSE: 9.7PAGE: 76LINE: allCOMMENT 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 beS-TAG TCI format.SUGGESTED CHANGES END:

NAME: Dirceu CavendishCOMMENT TYPE: TRCLAUSE: 9.7PAGE: 76LINE: allCOMMENT START:Given the widespread usage of QinQ solutions, QinQ frame format shouldbe reflected in more than a footnote...COMMENT END:SUGGESTED CHANGES START:SUGGESTED CHANGES END:

NAME: Dirceu CavendishCOMMENT TYPE: TRCLAUSE: 15.5PAGE: 90LINE: allCOMMENT 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 bridgeto "Customer controlled Provider EDGE Bridge."SUGGESTED CHANGES END:

NAME: Dirceu CavendishCOMMENT TYPE: TRCLAUSE: 15.6PAGE: 90LINE: allCOMMENT 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 serviceinstances supported by the provider bridge network can not be gauged. Asharp conceptual definition of customer, provider, and service must be

included.SUGGESTED CHANGES END:


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)


below):

______ Lack of Time


______ 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:[email protected]]Sent: Wednesday, November 10, 2004 7:23 AMTo: [email protected]: [802.1] P802.1ad/D3 Ballot - Abstain


9th November 2004TO: Mick SeamanEditor, P802.1adSUBJECT: <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-bindingcommentsbelow):_____ 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 BALLOT9th November 2004TO: Mick SeamanEditor, 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 commentsbelow):______ Lack of Time______ Lack of Expertise______ Other: _______________________________________________

__Mick_Seaman_____________(Name)___415-722-6843_______________(Telephone No.)------------------------------------------------------------------------

NAME: Mick SeamanCOMMENT TYPE: ECLAUSE:PAGE:LINE:COMMENT START:It's time to move this to the WG ballot cycle and put more of an onus oncommenters to provide text to meet their comments.COMMENT END:SUGGESTED CHANGES START:Issue next revision for WG ballot.SUGGESTED CHANGES END:

NAME: Mick SeamanCOMMENT TYPE: TCLAUSE: 8.9PAGE: 49LINE:COMMENT START:As the editor's note says the changes to allow wild cards in filteringentries are clearly required for operation at any scale. Actually they arereally 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 isno 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 SeamanCOMMENT TYPE: TCLAUSE: 8.6.1PAGE: 44

LINE:COMMENT START:The Enable Ingress Filtering control is not sufficient to enable theprovision of E-TREE services, as those require ingress control that isindependent of the Member Set - which is really an output member set. Thisis really a deficiency in basic .1Q capabilities, as shared VLANs to supportE-TREE like configurations or "private VLANs" are explicitly in .1Q. We havedone without the explicit ingress control in the past because of the sigleadministrative control assumption for most LANs. My preference would be, asthis 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 anoptional configurable Ingress Member Set parameter to .1ad Clause 8.6.1. IfEnable Ingress Filtering is set, the frames accepted on ingress will be theintersection of those admitted by this parameter and by the Member Set.SUGGESTED CHANGES END:

Documents

802grouper.ieee.org/groups/802/1/files/public/docs2004/ad-c… · Web view9th November 2004. TO: Mick Seaman. Editor, P802.1ad. SUBJECT: __XX___ I Approve (may

802grouper.ieee.org/groups/802/1/files/public/docs2004/ad-c… · Web view9th November 2004. TO: Mick Seaman. Editor, P802.1ad. SUBJECT: XX_ I Approve (may