Presentation is loading. Please wait.

Presentation is loading. Please wait.

Review of July 2013 Proposed Pars

Similar presentations


Presentation on theme: "Review of July 2013 Proposed Pars"— Presentation transcript:

1 802.11 Review of July 2013 Proposed Pars
doc.: IEEE /0789r2 July 2013 Review of July Proposed Pars Date: Authors: Jon Rosdahl, CSR Technology Inc. Jon Rosdahl, CSR Technology Inc.

2 July 2013 doc.: IEEE /0789r2 July 2013 Abstract Review of 802 WG PARS submitted for review during the July 2013 Session. Jon Rosdahl, CSR Technology Inc. Jon Rosdahl, CSR Technology Inc.

3 PARs under consideration
July 2013 doc.: IEEE /0789r2 July 2013 PARs under consideration July 1x-1x, 2013, Geneva, Switzerland 802.1Qcc - amendment for Stream Reservation Protocol (SRP), PAR and 5C 802.1Qcd - amendment for Application Virtual Local Area Networks (VLAN) Type, Length, Value (TLV), PAR and 5C 802.3br - amendment for Specification and Management Parameters for Interspersing Express Traffic, PAR and 5C recommended practice on Layer 2 Routing, PAR and 5C P PAR Extension Jon Rosdahl, CSR Technology Inc. Jon Rosdahl, CSR Technology Inc.

4 802.1Qcc July 2013 doc.: IEEE 802.11-13/0789r2 July 2013
PAR In general the PAR appears to be written by and for a community already knowledgeable in 802.1Q. However, one of the purposes of a PAR is to advertise the start of a new project to a broad community members can not read the PAR and determine the scope. Do you plan to issue a press release if the project is approved. How would you describe the project in a press release? In 5.2.b Change “amendment provides” to “amendment describes new” Change “and provide:’ to “which provides:” “Configurable SR (stream reservation) classes and streams “ wording is confusing. Can this be written more clearly? What is the current stream limit. What will the new limit be? What are the characteristics of the streams before and after Qcc? What types of layer three support do you plan to offer? 8.1 is empty. Could some of the 5C material be used to further explain the project? 5.2, 5.4 and 5.5 do not seem to describe the same project – please clarify. 5C Technical feasibility What is the AVnu Alliance and what is its relationship to 802.1Q? Did AVnu supply use cases or requirements that could be referenced/made available? What does C mean? “The technology re‐use, and other augmented methods are deemed proven for their reliability.” What assumptions are being made of and its ability to participate in SRP? Jon Rosdahl, CSR Technology Inc. Jon Rosdahl, CSR Technology Inc.

5 July 2013 802.1Qcd PAR Does IETF provide any similar VLAN tag? How does VLAN tag simplify management? In 5.2.b, the last scope sentence is actually a need statement and should be moved to C Slide 6 Please define the scope of “end stations” or provide some examples. The 5C alternately claims that Qcd will simplify network management and end station management – which is it? Jon Rosdahl, CSR Technology Inc.

6 July 2013 doc.: IEEE /0789r2 July 2013 PAR Section 1.2 Is this really a Recommended Practice or a Standard? Section 5.2 Change to “This standard defines a protocol that routes packets in a dynamically changing network (changes on the order of a minute time frame), with minimal impact to route handling. Section 5.4 What L3 mechanisms are to be considered? Section 8.1 Clarify the relationship between 15.4e and Are there any new functions being added by 15.10? Does use only features previously defined by 15.4e? Is for use only with 15.4 based networks? Should the project be called because this is a recommended practice (standard) for 15.4? 5C Jon Rosdahl, CSR Technology Inc. Jon Rosdahl, CSR Technology Inc.

7 July 2013 802.3br PAR 2.1 Change to: Standard for Ethernet Amendment Specification and Management Parameters for Interspersed Express Traffic. 5.2.b Clarify the scope regarding whether the project will add only Qos parameters or also a management protocol. 5.2.b Change “The scope of this project is to specify” to “This amendment specifies” Is there any dependency between 802.1Qbu and 802.3br? Please explain what “interspersed express traffic” is. Could the term be described in either 5.2 or 8.1? 5.5 the last sentence does not seem to be appropriate. 5.5 replace “, including but not limited to,” with “such as” 5.6 Delete “stakeholders included to date include but are not limited to:” 5C Distinct Identity (slide 5) What does close to zero delay on converged networks mean? Jon Rosdahl, CSR Technology Inc.

