Re: [IPFIX] New WG Last Call for Linbk-layer Monitoring draft

Hi Nevil,

Thank you for your attention to my comments. The draft is improved but still could use some changes. 

2.2 The draft links VEPA and S-channels (the "c" is lower case) - they shouldn't be linked - they are separate capabilities. A host system could support or use VEPA without having S-channel capability or without having enabled that capability. It could also use S-channels without using VEPA.

IEEE 802.1Qbg specifies two kinds of Edge Relay (ER) - VEPA and VEB
	A VEPA is a bridge-like device on a host system that forwards all internal traffic to the adjacent Bridge and then distributes any traffic received from the adjacent EVB Bridge to the internal ports (usually VMs)

	A Virtual Edge Bridge (VEB) is a Bridge but since it is on a host, it is not required to support learning (because it may be configured with all internal addresses and can assume that any unknown address goes to its external port) and spanning tree (because it has only one external port and is always at an edge of the tree).

S-channels are virtual links between a host system and the EVB Bridge - this allows the EVB Bridge to treat the traffic in an S-channel as if it comes in on a separate port. For example, to apply port-based filtering rules to the traffic. In the host, an S-channel may be attached to a VEB or a VEPA (or directly to an internal port, but in the standard there is a rudimentary two-port ER there to at least enable inserting and removing C-VLAN tags). 

I don't recall saving compute resources being presented as a rationale when we were making the case for including it in 802.1Qbg. The VEPA still has to examine the received frames to distribute them to the correct VM(s). The VEPA advantages presented were the other ones you mention  - making all the VM to VM traffic visible to the EVB  Bridge so that it can be monitored and so the EVB Bridge can apply filtering to it - both because the EVB Bridge may more filtering capability and because it may be more trusted to do the filtering. 

One might use S-channels because one wants to use a VEB for some VMs and a VEPA for others, to have greater separation between the traffic in the channels - e.g. the EVB Bridge being able to treat the traffic as if it came in on separate ports.

The sentence: "Frame format used in S-channel is complied with S-TAG format" is awkward and an odd use of comply. Suggest "When S-channel is in use, frames on the link carry an S-tag to identify the S-channel. 

Since the S-tag is only use local to a single link to identify a virtual port, it isn't clear that link monitoring needs to monitor an S-tag used for this purpose.  It could monitor the traffic based on the virtual port. Note that the S-VID used for this case only has link local significance.

Regards,
Pat


-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf Of Nevil Brownlee
Sent: Monday, February 25, 2013 1:00 PM
To: IPFIX Working Group
Subject: [IPFIX] New WG Last Call for Linbk-layer Monitoring draft


Hi all:

We have a new version of this draft,
   draft-ietf-ipfix-data-link-layer-monitoring-02,  22 Feb 2013,
thanks very much to the authors.

This version has a lot of changes from the previous one, mostly
in response to feedback from our IEEE Liaison, so we need a new
WG Last Call.

That WGLC starts now, and will end on Wednesday, 13 March (the day
before the IPFIX meeting in Orlando).

Do please read the draft, and send your comments (even just "it
seems OK now") to the IPFIX list.

Cheers, Nevil

-- 
---------------------------------------------------------------------
  Nevil Brownlee                          Computer Science Department
  Phone: +64 9 373 7599 x88941             The University of Auckland
  FAX: +64 9 373 7453   Private Bag 92019, Auckland 1142, New Zealand
_______________________________________________
IPFIX mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/ipfix


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