Subject: [nvo3] A variety of 802.1Q definitions (Was - RE: WG Last Call for draft-ietf-nvo3-overlay-problem-statement-02)

From: Eric Gray <[email-masked]>
Date: Tue, 7 May 2013 18:33:30 +0000

Lothar, et al,

I would greatly appreciate it - if we want to continue this discussion - that we use a different subject line,
such as the one I've used in this mail.

The Last call was closed a while back and the comments have been addressed to the grudging satisfaction
of all of those who went to the trouble to make comments during the Last Call period.

As near as I can tell, this discussion is not about what should have been included in the draft, but is instead
a side-bar discussion on clarifying a variety of generic definitions having to do with Ethernet and/or IEEE
802.1Q terminology that is more than a little out of scope for any discussion having to do with the problem
statement...

--
Eric

From: Pat Thaler [mailto:[email-masked]]
Sent: Tuesday, May 07, 2013 2:04 PM
To: Reith, Lothar
Cc: Eric Gray; Janos Farkas; Thomas Narten; [email-masked]
Subject: RE: [nvo3] WG Last Call for draft-ietf-nvo3-overlay-problem-statement-02

Lothar,

The MSAP is the interface from the upper layers to the MAC.

The MSAP also appears on both sides of shim layers - for example Link Aggregation has an MSAP above and one or more MSAPs below it. IEEE 802.3 defines an optional MAC Control sublayer above the MAC with an MSAP above and below it.

The service interface defined for the MSAP in IEEE 802.1AC is the ISS (Internal Sublayer Service) and that name is used more than MSAP when referring to the service interface.  The interface of a VLAN aware component (for example between a VLAN-aware bridge relay and a port on that bridge) is an EISS, Enhanced ISS, which adds parameters such as priority, VLAN identifier and drop eligibility.

The interface North of the IEEE 802.2 LLC isn't given a short name in that standard - it is just the LLC sublayer service interface. IEEE 802 calls it LSAP.  IEEE 802.1Q uses LSAP the few times it is used (which are cases that talk about 802.2 LLC specifically). Since most often today, Ethertype is used instead of IEEE 802.2 (using the SNAP encapsulation if the native network is defined to use 802.2), the LLC is rather atrophied - it is just an Ethertype in the frame so only the MSAP interface is used.

IEEE 802 calls the service interface above the MAC PhSAP, but the revision in progress on that document changes that to PSAP. IEEE 802.3 calls that interface the Physical Signaling (PLS) service, but more often mentions the possible exposed interfaces between sublayers of the PHY, e.g. the MII (Media Independent Interface) and the older AUI (Attachment Unit Interface) and the interface to the actual media, the MDI (Medium Dependent Interface).

Pat

From: Reith, Lothar [mailto:[email-masked]]
Sent: Thursday, May 02, 2013 12:25 AM
To: Pat Thaler
Cc: Eric Gray; Janos Farkas; Thomas Narten; [email-masked]<mailto:[email-masked]>
Subject: Re: [nvo3] WG Last Call for draft-ietf-nvo3-overlay-problem-statement-02

Hi Pat,
Many thanks for pointing is to the MSAP!

Could you clarify The exact position of The MSAP?

- North of LLC ?
- North of MAC Layer and South of LLC?
 - South of MAC Layer?

and also thanks for pointing to The Short VLAN Definitionn,
Brause it Spears well aligned with MEF EVC and ITU-T
Definitions of a Flow Domain fragment.

Regards,   Lothar

Sent from my mobile device

Am 30.04.2013 um 23:41 schrieb "Pat Thaler" <[email-masked]<mailto:[email-masked]>>:
Hi Lothar,

Actually, if I'm following the thread correctly, the VLAN definition that used "end station" was from Thomas. Janos suggested a very brief definition of C-VLAN that references IEEE 802.1Q.

An end station or end station interface isn't "identified by a VLAN-ID". A C-VID identifies a virtual network. MAC address plus C-VID may identify an MSAP (MAC service access point). If the MAC address is globally scoped, the MAC address alone identifies the MSAP, but a MAC address may be a local address and only unique within a VLAN or set of VLANs and in that case it is the MAC address, C-VID pair that identifies the MSAP.