8 July 2013 extension PAR In 2 delete “and therefore an extension of the PAR is required” Insert in 2 an explanation of expected project timeline to justify a two year extension. Fix 3.5. What percentage of the Draft is stable: % (blank) 5C N/A Jon Rosdahl, CSR Technology Inc.

9 Response Summary July 2013 PAR Response Comments only Revised PAR
Revised 5c action 802.1Qcc P 5C ok where is revised PAR? 802.1Qcd PAR ok. 5C explanation OK still wish this was added to 5C 802.3br PAR ok, 5C ok PAR ok Jon Rosdahl, CSR Technology Inc.

10 Response to IEEE 802.11 comments on PAR for IEEE P802.1Qcc
July 2013 Response to IEEE comments on PAR for IEEE P802.1Qcc July 2013 Pat Thaler, IEEE DCB task group chair .

11 July 2013 802.1Qcc PAR In general the PAR appears to be written by and for a community already knowledgeable in 802.1Q. However, one of the purposes of a PAR is to advertise the start of a new project to a broad community members can not read the PAR and determine the scope. Do you plan to issue a press release if the project is approved. How would you describe the project in a press release? We have assumed that dealing with your specific comments will resolve this general comment. Jon Rosdahl, CSR Technology Inc.

12 July 2013 802.1Qcc (cont) In 5.2.b Change “amendment provides” to “amendment describes new” Accepted - change made. Change “and provide:’ to “which provides:” Accepted in principle – wording clarified. “Configurable SR (stream reservation) classes and streams “ wording is confusing. Can this be written more clearly? Accepted – wording improved (in our opinion). What is the current stream limit. What will the new limit be? Accepted. The wording has clarified this. What are the characteristics of the streams before and after Qcc? Accepted. Wording improved. Jon Rosdahl, CSR Technology Inc.

13 July 2013 802.1Qcc (cont) What types of layer three support do you plan to offer? Accepted. Wording improved. 8.1 is empty. Could some of the 5C material be used to further explain the project? Accepted. A pointer to the 5C wil be included in , 5.4 and 5.5 do not seem to describe the same project – please clarify. 5.2 and 5.5 are introduced by this project and are mutually consistent; 5.4 is the Purpose as it appears in the current base document (802.1Q) and as it will appear in the rolled-up document (802.1Q plus this and other amendments). This amendment is consistent with the purpose as described. Jon Rosdahl, CSR Technology Inc.

14 July 2013 802.1Qcc (cont) 5C - Technical feasibility What is the AVnu Alliance and what is its relationship to 802.1Q? Accepted. Clarification included. Did AVnu supply use cases or requirements that could be referenced/made available? No. What does C mean? “The technology re‐use, and other augmented methods are deemed proven for their reliability.” Accepted. Wording improved. What assumptions are being made of and its ability to participate in SRP? This amendment makes no assumptions regarding Jon Rosdahl, CSR Technology Inc.

15 Response to IEEE 802.11 comments on PAR for IEEE P802.1Qcd
July 2013 Response to IEEE comments on PAR for IEEE P802.1Qcd July 2013 Pat Thaler, IEEE DCB task group chair .

16 July 2013 802.1Qcd PAR Does IETF provide any similar VLAN tag? No, VLAN tags are defined in IEEE 802.1Q and was fundamental to the initial IEEE 802.1Q. VLAN tags carry QoS information (i.e. priority) and VLAN IDs. How does VLAN tag simplify management? The VLAN ID is used to mark traffic as belonging to a Virtual LAN. This amendment simplifies management of end stations (i.e. devices that create and are the destination of traffic, rather than bridging the traffic) by providing a means for the adjacent bridge to tell the end station what VLAN ID to use for a particular application. We already have a similar TLV that indicates the priority to use for a particular application. See IEEE 802.1Q Annex D (currently published in IEEE 802.1Qaz). In 5.2.b, the last scope sentence is actually a need statement and should be moved to 5.5. Accept, we will move that sentence to the start of 5.5 Pat Thaler, IEEE DCB task group chair .

