Re: [IPFIX] Fwd: WG Last Call for draft-ietf-ipfix-data-link-layer-monitoring-01

Hi Pat,

Thank you for detailed your review. Sorry for late reply.
I rewrote the parts related to 802.1Q-2011 incorporating IEEE 802.1ad
and 802.1ah. I have not yet rewrote the parts related to IEEE802.1Qbg
and IEEE802.1BR. Please see in-line.

On Wed, 19 Dec 2012 03:25:58 +0000
"Pat Thaler" <[email protected]> wrote:

> There are a number of items that should be corrected in this draft.
> 
> 
> *         The draft is out of date with respect to status of 802.1 and 802.3 standards. Please replace with current references.
> 
> o   The amendments IEEE 802.1ad and 802.1ah are not active standards as the material from them was incorporated into IEEE 802.1Q revisions. References to them should be changed to the current revision of 802.1Q
> 
> o   The current revision of 802.1Q is IEEE Std 802.1Q-2011.
> 
Ok, I will correct it.


> o   The current revision of 802.3 is IEEE Std 802.3-2012 (which has been approved and should be published shortly). It doesn't have a subclause 3.5. This was removed in the 2008 revision of 802.3 as the subclause just duplicated information from 802.1Q. 802.1Q should be used as the reference for fields such as VLAN ID and priority code point.
> 
Yes, I confirmed the clause 9 in IEEE 802.1Q-2011. The reference 802.3 will be removed.

> o   802.1BR only specifies Bridge Port Extension so only Figure B-4 shows a frame format specified in 802.1BR
> 
Yes, I will correct the title of Figure B-4.


> o   802.1Qbg Edge Virtual Bridging specifies use of an S-Tag to identify traffic belonging to S-Channels (i.e. a virtual link) on a physical link between an end station and the adjacent bridge so the formats in Figure B-1 and B-2 would apply to 802.1Qbg, not 802.1BR.
> 
Yes, I will correct the title of Figure B-1 and B-2.

> *         The frame formats for Edge Virtual Bridging and Port Extension apply only between the end node and adjacent bridge (for figures B-1 and B-2) or within an Extended Bridge (i.e. a controlling bridge plus its port extenders, figure B-3).  They are never used between bridges for those standards. The  Edge Virtual Bridge frame formats use the same tags as Provider Bridged frame formats (Figure A-3 and A-4). When the frames with that format are used between bridges it is provider bridging which is used in some data centers as well as in the WAN. It would be better to organize the frame format annexes as frame formats used between bridges and frame formats used for Edge Virtual Bridging between edge devices and their bridge and within an Extended Bridge.
> 
> *         2.2 Data Center Bridging - the content here seems confused. It isn't clear what the relevance of this summary is to the draft since information elements for the IEEE 802.1BR E-Tag have not been added. The E-Tag only appears between elements of an Extended Bridge and the Controlling Bridge has visibility of all the traffic in the Extended Bridge so it isn't clear to me that data link layer monitoring is relevant to it (any more than it would be to monitoring traffic between blades in a blade bridge). The C-Tag is used in Data Center Bridging the same way as in all 802.1Q bridging so that isn't a special case. The use of the S-Tag for Edge Virtual Bridging S-Channels only occurs on the link between an end station and its adjacent bridge. No additional elements are needed for thes
 e. The conclusion that Data Center Bridging complicates traffic measurement is not substantiated. Please remove 2.2 or if it is retained make it more clear and accurate.
> 
In current version, it does not describe the overview of Edge Virtual
Bridging and Bridge Port Extension. I will remove subsection 2.2.
However, I will add substitute subsection about IEEE802.1Qbg and
IEEE802.1BR. I am not specialist about Ethernet layer, it takes time
more than two weeks to learn more about IEEE802.1Qbg.


> *         2.3 Multiple Path Ethernet Summary - says "two solutions are discussed for standardization" implying that the standards haven't been finished. IEEE Std 802.1aq-2012 Shortest Path Bridging is an approved standard which was published in June.

I will rewrite as follows.

There are two solutions; one is Shortest Path Bridging [IEEE802.1aq],
the other is TRILL (Transparent Interconnection of Lots of Links)
[RFC6325].

> 
> *         2.4 VXLAN - The limit of the 12-bit VLAN ID is not the motivating factor for Network Virtualization Overlay (NVO3). If it was, the I-Tag which supports a 24-bit service identifier would suffice. A more significant motivator for the NVO3 is allowing for IP and MAC address isolation between the data center (which may be a layer 3 data center) and the tenant networks and between the tenant networks. The problem statement draft, draft-ietf-nvo3-overlay-problem-statement-01<http://datatracker.ietf.org/doc/draft-ietf-nvo3-overlay-problem-statement/>, provides a more complete description of the motivating factors. VXLAN is not the only proposed encapsulation for NVO3. It seems early to mention this topic as we haven't decided on which solutions to standardize. No information elements 
 have been added for it so 2.4 could be deleted. If it remains, it should point to the NVO3 work in general rather than a specific proposal.
> 
Ok, I will remove the subsection 2.4.


> *         5.1 and 5.2 - formally, there is no such thing as an 802.1ad frame or 802.1ah since 802.1ad and 802.1ah have been rolled into 802.1Q. You could use S-Tagged and B-Tagged frame.

Ok, I will use it.

Regards, Atsushi

> 
> Regards,
> Pat Thaler

-- 
KOBAYASHI ATSUSHI <[email protected]>

_______________________________________________
IPFIX mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipfix