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

Hi Pat,

We have finished to improve the draft in accordance with your comments.
Please let us know your comments for new version.
http://tools.ietf.org/html/draft-ietf-ipfix-data-link-layer-monitoring-02

We improved it about the several issues:

a) "2.2. Virtual Ethernet Technology Summary"
We improved subsection 2.2, and changed the title from "Data Center
Bridging Summary". It describes Edge Virtual Bridging and Bridge Port
Extension.

b) "2.3.  Multiple Path Ethernet Summary"
Removed it.

c) New  Information Elements "dot1qTagProtocolIdentification"

The reuse of dot1qVlanId for C-TAG, S-TAG, and B-TAG makes difficult to
recognize its semantic. Thus, we added dot1qTagProtocolIdentification
Information Elements. It indicates TAG type.

d) New Information Elements related to E-TAG in IEEE 802.1BR

In the old draft, there was no Information Element related to E-TAG used
in Port Extention. we added dot1brEChannelTag  and
dot1brEChannelPriority. Thanks to them, we can monitor VM-to-VM traffic
within emulated Extended Bridge.

Regards, Atsushi

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.
> 
> 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.
> 
> o   802.1BR only specifies Bridge Port Extension so only Figure B-4 shows a frame format specified in 802.1BR
> 
> 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.
> 
> *         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.
> 
> *         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.
> 
> *         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.
> 
> *         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.
> 
> Regards,
> Pat Thaler

-- 
KOBAYASHI ATSUSHI <[email protected]>

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