17 July 2013 802.1Qcd continued 5C Slide 6 Please define the scope of “end stations” or provide some examples. This term is defined in IEEE 802 and used in IEEE 802.1Q. The 5C alternately claims that Qcd will simplify network management and end station management – which is it? It doesn’t say that it simplifies network management – it says management of such networks. The network includes the end station network interfaces and the bridges, even though the term “network management” often is used in industry meaning just management of bridges. Typically, different administrators and management applications are involved in managing end stations and bridges. This presents a challenge for coordinating end stations with the network to which they are attached. DCBX (part of IEEE 802.1Qaz) was created to address this by providing a way for the adjacent bridge to tell an end station things it needed to know about the network configuration. The Application VLAN ID TLV fills a gap in the information currently covered by DCBX. This simplifies end station management as well as management of the network as a whole. Pat Thaler, IEEE DCB task group chair

18 Response to IEEE 802.11 comments on PAR for IEEE P802.15.10
July 2013 Response to IEEE comments on PAR for IEEE P July 2013 Pat Thaler, IEEE DCB task group chair .

19 July 2013 doc.: IEEE /0789r2 July 2013 Attached are the updated PAR and 5C redlines for your reference reflecting the responses to comments circulated previously with one exception. The response to 6.1b has been changed to yes, at the further request of Bob Grow, as a courtesy and as early notice that the project will be reviewed by the RAC even though the proposed recommended practice is not changing the MAC addressing used in IEEE Std , therefore no changes to registration activity are anticipated. Additionally changes were made to the Title (2.1), Scope (5.2) and Explanatory Notes (8.1). In the 5C a change was made to Section 2. Jon Rosdahl, CSR Technology Inc. Jon Rosdahl, CSR Technology Inc.

20 Comments Received from 802.11
doc.: IEEE /0789r1 July 2013 Comments Received from PAR 1.2 Type of Document Is this really a Recommended Practice or a Standard? Yes, it is a recommended practice. A recommended practice is more appropriate to verify that this appropriately meets the market demands of 5.2 Scope Change to “This standard defines a protocol that routes packets in a dynamically changing network (changes on the order of a minute time frame), with minimal impact to route handling. Changed to “This recommended practice defines a protocol that routes packets in a dynamically changing network (changes on the order of a minute time frame), with minimal impact to route handling. 5.4 Purpose What L3 mechanisms are to be considered? The L3 mechanisms are described in IETF RFC4903 “Multilink Subnet Issues” Jon Rosdahl, CSR Technology Inc.

21 Comments Received from 802.11 (cont’d.)
doc.: IEEE /0789r1 July 2013 Comments Received from (cont’d.) PAR 8.1 Additional Explanatory Notes Clarify the relationship between 15.4e and e (MAC enhancements) is anticipated to facilitate Are there any new functions being added by 15.10? No functions are being added to IEEE 15.10 will have define IEEE behaviors for routing Does use only features previously defined by 15.4e? Yes Is for use only with 15.4 based networks? Should the project be called because this is a recommended practice (standard) for 15.4? While is a recommended practice for IEEE , it keeps a clear distinction between the standard and the recommended practice This also provides a capability to extend the recommended practice to other IEEE networks Jon Rosdahl, CSR Technology Inc.

22 Comments Received from Chair 802.19
doc.: IEEE /0789r1 July 2013 Comments Received from Chair PAR 2.1 Title Change “dynamically changing wireless networks” to “dynamically changing wireless personal area networks” Change to “dynamically changing IEEE networks” 5.2 Scope The scope says that this recommended practice “extends wireless networks.” It is not clear what is meant by “extend” in this phrase. Is the distance extended? Would the word “enhance” be a better word than “extend” in this scope? Change to ”extends the area of coverage of IEEE networks” When you say that the network is “dynamically changing” are you saying that the network connections are changing due to mobility? Yes, among other s (see below). Please explain what is meant by “dynamically changing networks” in Section 8.1, Additional Explanatory Notes. Add to 8.1: “Dynamically changing networks refer to network connections changing due to mobility, signal impairments, and the transient nature of networks” Jon Rosdahl, CSR Technology Inc.

23 Comments Received from Chair 802.19 (cont’d.)
doc.: IEEE /0789r1 July 2013 Comments Received from Chair (cont’d.) PAR 5.2 Scope We suggest changing “This recommended practice will facilitate the routing of packets …” to “This recommended practice will provide recommendations on the routing of packets …” Agree 5.5 Need for the Project Please add an explanation in Section 8.1 on what is a “Field Area Network” Add to 8.1: The Field Area Network (FAN) may provide a connectivity path from field Distribution Automation (DA) devices to the substation upstream, or connectivity that bypasses the Substations and links the field DA devices into a centralized management and control system. Jon Rosdahl, CSR Technology Inc.

