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

From: Nevil Brownlee <[email-masked]>
Date: Tue, 26 Feb 2013 09:59:58 +1300

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

---

From: "Pat Thaler" <[email-masked]>
Date: Tue, 26 Feb 2013 02:25:22 +0000

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-masked] [mailto:[email-masked]] 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:

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-masked]
https://www.ietf.org/mailman/listinfo/ipfix

---

From: "Pat Thaler" <[email-masked]>
Date: Tue, 26 Feb 2013 02:29:06 +0000

In 3. The information elements TBD04 to TBD09 are not necessary for all of IEEE 802.1Q. Only a Provider Backbone Bridge  (PBB) would need these. A customer bridge knows nothing about I-Tags. 

I think that got lost when updating the reference from the PBB amendment to the IEEE 802.1Q revision that includes the material from the amendment.

Regards,
Pat

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 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:

Cheers, Nevil

---

From: "Pat Thaler" <[email-masked]>
Date: Tue, 26 Feb 2013 02:26:43 +0000

Hi Nevil,

My comments were not a formal IEEE Liaison. They were my comments as an experienced IEEE 802.1 participant.

I think the authors misunderstood my point regarding IEEE 802.1BR. The E-Tag and its fields should not be added to the Information Elements. An E-channels and E-Tags are internal to an Extended Bridge. All the traffic on the Extended Bridge goes through the Controlling Bridge. An E-channel is a virtual port on the Extended Bridge and traffic can be monitored by monitoring the virtual port. Port Extenders are not addressable from outside the Controlling Bridge. The Controlling Bridge has any management agents and controls the Port Extenders including collecting any statistics they gather on their ports. 

Any flows going through an Extended Bridge flows can be fully monitored by monitoring the same means as for any IEEE 802.1 Bridge. 

Therefore, TBD10 and TBD11 should be removed.

Regards,
Pat

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 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:

Cheers, Nevil