I agree with Janos that it would be best to use C-VLAN rather than VLANs when the document means C-VLAN and to reference IEEE 802.1Q for C-VLAN definition.

By the way, the short definition of a VLAN in IEEE 802.1Q-2011 is:
The closure of a set of MAC SAPs such that a data request in one MAC SAP in the set is
expected to result in a data indication in another MAC SAP in the set.

Regards,
Pat

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Reith, Lothar
Sent: Monday, April 29, 2013 1:02 PM
To: Eric Gray; Janos Farkas; Thomas Narten
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [nvo3] WG Last Call for draft-ietf-nvo3-overlay-problem-statement-02

Hi Eric,

your point should have been addressed to Janos, who came up with the VLAN definition.

I just wanted to point to the fact, that the term  "end station" may be ambiguous regarding the layer.

I realize that even when the VM is dual attached to the network via two end station interfaces (for example two VNICs bound to one MAC-Layer and one  L2-SAP interfacing upwards in the stack to one  layer 3 interface interfacing from the layer 3 layer network downwards in the stack towards the L2-SAP) the VLAN-ID still identifies the end station in the upward direction (from network to VM),however, in the  downward direction  from VM to network there would be one layer 3 interface interfacing with one L2-SAP that may be associated with two L1-interfaces of the dual attachment (two vNIC ports forming a LAG).

The reason for my comment was to be able to accommodate this situation of a dual attached VM, given that the application in the VM may initiate a LAG because the application is not aware that the NICs which it sees are not physical NICs but only virtual NICs.

Lothar

Von: Eric Gray [mailto:[email-masked]]
Gesendet: Montag, 29. April 2013 20:38
An: Reith, Lothar; Janos Farkas; Thomas Narten
Cc: [email-masked]<mailto:[email-masked]>
Betreff: RE: [nvo3] WG Last Call for draft-ietf-nvo3-overlay-problem-statement-02

Lothar,

                Your reply below appears to have missed the fact that this is a proposed definition for