24 Response to IEEE 802.11 comments on PAR for IEEE P802.3br
July 2013 Response to IEEE comments on PAR for IEEE P802.3br July 2013 < SG-1305-Winkel-PAR r2.pdf>. Pat Thaler, IEEE DCB task group chair .

25 July 2013 802.3br response PAR 2.1 Change to: Standard for Ethernet Amendment Specification and Management Parameters for Interspersed Express Traffic. Rejected: According to native speakers’ advice, the SG DMLT decided explicitly to use the verbal form INETERSPERSING in the title and in the scope to use “to add a support for INTERSPERSED express traffic.”! Rationale: the project will be describing how to intersperse express traffic. Jon Rosdahl, CSR Technology Inc.

26 July 2013 802.3br (cont) 5.2.b Clarify the scope regarding whether the project will add only Qos parameters or also a management protocol. Rejected: The Scope shall not include solutions. The objectives are giving boundaries for the Task Force. As said in the tutorial, more than one solution is possible, see T_SG_Tutorial_v04.pdf. IEEE already has a management protocol. There is no intent to change the management protocol. IEEE projects cover the QoS aspects. This project is to augment the data path capabilities of to support interspersing express traffic. As typically for the project will specify the management parameters for the new capability. The title of this Amendment mentions “… Management Parameters …”. Jon Rosdahl, CSR Technology Inc.

27 July 2013 802.3br (cont) 5.2.b Change “The scope of this project is to specify” to “This amendment specifies” Rejected: The wording is typical for IEEE PARs. The scope of an amendment will not be in included in the body of the amendment. Is there any dependency between 802.1Qbu and 802.3br? 􀀃Noted: No dependency for 802.3br known. This Amendment can be used by several projects. Please explain what “interspersed express traffic” is. Could the term be described in either 5.2 or 8.1? AiP: The tutorial provided an explanation, see LT_SG_Tutorial_v04.pdf. Any more detailed explanations would vary depending on the solution adopted. No further explanation in the PAR is appropriate. No changes needed. Jon Rosdahl, CSR Technology Inc.

28 802.3br 5.5 the last sentence does not seem to be appropriate.
July 2013 802.3br 5.5 the last sentence does not seem to be appropriate. Rejected: Because the alternative to interspersing express traffic would be to run express traffic on a separate physical link and this point out the need for the single physical link. 5.5 replace “, including but not limited to,” with “such as” Accepted 5.6 Delete “stakeholders included to date include but are not limited to:” 5C -- Distinct Identity (slide 5) What does close to zero delay on converged networks mean AiP: Delay substantially less than a max frame transmission time. See the tutorial for more explanations, see MLT_SG_Tutorial_v04.pdf. No changes needed.? Jon Rosdahl, CSR Technology Inc.

29 Response to IEEE 802.11 comments on PAR for IEEE P802.19.1
July 2013 Response to IEEE comments on PAR for IEEE P July 2013 Pat Thaler, IEEE DCB task group chair .

30 July 2013 response PAR In 2 delete “and therefore an extension of the PAR is required” Insert in 2 an explanation of expected project timeline to justify a two year extension. Fix 3.5. What percentage of the Draft is stable: % (blank) 5C - N/A response - We have updated the extension request 3.5. What percentage of the Draft is stable: 80% Jon Rosdahl, CSR Technology Inc.

31 July 2013 2. Why an Extension is Required: The draft passed working group letter ballot in November The first recirculation was run in May 2013, the second recirculation is planned for August 2013, and the third recirculation (if needed) is planned for October Initial Sponsor Ballot is planned for November with recirculation planned for March 2014 and final IEEE 802 executive committee approval in July The draft is expected to be submitted to RevCom in October If an additional working group or Sponsor Ballot recirculations are required, the completion of the draft standard could be delayed until the beginning of Therefore a 2 year extension is required. Jon Rosdahl, CSR Technology Inc.

32 July 2013 Cont Jon Rosdahl, CSR Technology Inc.


Download ppt "Review of July 2013 Proposed Pars"

Similar presentations


Ads by Google