"C-VLAN" - which is the specific type of VLAN that uses C-VIDs to identify individual VLANs.  It
is - I believe - essential that we are more precise in the use of this terminology as we do use
the term "VLAN" in several places to mean "VLAN as defined in IEEE 802.1Q-2011" (a much
bigger concept.

                If we are not clear in using the correct terms in the right places, then we will be making
technically incorrect assertions about various types of Virtual LANs in different parts of the draft.

--
Eric

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Reith, Lothar
Sent: Monday, April 29, 2013 5:15 AM
To: Janos Farkas; Thomas Narten
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [nvo3] WG Last Call for draft-ietf-nvo3-overlay-problem-statement-02

Please correct below definition as follows:

Please replace the term "end stations, (e.g. VMs) by "end station interfaces (e.g.,VNICs, which in turn are associated with VMs"

Resulting in the following:

  VLANs: An informal term used in this document to refer to IEEE

          802.1Q networks using C-VIDs (as defined in IEEE

          802.1Q-2011) at the network edge.  C-VIDs are generally

          associated with end station interfaces (e.g.,VNICs, which in turn are associated with VMs). Within an IEEE

          802.1Q-2011 network, other tags may be used as well, but

          such usage is generally transparent to the network edge.

Von: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] Im Auftrag von János Farkas
Gesendet: Montag, 29. April 2013 10:49
An: Thomas Narten
Cc: [email-masked]<mailto:[email-masked]>
Betreff: Re: [nvo3] WG Last Call for draft-ietf-nvo3-overlay-problem-statement-02

Hi Thomas,

Thank you for your feedback!

I'm only keeping items still under discussion in this mail in order to make it easier to read. (It is a quite long discussion.)
My current reply is in <JF> brackets.
I suggest a couple of further updates, which involve deletion/replacement of current text with new text.

Thomas Narten wrote:

<[email-masked]><mailto:[email-masked]> writes:

Overlay Virtual Network:  A Virtual Network in which the separation of

tenants is hidden from the underlying physical infrastructure. That is,

the underlying transport network does not need to know about tenancy

separation to correctly forward traffic. IEEE 802.1 Provider Backbone

Bridge (PBB) networks are an example for Overlay Virtual Networks. The

underlying transport network is provided by Backbone VLANs (B-VLAN)

implementing the forwarding based on B-MAC and B-VID, therefore, the

transport is unaware of the tenancy separation provided by an Overlay,

e.g. by the 24-bit I-SID Overlays.

How about:

 Overlay Virtual Network: A Virtual Network in which the separation of

 tenants is hidden from the underlying physical infrastructure. That

 is, the underlying transport network does not need to know about

 tenancy separation to correctly forward traffic. IEEE 802.1 Provider

 Backbone Bridging (PBB) is an example of an L2 Overlay Network. PBB

 uses MAC-in-MAC encapsulation and the underlying transport network

 forwards traffic using only the B-MAC and B-VID in the outer header.

 The underlay transport network is unaware of the tenancy separation

 provided by, for example, a 24-bit I-SID.

<JF>
Looks good.
A minor comment: "I-SID overlays" is more accurate, because multiple groups of entities may be separated from each other. Thus, the end of the paragraph should look like: "for example, 24-bit I-SID overlays."
<JF>

The bullet defining VLANs should either be deleted, or should refer to

IEEE 802.1Q-2011 as the most up-to-date authoritative definition of the

term.

How about:

   VLANs: An informal term used in this document to refer to IEEE

          802.1Q networks using C-VIDs (as defined in IEEE

          802.1Q-2011) at the network edge.  C-VIDs are generally

          associated with end stations (e.g., VMs). Within an IEEE

          802.1Q-2011 network, other tags may be used as well, but

          such usage is generally transparent to the network edge.

<JF>
I still think that there is no need to have text in Section 2 for explaining VLANs. Section 5.3 provides a more detailed description, which I think is enough for this document. I think the best would be just to refer to Section 5.3 at the first occurrence of VLAN in the document; and do not add any explanation to Section 2.

If I understand it right, then your intention with the VLAN bullet in Section 2 is to explain that the term "VLAN" means "C-VLAN" in the core of the document (Sections 3 and 4). In order to achieve that, I think it would be much cleaner to use "C-VLAN" instead of "VLAN" in Sections 3 and 4, which would make it explicit thus avoid any ambiguity. Referring to Section 5.3 at the first occurrence of C-VLAN would then guide the reader to get more information on VLANs.

However, if you really want to have a VLAN bullet in Section 2, then it has to be clear and unambiguous and it should in fact be a C-VLAN bullet for the above reasons. I'm making a try to help you on that if you really want to go for it:
"C-VLAN: This document refers to C-VLAN as implemented by many routers, i.e. a L2 virtual network identified by a C-VID. Section 5.3 provides more details on VLANs defined by [802.1Q]."

Anyway, I highly recommend replacing "VLAN" and "L2 VLAN" with "C-VLAN" in the following places:
1) Section 3.2, last paragraph: replace "the VLAN configured" with "the C-VLAN configured"
2) Section 3.4, last paragraph: replace "underlying L2 VLAN" with "underlying C-VLAN"
3) Section 4.1, 10th paragraph (starting with "A key aspect of overlays"): replace "the L2 VLAN scope" with "the C-VLAN scope"
<JF>

Please remove:

"In networks using VLANs, moving servers elsewhere in the network may

require expanding the scope of the VLAN beyond its original boundaries.

While this can be done, it requires potentially complex network

configuration changes and can conflict with the desire to bound the size

of broadcast domains, especially in larger data centers.  In addition,

when VMs migrate, the physical network (e.g., access lists) may need to

be reconfigured which can be time consuming and error prone."

If you want to keep it then it should be made generic as it inherently

is a generic problem. If a server is a member of a (virtual) network,

and the server is then moved to another location then the new location

has to be configured as part of the (virtual) network the server is

member of. A generalized version might look like e.g.:

"Moving servers elsewhere in a network may require expanding the scope

of the network beyond its original boundaries.  While this can be done,

it requires potentially complex network configuration changes. The

configuration burden would increase, when VMs migrate, which can be time

consuming and error prone."

I think we should leave the L2 text in. This is a real issue in DC

networks today. IMO, the text is more clear when using VLANs as an

example. (More below.)

<JF>
If you want to have text on the network expansion problem, then you should
replace
"In networks using VLANs, moving servers elsewhere in the network may require expanding the scope of the VLAN beyond its original boundaries. While this can be done, it requires potentially complex network configuration changes and can conflict with the desire to bound the size of broadcast domains, especially in larger data centers."
with
"In networks of many types (e.g. - IP subnets, MPLS VPNs, VLANs) moving servers may require expanding the scope of a portion of the network (subnet, VPN, VLAN) beyond its original boundaries. While this can be done, it requires potentially complex network configuration changes and may (in some cases - e.g. - a VLAN or L2VPN) conflict with a desire to bound the size of broadcast domains."

My point is that expanding a (virtual) network is a generic networking problem, therefore, should not be made as if it was only the attribute of VLANs. The generic problem is definitely there in any network if one does not use protocols designed to solve the problem. If you want to keep the text and do not want to generalize it along my suggestion in the previous mail, then you should add further examples to make it correct. IP is definitely used in data centers, so it should be there. MPLS should be there too as it was at least proposed to be used (see e.g." http://tools.ietf.org/id/draft-sajassi-nvo3-evpn-overlay-01.txt).
/Note that I suggested VLAN instead of C-VLAN here because it is about networking in general. It is also valid for C-VLAN, so you may use that instead if you prefer./

I would delete "especially in larger data centers" because it has no added value.

I'd make a separate paragraph out of it starting with "In networks of many types ..."
<JF>

As it was pointed out before, the L2 protocols are just there for it,

everything is provided by the protocols and fully automatic.

I disagree with this. (More below.)

VDP provides all the information associated with VM migration, based

on which the virtual overlay(s) the VM is member of can be expanded

automatically at Network Virtual Edges.

VDP is barely deployed today. There are few products supporting VDP

and port profiles.  It is not accurate to imply that VDP solves this

problem today.

SPBM controlling the underlying PBB network also does its job

automatically, i.e. provides the connectivity for the overlay. This

should be described if the intention is to talk about L2.

Likewise, SPBM is also not widely deployed today. Indeed, I am aware

of very few SPBM shipping products. I think it is fair to say that

SPMB has not reached critical mass within industry. It is also unclear

to me when/if that will change. Consequently, I think it would be

misleading to suggest that VDP/SPBM is what people do today and that

they adequately solve the problem.

Hence, I do think we need to leave the above text in place with

references to L2

<JF>
See my point to the given text above.

I strongly disagree with your statements on VDP and SPBM because they adequately solve the problems they address.
However, as it does not seem directly affecting text in the draft we may just agree or disagree.
<JF>

Thanks again for your careful review!

You're welcome!

Best regards,
János

---

From: Eric Gray <[email-masked]>
Date: Tue, 7 May 2013 19:15:51 +0000

Pat pointed out to me off-line that this discussion covers an even broader range than Ethernet and IEEE
802.1Q.

It includes other areas from IEEE 802 as well.

This is correct, as anyone who reads the details of the thread below can easily see.  And it makes the
discussion even more off the topic of the Overlay Problem Statement than I had earlier indicated.

--
Eric

From: Eric Gray
Sent: Tuesday, May 07, 2013 2:33 PM
To: Reith, Lothar
Cc: Janos Farkas; Thomas Narten; [email-masked]; 'Pat Thaler'
Subject: A variety of 802.1Q definitions (Was - RE: [nvo3] WG Last Call for draft-ietf-nvo3-overlay-problem-statement-02)

Lothar, et al,

--
Eric

Lothar,

Pat

Hi Pat,

- North of LLC ?

Regards,   Lothar

Regards,
Pat

Hi Eric,

Lothar

Lothar,

--
Eric

Hi Thomas,

Thomas Narten wrote:

How about:

<JF>
Looks good.

term.

How about:

<JF>

Please remove:

example. (More below.)

<JF>

problem today.

references to L2

<JF>

You're welcome!

Best regards,
János