Subject: Re: [nvo3] NVO3 Terminology changes

From: Lizhong Jin <[email-masked]>
Date: Sat, 20 Apr 2013 01:05:24 +0800

Hi Larry,
I wonder if point C or D is feasible in implementation. In my
understanding, the TSI must be a virtual port which could be associated
with the special VN, and transmit/receive packets from tenant system (the
virtual port terminology is used in many switch chip). If we use one IP
address, we could not treat it as a virtual port. One simple example, if
packet with broadcast IP address received, will this packet be send to IP_a
and IP_b on the same vNIC?

I don't think we need to define such kind of detail for TSI. The TSI
definition is implementation related. I could define the TSI with a VLAN
(piont B in your figure), or define TSI with a priority queue within one
vNIC.

BTW, I like the name TSI, and remove NIC/vNIC/pNIC. pNIC is closely related
with data transfer between network and host stack, and it is usually a
controller without MAC&PHY. vNIC is a driver function or virtual
function(defined by SR-IOV). A TSI could also be a vNIC teaming interface
by teaming driver. So "interface" is a appropriate name to define a Tx/Rx
channel between tenant system and VN.

Regards
Lizhong

> ---------- Forwarded message ----------
> From: "Larry Kreeger (kreeger)" <[email-masked]>
> To: Qin Wu <[email-masked]>, Anoop Ghanwani <[email-masked]>,
> "Black, David" <[email-masked]>
> Cc: "[email-masked]" <[email-masked]>, "Reith, Lothar" <
> [email-masked]>
> Date: Wed, 17 Apr 2013 16:55:50 +0000
> Subject: Re: [nvo3] NVO3 Terminology changes
>  Hi Qin,
>
>  A VM is one possible implementation of a Tenant System. I have not seen
> anyone suggesting that a Tenant System get more granular than that.
>
>  Regarding what defines a TSI, someone could choose any branch in the
> tree below to define as the TSI.  I was assuming that the TSI would be at
> point A below in the tree.  However, point B would correspond the the VAP.
>  Pat had mentioned having the TSI at point D.  I think if we were to define
> the TSI to be either point C or point D, then it would depend on the
> service being given (L2 or L3).  I would prefer it to be at point A or B.
>
>           VNIC-+-VN-+-MAC-+-IP
>            ^  |    |     +-IP ...
>            |  |    |
>            |  |    +-MAC-+-IP
>            |  |          +-IP ...
>            |  |
>            |  +-VN-+-MAC-+-IP
>            |     ^ |     +-IP ...
>            |     | |
>            |     | +-MAC-+-IP
>            |     |    ^  +-IP ...
>            |     |    |     ^
>            |     |    |     |
>            A     B    C     D
>
>   - Larry
>
>

---

From: Anoop Ghanwani <[email-masked]>
Date: Fri, 19 Apr 2013 16:28:25 -0700

> and IP_b on the same vNIC?

We have those same issues with MAC address-based VLANs, and with
multinetted interfaces, but that doesn't stop people from using both of
those features.

Now whether or not we want to pursue these as a working group is a
different matter, but it's worthwhile to at least be aware of what's in and
what's not and to clearly document these somewhere.

Anoop

---

From: "Reith, Lothar" <[email-masked]>
Date: Sun, 21 Apr 2013 11:44:03 +0000

Given that the term TSI lead to a long discussion and perhaps even confusion, I like to offer some abstraction help.

 Please consider any network can be drawn as a graph with vertices and points representing the endpoints of the vertices.

Agreed?

If you agree, please consider which of the 3 options the TSI represents:

a)      The point in the tenant system that interfaces towards the network

b)      The point in the network that interfaces towards the tenant system

c)       The vertice that connects 2 points (one in the network that is closest to the tenant system and one in the tenant system that is closest to the network)

Do all agree that it is b)  ?

If yes, do you agree that we may be better of in renaming Tenant System Interface as  "Overlay network interface"?

Or did I get something totally wrong?

Lothar
Von: [email-masked] [mailto:[email-masked]] Im Auftrag von Lizhong Jin
Gesendet: Freitag, 19. April 2013 19:05
An: [email-masked]; Lawrence Kreeger
Betreff: Re: [nvo3] NVO3 Terminology changes

Hi Larry,
I wonder if point C or D is feasible in implementation. In my understanding, the TSI must be a virtual port which could be associated with the special VN, and transmit/receive packets from tenant system (the virtual port terminology is used in many switch chip). If we use one IP address, we could not treat it as a virtual port. One simple example, if packet with broadcast IP address received, will this packet be send to IP_a and IP_b on the same vNIC?

I don't think we need to define such kind of detail for TSI. The TSI definition is implementation related. I could define the TSI with a VLAN (piont B in your figure), or define TSI with a priority queue within one vNIC.

BTW, I like the name TSI, and remove NIC/vNIC/pNIC. pNIC is closely related with data transfer between network and host stack, and it is usually a controller without MAC&PHY. vNIC is a driver function or virtual function(defined by SR-IOV). A TSI could also be a vNIC teaming interface by teaming driver. So "interface" is a appropriate name to define a Tx/Rx channel between tenant system and VN.

Regards
Lizhong

---------- Forwarded message ----------
From: "Larry Kreeger (kreeger)" <[email-masked]<mailto:[email-masked]>>
To: Qin Wu <[email-masked]<mailto:[email-masked]>>, Anoop Ghanwani <[email-masked]<mailto:[email-masked]>>, "Black, David" <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "Reith, Lothar" <[email-masked]<mailto:[email-masked]>>
Date: Wed, 17 Apr 2013 16:55:50 +0000
Subject: Re: [nvo3] NVO3 Terminology changes
Hi Qin,

A VM is one possible implementation of a Tenant System. I have not seen anyone suggesting that a Tenant System get more granular than that.

Regarding what defines a TSI, someone could choose any branch in the tree below to define as the TSI.  I was assuming that the TSI would be at point A below in the tree.  However, point B would correspond the the VAP.  Pat had mentioned having the TSI at point D.  I think if we were to define the TSI to be either point C or point D, then it would depend on the service being given (L2 or L3).  I would prefer it to be at point A or B.

         VNIC-+-VN-+-MAC-+-IP
           ^  |    |     +-IP ...
           |  |    |
           |  |    +-MAC-+-IP
           |  |          +-IP ...
           |  |
           |  +-VN-+-MAC-+-IP
           |     ^ |     +-IP ...
           |     | |
           |     | +-MAC-+-IP
           |     |    ^  +-IP ...
           |     |    |     ^
           |     |    |     |
           A     B    C     D

 - Larry

---

From: "Florian Mahr" <[email-masked]>
Date: Sun, 21 Apr 2013 20:33:39 +0200

Hi Lothar,

I agree with you that the discussion that is going on about the term TSI
is a little bit confusing.

In my opinion, it is best to think about the TSI in regard to the
containment tree proposed in draft-kreeger-nvo3-hypervisor-nve-cp-01.

In its simplest case the containment tree might look like this: TSI --
VN -- MAC -- IP.

Therefore, a TSI is nothing more than a conceptual interface which
connects a Tenant System (TS) to a Virtual Network Instance (VNI).

I personally like the new term TSI more than the old one (VNIC), because
it does not make any assumption about the implementation of the
interface,

i.e. the TSI can be for example a logical NIC or a physical NIC, and it
can be VLAN-tagged or untagged.

If I understand the current NVE reference model correctly, there is a
one-to-one relationship between the TSI on the TS side and the VAP on

the NVE side, i.e. each TSI is logically associated with exactly one
VAP.

I do not think it is a good idea to call the TSI an "Overlay network
interface", because the TSI is not directly involved in creating the
overlay

network. This is the job of the NVE which conceptually consists of one
or more VNIs and the Overlay Module.

Thanks,

Florian

>>> "Reith, Lothar" <[email-masked]> 21.04.13 13.44 Uhr >>>

Given that the term TSI lead to a long discussion and perhaps even
confusion, I like to offer some abstraction help.

 Please consider any network can be drawn as a graph with vertices and
points representing the endpoints of the vertices.

Agreed?

a)      The point in the tenant system that interfaces towards the
network

b)      The point in the network that interfaces towards the tenant
system

c)       The vertice that connects 2 points (one in the network that is
closest to the tenant system and one in the tenant system that is
closest to the network)

If yes, do you agree that we may be better of in renaming Tenant System
Interface as  “Overlay network interface”?

Lothar

Von: [email-masked] [mailto:[email-masked]] Im Auftrag von
Lizhong Jin
Gesendet: Freitag, 19. April 2013 19:05
An: [email-masked]; Lawrence Kreeger
Betreff: Re: [nvo3] NVO3 Terminology changes

Hi Larry,

I wonder if point C or D is feasible in implementation. In my
understanding, the TSI must be a virtual port which could be associated
with the special VN, and transmit/receive packets from tenant system
(the virtual port terminology is used in many switch chip). If we use
one IP address, we could not treat it as a virtual port. One simple
example, if packet with broadcast IP address received, will this packet
be send to IP_a and IP_b on the same vNIC?

 

BTW, I like the name TSI, and remove NIC/vNIC/pNIC. pNIC is closely
related with data transfer between network and host stack, and it is
usually a controller without MAC&PHY. vNIC is a driver function or
virtual function(defined by SR-IOV). A TSI could also be a vNIC teaming
interface by teaming driver. So "interface" is a appropriate name to
define a Tx/Rx channel between tenant system and VN.

Regards

Lizhong

 

---------- Forwarded message ----------
From: "Larry Kreeger (kreeger)" <[email-masked]>
To: Qin Wu <[email-masked]>, Anoop Ghanwani <[email-masked]>,
"Black, David" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, "Reith, Lothar"
<[email-masked]>
Date: Wed, 17 Apr 2013 16:55:50 +0000
Subject: Re: [nvo3] NVO3 Terminology changes

Hi Qin,

Regarding what defines a TSI, someone could choose any branch in the
tree below to define as the TSI.  I was assuming that the TSI would be
at point A below in the tree.  However, point B would correspond the the
VAP.  Pat had mentioned having the TSI at point D.  I think if we were
to define the TSI to be either point C or point D, then it would depend
on the service being given (L2 or L3).  I would prefer it to be at point
A or B.

         VNIC-+-VN-+-MAC-+-IP

           ^  |    |     +-IP ...

           |  |    |

           |  |    +-MAC-+-IP

           |  |          +-IP ...

           |  |

           |  +-VN-+-MAC-+-IP

           |     ^ |     +-IP ...

           |     | |

           |     | +-MAC-+-IP

           |     |    ^  +-IP ...

           |     |    |     ^

           |     |    |     |

           A     B    C     D

 - Larry

---

From: "Reith, Lothar" <[email-masked]>
Date: Mon, 22 Apr 2013 08:07:15 +0000

Hi Florian,

thanks for this interpretation.

I now understand that I may indeed have been confused, and that the TSI is not b).

I am still not quite clear, if it’s a) or c) though.

For me, that is a very fundamental conceptual difference – like for Euklid the difference between a point and a line that looks like a point, because it is a collapsed line.

My take is, that you tend for a) – correct?  That means that the TSI corresponds to the VAP in a 1 to 1 relation (because they are 2 points connected to each other by said implicit point to point relation, which represents the vertice in the graph, however, the 2 points are the endpoints of a collapsed line, and the line (the vertice between the point “VAP” and the point “TSI”  is not present in the data model.

Is that what you are saying?

Lothar

Von: Florian Mahr [mailto:[email-masked]]
Gesendet: Sonntag, 21. April 2013 20:34
An: Reith, Lothar
Cc: [email-masked]
Betreff: Antw: Re: [nvo3] NVO3 Terminology changes

Hi Lothar,

I agree with you that the discussion that is going on about the term TSI is a little bit confusing.

In my opinion, it is best to think about the TSI in regard to the containment tree proposed in draft-kreeger-nvo3-hypervisor-nve-cp-01.
In its simplest case the containment tree might look like this: TSI -- VN -- MAC -- IP.
Therefore, a TSI is nothing more than a conceptual interface which connects a Tenant System (TS) to a Virtual Network Instance (VNI).
I personally like the new term TSI more than the old one (VNIC), because it does not make any assumption about the implementation of the interface,
i.e. the TSI can be for example a logical NIC or a physical NIC, and it can be VLAN-tagged or untagged.
If I understand the current NVE reference model correctly, there is a one-to-one relationship between the TSI on the TS side and the VAP on
the NVE side, i.e. each TSI is logically associated with exactly one VAP.

I do not think it is a good idea to call the TSI an "Overlay network interface", because the TSI is not directly involved in creating the overlay
network. This is the job of the NVE which conceptually consists of one or more VNIs and the Overlay Module.

Thanks,
Florian

Agreed?

If yes, do you agree that we may be better of in renaming Tenant System Interface as  “Overlay network interface”?

Lothar

Hi Larry,

Regards
Lizhong

---------- Forwarded message ----------
From: "Larry Kreeger (kreeger)" <[email-masked]<mailto:[email-masked]>>
To: Qin Wu <[email-masked]<mailto:[email-masked]>>, Anoop Ghanwani <[email-masked]<mailto:[email-masked]>>, "Black, David" <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "Reith, Lothar" <[email-masked]<mailto:[email-masked]>>
Date: Wed, 17 Apr 2013 16:55:50 +0000
Subject: Re: [nvo3] NVO3 Terminology changes
Hi Qin,

         VNIC-+-VN-+-MAC-+-IP
           ^  |    |     +-IP ...
           |  |    |
           |  |    +-MAC-+-IP
           |  |          +-IP ...
           |  |
           |  +-VN-+-MAC-+-IP
           |     ^ |     +-IP ...
           |     | |
           |     | +-MAC-+-IP
           |     |    ^  +-IP ...
           |     |    |     ^
           |     |    |     |
           A     B    C     D

 - Larry

---

From: "Reith, Lothar" <[email-masked]>
Date: Mon, 22 Apr 2013 08:35:32 +0000

Heureka,

I now know what the vertice is.

In the case where the TSI is the interface of a VM, it is a collapsed virtual yellow cable, the thing that Bob Metcalfe called “the Ether” in his original 40 year old drawing.

And both the VAP as well as the TSI are Interfaces to the “Ether”. And they are both of point nature.s

Is there any  other case in scope of NVO3, where the TSI is not an interface of a VM?

The current definition of Tenant System may have mislead me to believe so.

Lothar

Von: [email-masked] [mailto:[email-masked]] Im Auftrag von Reith, Lothar
Gesendet: Montag, 22. April 2013 10:07
An: Florian Mahr
Cc: [email-masked]
Betreff: Re: [nvo3] Antw: Re: NVO3 Terminology changes

Hi Florian,

Lothar

Hi Lothar,

Thanks,
Florian

Agreed?

Lothar

Hi Larry,

Regards
Lizhong

---------- Forwarded message ----------
From: "Larry Kreeger (kreeger)" <[email-masked]<mailto:[email-masked]>>
To: Qin Wu <[email-masked]<mailto:[email-masked]>>, Anoop Ghanwani <[email-masked]<mailto:[email-masked]>>, "Black, David" <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "Reith, Lothar" <[email-masked]<mailto:[email-masked]>>
Date: Wed, 17 Apr 2013 16:55:50 +0000
Subject: Re: [nvo3] NVO3 Terminology changes
Hi Qin,

         VNIC-+-VN-+-MAC-+-IP
           ^  |    |     +-IP ...
           |  |    |
           |  |    +-MAC-+-IP
           |  |          +-IP ...
           |  |
           |  +-VN-+-MAC-+-IP
           |     ^ |     +-IP ...
           |     | |
           |     | +-MAC-+-IP
           |     |    ^  +-IP ...
           |     |    |     ^
           |     |    |     |
           A     B    C     D

 - Larry

---

From: "Reith, Lothar" <[email-masked]>
Date: Mon, 22 Apr 2013 08:40:59 +0000

Sorry I screwed up the meaning of vertice.

In mathematical graph theory the vertices are the points that are connected by edges.

So what I meant to say is that I now know what the nature of the edge is, that connects the both vertices “VAP” and “TSI”. It is a collapse virtual yellow cable.

Apologies for the confusion.

Lothar

Von: Reith, Lothar
Gesendet: Montag, 22. April 2013 10:36
An: Reith, Lothar; Florian Mahr
Cc: [email-masked]
Betreff: AW: [nvo3] Antw: Re: NVO3 Terminology changes

Heureka,

Lothar

Hi Florian,

Lothar

Hi Lothar,

Thanks,
Florian

Agreed?

Lothar

Hi Larry,

Regards
Lizhong

---------- Forwarded message ----------
From: "Larry Kreeger (kreeger)" <[email-masked]<mailto:[email-masked]>>
To: Qin Wu <[email-masked]<mailto:[email-masked]>>, Anoop Ghanwani <[email-masked]<mailto:[email-masked]>>, "Black, David" <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "Reith, Lothar" <[email-masked]<mailto:[email-masked]>>
Date: Wed, 17 Apr 2013 16:55:50 +0000
Subject: Re: [nvo3] NVO3 Terminology changes
Hi Qin,

         VNIC-+-VN-+-MAC-+-IP
           ^  |    |     +-IP ...
           |  |    |
           |  |    +-MAC-+-IP
           |  |          +-IP ...
           |  |
           |  +-VN-+-MAC-+-IP
           |     ^ |     +-IP ...
           |     | |
           |     | +-MAC-+-IP
           |     |    ^  +-IP ...
           |     |    |     ^
           |     |    |     |
           A     B    C     D

 - Larry

---

From: Qin Wu <[email-masked]>
Date: Mon, 22 Apr 2013 09:29:14 +0000

I think both VAP and TSI are related to Access interface/link or attachment point of virtual network, TSI is corresponding to end host side while VAP is corresponding to network side.
Go to deeper or more granularity, we may have virtual access link and each virtual access link is corresponding to the pair of TSI and VAP and identified by VNID, and maybe other information like VLAN Tag. Such virtual link needs be mapped to different Physical access link between tenant system and NVE. TSI could have Identifier too.

Regards!
-Qin
From: [email-masked] [mailto:[email-masked]] On Behalf Of Reith, Lothar
Sent: Monday, April 22, 2013 4:41 PM
To: Reith, Lothar; Florian Mahr
Cc: [email-masked]
Subject: Re: [nvo3] Antw: Re: NVO3 Terminology changes

Lothar

Von: Reith, Lothar

Heureka,

Lothar

Hi Florian,

Lothar

Hi Lothar,

Thanks,
Florian

Agreed?

Lothar

Hi Larry,

Regards
Lizhong

---------- Forwarded message ----------
From: "Larry Kreeger (kreeger)" <[email-masked]<mailto:[email-masked]>>
To: Qin Wu <[email-masked]<mailto:[email-masked]>>, Anoop Ghanwani <[email-masked]<mailto:[email-masked]>>, "Black, David" <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "Reith, Lothar" <[email-masked]<mailto:[email-masked]>>
Date: Wed, 17 Apr 2013 16:55:50 +0000
Subject: Re: [nvo3] NVO3 Terminology changes
Hi Qin,

         VNIC-+-VN-+-MAC-+-IP
           ^  |    |     +-IP ...
           |  |    |
           |  |    +-MAC-+-IP
           |  |          +-IP ...
           |  |
           |  +-VN-+-MAC-+-IP
           |     ^ |     +-IP ...
           |     | |
           |     | +-MAC-+-IP
           |     |    ^  +-IP ...
           |     |    |     ^
           |     |    |     |
           A     B    C     D

 - Larry

---

From: "Reith, Lothar" <[email-masked]>
Date: Mon, 22 Apr 2013 10:03:03 +0000

Florian,

I would like to share some more thoughts regarding the virtual yellow cable, with the intend to get to a better definition and understanding of the terms “VAP” and  “TSI”, and how they are connected to each other.

Here is how I see the 40 years of relevant history related to the yellow cable and to NVO3:

It started with a yellow cable: a physical multipoint cable.

  1.  Bridge: creates one virtual-yellow cable from 2 physical yellow cables to overcome distance limit

  1.  Hub: creates one virtual yellow cable from multiple physical yellow cables to allow structured cabling, but collisions limit throughput
  2.  Multiport Bridge (also called Ethernet Switch): Allows to create multiple virtual yellow cables from groups of ports terminating physical point to point cables. No more collisions but  may drop frames.
  3.  IEEE802.1Q VLAN based Ethernet Switched networks: Allows to create upto 4K (4094) virtual yellow cables per network, one station (MAC-address) can be endpoint in upto 4K virtual yellow cables/networks/VLANs. But: Not suitable for provider as customer requires multiple VID himself.
  4.  IEEE Provider Bridges: “QinQ” type S-VLAN:  4K virtual yellow cables per provider independent of customer use of VLAN/virtual yellow cables
  5.  IEEE Backbone Provider Bridges: MAC in MAC with upto 16 Mio I-SIDs as virtual yellow cable ID.
  6.  VXLAN: IETF defined MAC in IP encapsulation with upto 16 Mio Segment-IDs as virtual yellow cable ID.
  7.  NVO3: IETF defined work in progress with the term virtual network refers either to a virtual layer2 network (virtual yellow cable), or to a virtual layer 3 network (a community of Layer 2 endpoints – i.e. interfaces to virtual yellow cables with associated layer 3 endpoint addresses).  Said layer3 endpoint addresses are not used for routing, only for endpoint identification in overlay networks and associated underlay network, where routing is done based on underlay IP-addresses.

Given above, it should be possible to improve the definition of TSI, by logically  inverting the definition you gave:

You stated (excerpt):

“containment tree might look like this: TSI -- VN -- MAC -- IP.”

Let me try to logically invert your definition as follows:

A TSI is an interface to a virtual yellow cable connecting the TSI with a VAP, with the following granularity:

1.       If an IP address is bound to a MAC address and said MAC address bound to a virtual yellow cable interface, then the TSI has the granularity of the IP. Please note that multiple IP addresses may be bound to the same MAC address.

2.       If a MAC address is  bound to the virtual yellow cable interface, then the TSI has the granularity of that MAC-address (like a normal station seeing only the frames destined to it and ignoring other frames)

3.       If in addition a conceptual “wildcard” MAC address is bound to the virtual yellow cable interface, then the TSI has the granularity of a VN (like a protocol analyzer looking at all frames arriving at the station or passing the station).
If we are talking about a container that includes all 3 interface granularity options  listed above, then we may call this a TSI as the underlying interface, which enables these options.

And please excuse my terrible mistake in the emails below where I have used the word vertice as if it meant edge, even though it refers to a point in graph theory.  So when you read below emails, please  replace the term “vertice” with the term “edge” or “line”, in order to make sense.

Von: Reith, Lothar
Gesendet: Montag, 22. April 2013 10:41
An: Reith, Lothar; Florian Mahr
Cc: [email-masked]
Betreff: AW: [nvo3] Antw: Re: NVO3 Terminology changes

Lothar

Von: Reith, Lothar

Heureka,

Lothar

Hi Florian,

Lothar

Hi Lothar,

Thanks,
Florian

Agreed?

Lothar

Hi Larry,

Regards
Lizhong

---------- Forwarded message ----------
From: "Larry Kreeger (kreeger)" <[email-masked]<mailto:[email-masked]>>
To: Qin Wu <[email-masked]<mailto:[email-masked]>>, Anoop Ghanwani <[email-masked]<mailto:[email-masked]>>, "Black, David" <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "Reith, Lothar" <[email-masked]<mailto:[email-masked]>>
Date: Wed, 17 Apr 2013 16:55:50 +0000
Subject: Re: [nvo3] NVO3 Terminology changes
Hi Qin,

         VNIC-+-VN-+-MAC-+-IP
           ^  |    |     +-IP ...
           |  |    |
           |  |    +-MAC-+-IP
           |  |          +-IP ...
           |  |
           |  +-VN-+-MAC-+-IP
           |     ^ |     +-IP ...
           |     | |
           |     | +-MAC-+-IP
           |     |    ^  +-IP ...
           |     |    |     ^
           |     |    |     |
           A     B    C     D

 - Larry

---

From: "Florian Mahr" <[email-masked]>
Date: Mon, 22 Apr 2013 17:08:48 +0200

Hi Lothar,

Please see my comment below marked as "FM".

Thanks,

Florian

>>> "Reith, Lothar" <[email-masked]> 22.04.13 10.36 Uhr >>>

>In the case where the TSI is the interface of a VM, it is a collapsed
virtual yellow cable, the thing that Bob Metcalfe called “the Ether” in
his original 40 >year old drawing.

>The current definition of Tenant System may have mislead me to believe
so.

FM> Yes, a VM is only one example of a Tenant System (TS). The TS can
also be a physical system like a physical server, router, switch,
firewall, load-balancer etc.

Reith, Lothar

Hi Florian,

I now understand that I may indeed have been confused, and that the TSI
is not b).

For me, that is a very fundamental conceptual difference – like for
Euklid the difference between a point and a line that looks like a
point, because it is a collapsed line.

My take is, that you tend for a) – correct?  That means that the TSI
corresponds to the VAP in a 1 to 1 relation (because they are 2 points
connected to each other by said implicit point to point relation, which
represents the vertice in the graph, however, the 2 points are the
endpoints of a collapsed line, and the line (the vertice between the
point “VAP” and the point “TSI”  is not present in the data model.

Lothar

 

 

Hi Lothar,

 

 

 

Thanks,

Florian

 

Agreed?

a)      The point in theclosest to the tenant system and one in the tenant system that is
closest to the network)

Lothar

 

Hi Larry,

 

 

 

Regards

Lizhong

 

---------- Forwarded message ----------
From: "Larry Kreeger (kreeger)" <[email-masked]>
To: Qin Wu <[email-masked]>, Anoop Ghanwani <[email-masked]>,

Hi Qin,

 

 

         VNIC-+-VN-+-MAC-+-IP

           ^  |    |     +-IP ...

           |  |    |

           |  |    +-MAC-+-IP

           |  |          +-IP ...

           |  |

           |  +-VN-+-MAC-+-IP

           |     ^ |     +-IP ...

           |     | |

           |     | +-MAC-+-IP

           |     |    ^  +-IP ...

           |     |    |     ^

           |     |    |     |

           A     B    C     D

 - Larry

---

From: David Allan I <[email-masked]>
Date: Mon, 22 Apr 2013 15:26:38 +0000

HI Lothar:

Some nits/clarifications with your definitions below...

What you call a bridge would be more accurately characterized as a 2-port relay or repeater, not a bridge. If it has demarcation functionality, (e.g. tag manipulation and OAM functionality)  MEF refers to it as a NID (network interface device). In any case a bridge does not need to have multiple classifications (e.g. dual port or multiport bridge...). A bridge is 2 or more ports, with two ports being a degenerate case with the actual needs possibly being satisfied by simpler classes of devices. (e.g. a 2 port relay or a repeater does not perform MAC learning).

An 802.1Q VLAN based network is more accurately characterized as up to unique 4096 sets of yellow cables each interconnected by a virtual Ethernet switch. All under a single administration.

A 802 provider bridged network is the same but with support for multiple VLAN and MAC administrations.

An 802.1ah or .1aq network extends the attributes of provider bridged networks to 16M sets of yellow cables each with its own virtual bridge, and multi-VLAN/MAC administration support.

These are rather key distinctions from the POV of accurate terminology and embodied concepts...

I hope this helps
Dave

________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of Reith, Lothar
Sent: Monday, April 22, 2013 3:03 AM
To: 'Florian Mahr'
Cc: [email-masked]'
Subject: Re: [nvo3] Antw: Re: NVO3 Terminology changes

Florian,

I would like to share some more thoughts regarding the virtual yellow cable, with the intend to get to a better definition and understanding of the terms "VAP" and  "TSI", and how they are connected to each other.

  1.  Hub: creates one virtual yellow cable from multiple physical yellow cables to allow structured cabling, but collisions limit throughput
  2.  Multiport Bridge (also called Ethernet Switch): Allows to create multiple virtual yellow cables from groups of ports terminating physical point to point cables. No more collisions but  may drop frames.
  3.  IEEE802.1Q VLAN based Ethernet Switched networks: Allows to create upto 4K (4094) virtual yellow cables per network, one station (MAC-address) can be endpoint in upto 4K virtual yellow cables/networks/VLANs. But: Not suitable for provider as customer requires multiple VID himself.
  4.  IEEE Provider Bridges: "QinQ" type S-VLAN:  4K virtual yellow cables per provider independent of customer use of VLAN/virtual yellow cables
  5.  IEEE Backbone Provider Bridges: MAC in MAC with upto 16 Mio I-SIDs as virtual yellow cable ID.
  6.  VXLAN: IETF defined MAC in IP encapsulation with upto 16 Mio Segment-IDs as virtual yellow cable ID.
  7.  NVO3: IETF defined work in progress with the term virtual network refers either to a virtual layer2 network (virtual yellow cable), or to a virtual layer 3 network (a community of Layer 2 endpoints - i.e. interfaces to virtual yellow cables with associated layer 3 endpoint addresses).  Said layer3 endpoint addresses are not used for routing, only for endpoint identification in overlay networks and associated underlay network, where routing is done based on underlay IP-addresses.

You stated (excerpt):

"containment tree might look like this: TSI -- VN -- MAC -- IP."

3.       If in addition a conceptual "wildcard" MAC address is bound to the virtual yellow cable interface, then the TSI has the granularity of a VN (like a protocol analyzer looking at all frames arriving at the station or passing the station).
If we are talking about a container that includes all 3 interface granularity options  listed above, then we may call this a TSI as the underlying interface, which enables these options.

And please excuse my terrible mistake in the emails below where I have used the word vertice as if it meant edge, even though it refers to a point in graph theory.  So when you read below emails, please  replace the term "vertice" with the term "edge" or "line", in order to make sense.

Von: Reith, Lothar

So what I meant to say is that I now know what the nature of the edge is, that connects the both vertices "VAP" and "TSI". It is a collapse virtual yellow cable.

Lothar

Von: Reith, Lothar

Heureka,

In the case where the TSI is the interface of a VM, it is a collapsed virtual yellow cable, the thing that Bob Metcalfe called "the Ether" in his original 40 year old drawing.

And both the VAP as well as the TSI are Interfaces to the "Ether". And they are both of point nature.s

Lothar

Hi Florian,

I am still not quite clear, if it's a) or c) though.

For me, that is a very fundamental conceptual difference - like for Euklid the difference between a point and a line that looks like a point, because it is a collapsed line.

My take is, that you tend for a) - correct?  That means that the TSI corresponds to the VAP in a 1 to 1 relation (because they are 2 points connected to each other by said implicit point to point relation, which represents the vertice in the graph, however, the 2 points are the endpoints of a collapsed line, and the line (the vertice between the point "VAP" and the point "TSI"  is not present in the data model.

Lothar

Hi Lothar,

Thanks,
Florian

Agreed?

Lothar

Hi Larry,

Regards
Lizhong

---------- Forwarded message ----------
From: "Larry Kreeger (kreeger)" <[email-masked]<mailto:[email-masked]>>
To: Qin Wu <[email-masked]<mailto:[email-masked]>>, Anoop Ghanwani <[email-masked]<mailto:[email-masked]>>, "Black, David" <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "Reith, Lothar" <[email-masked]<mailto:[email-masked]>>
Date: Wed, 17 Apr 2013 16:55:50 +0000
Subject: Re: [nvo3] NVO3 Terminology changes
Hi Qin,

         VNIC-+-VN-+-MAC-+-IP
           ^  |    |     +-IP ...
           |  |    |
           |  |    +-MAC-+-IP
           |  |          +-IP ...
           |  |
           |  +-VN-+-MAC-+-IP
           |     ^ |     +-IP ...
           |     | |
           |     | +-MAC-+-IP
           |     |    ^  +-IP ...
           |     |    |     ^
           |     |    |     |
           A     B    C     D

 - Larry

---

From: "Florian Mahr" <[email-masked]>
Date: Mon, 22 Apr 2013 18:10:23 +0200

Hi Lothar,

I do not really understand what you are trying to achieve by means of
your "virtual yellow cable".

What the connection between a TSI and a VAP looks like depends on the
kind of TS/TSI you have and where the VAP/NVE is located.

It can be a physical (Ethernet) link, a logical link, or a chain of
physical and logical links.

It might be helpful to think about the TSI as having two "sides", but
this is my personal interpretation:

One side of the TSI faces the TS and its operating system, and the other
side faces the network.

In my opinion, it is outside the scope of NVO3 what the TS facing side
looks like, because this normally

depends on the operating system the TS is running.

In regard to the VAP, I think of it as a physical or logical port on an
NVE which can be identified by means

of a physical or logical interface identifier, e.g. a physical or
logical port ID, a VLAN ID and so on. Inside

the NVE each VAP is associated with exactly one VNI.

Thanks,

Florian

>>> "Reith, Lothar" <[email-masked]> 22.04.13 12.03 Uhr >>>

Florian,

I would like to share some more thoughts regarding the virtual yellow
cable, with the intend to get to a better definition and understanding
of the terms “VAP” and  “TSI”, and how they are connected to each other.

Here is how I see the 40 years of relevant history related to the yellow
cable and to NVO3:

1. Bridge: creates one virtual-yellow cable from 2 physical yellow
cables to overcome distance limit 

1. Hub: creates one virtual yellow cable from multiple physical yellow
cables to allow structured cabling, but collisions limit throughput 

2. Multiport Bridge (also called Ethernet Switch): Allows to create
multiple virtual yellow cables from groups of ports terminating physical
point to point cables. No more collisions but  may drop frames. 

3. IEEE802.1Q VLAN based Ethernet Switched networks: Allows to create
upto 4K (4094) virtual yellow cables per network, one station
(MAC-address) can be endpoint in upto 4K virtual yellow
cables/networks/VLANs. But: Not suitable for provider as customer
requires multiple VID himself. 

4. IEEE Provider Bridges: “QinQ” type S-VLAN:  4K virtual yellow cables
per provider independent of customer use of VLAN/virtual yellow cables 

5. IEEE Backbone Provider Bridges: MAC in MAC with upto 16 Mio I-SIDs as
virtual yellow cable ID. 

6. VXLAN: IETF defined MAC in IP encapsulation with upto 16 Mio
Segment-IDs as virtual yellow cable ID. 

7. NVO3: IETF defined work in progress with the term virtual network
refers either to a virtual layer2 network (virtual yellow cable), or to
a virtual layer 3 network (a community of Layer 2 endpoints – i.e.
interfaces to virtual yellow cables with associated layer 3 endpoint
addresses).  Said layer3 endpoint addresses are not used for routing,
only for endpoint identification in overlay networks and associated
underlay network, where routing is done based on underlay IP-addresses. 

Given above, it should be possible to improve the definition of TSI, by
logically  inverting the definition you gave:

You stated (excerpt): 

A TSI is an interface to a virtual yellow cable connecting the TSI with
a VAP, with the following granularity:

1.       If an IP address is bound to a MAC address and said MAC address
bound to a virtual yellow cable interface, then the TSI has the
granularity of the IP. Please note that multiple IP addresses may be
bound to the same MAC address.

2.       If a MAC address is  bound to the virtual yellow cable
interface, then the TSI has the granularity of that MAC-address (like a
normal station seeing only the frames destined to it and ignoring other
frames)

3.       the virtual yellow cable interface, then the TSI has the granularity of
a VN (like a protocol analyzer looking at all frames arriving at the
station or passing the station).

If we are talking about a container that includes all 3 interface
granularity options  listed above, then we may call this a TSI as the
underlying interface, which enables these options.

And please excuse my terrible mistake in the emails below where I have
used the word vertice as if it meant edge, even though it refers to a
point in graph theory.  So when you read below emails, please  replace
the term “vertice” with the term “edge” or “line”, in order to make
sense.

Von: Reith, Lothar 

In mathematical graph theory the vertices are the points that are
connected by edges.

So what I meant to say is that I now know what the nature of the edge
is, that connects the both vertices “VAP” and “TSI”. It is a collapse
virtual yellow cable.

Lothar

Von: Reith, Lothar 

Heureka, 

In the case where the TSI is the interface of a VM, it is a collapsed
virtual yellow cable, the thing that Bob Metcalfe called “the Ether” in
his original 40 year old drawing.

And both the VAP as well as the TSI are Interfaces to the “Ether”. And
they are both of point nature.s

Is there any  other case in scope of NVO3, where the TSI is not an
interface of a VM?

The current definition of Tenant System may have mislead me to believe
so.

Lothar

 

Hi Florian,

Lothar

 

 

Hi Lothar,

 

i.e. the TSI can be for example a logical NIC or one-to-one relationship between the TSI on the TS side and the VAP on

 

 

Thanks,

Florian

 

Agreed?

Lothar

 

Hi Larry,

 

 

 

Regards

Lizhong

 

---------- Forwarded message ----------
From: "Larry Kreeger (kreeger)" <[email-masked]>
To: Qin Wu <[email-masked]>, Anoop Ghanwani <[email-masked]>,

Hi Qin,

 

 

         VNIC-+-VN-+-MAC-+-IP

           ^  |    |     +-IP ...

           |  |    |

           |  |    +-MAC-+-IP

           |  |          +-IP ...

           |  |

           |  +-VN-+-MAC-+-IP

 - Larry

---

From: "Reith, Lothar" <[email-masked]>
Date: Mon, 22 Apr 2013 19:45:55 +0000

Hi Dave,

Many thanks for your comment, really appreciated.

I have so much respect for your role over many years in multiple SDOs/standards defining organisations, that I almost do not dare to ask, if you are sure about the number 4096.

But I propose a compromise between 4096 and 4094: what about 4095?

Reason:
My view is that 12 bits provide 4096 values, but the highest and the lowest value have special meanings, therefore I deducted 2 from 4096 and counted 4094 virtual yellow cables.

I understand the highest value (all 12 bits 1) has some special meaning  (a broadcast frame tagged with a VLAN-ID all bits set to one should arrive at all stations in all VLANs).

I further understand that the lowest value (all 12 bits are 0) of the VLAN-Tag also has a special meaning, namely that it has only  local significance to a single layer 2 hop only  (to mark so called priority tagged frames that otherwise must be considered untagged, i.e. to get access to the PCP Priority Code Point in untagged networks).

So I count 4094 VLAN tagged "virtual yellow cables" and one untagged "virtual yellow cables" providing a maximum of 4095 virtual yellow cables.

Lothar

Von: David Allan I [mailto:[email-masked]]
Gesendet: Montag, 22. April 2013 17:27
An: Reith, Lothar; 'Florian Mahr'
Cc: [email-masked]'
Betreff: RE: [nvo3] Antw: Re: NVO3 Terminology changes

HI Lothar:

I hope this helps
Dave

You stated (excerpt):

Von: Reith, Lothar

Lothar

Von: Reith, Lothar

Heureka,

Lothar

Hi Florian,

Lothar

Hi Lothar,

Thanks,
Florian

Agreed?

Lothar

Hi Larry,

Regards
Lizhong

---------- Forwarded message ----------
From: "Larry Kreeger (kreeger)" <[email-masked]<mailto:[email-masked]>>
To: Qin Wu <[email-masked]<mailto:[email-masked]>>, Anoop Ghanwani <[email-masked]<mailto:[email-masked]>>, "Black, David" <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "Reith, Lothar" <[email-masked]<mailto:[email-masked]>>
Date: Wed, 17 Apr 2013 16:55:50 +0000
Subject: Re: [nvo3] NVO3 Terminology changes
Hi Qin,

         VNIC-+-VN-+-MAC-+-IP
           ^  |    |     +-IP ...
           |  |    |
           |  |    +-MAC-+-IP
           |  |          +-IP ...
           |  |
           |  +-VN-+-MAC-+-IP
           |     ^ |     +-IP ...
           |     | |
           |     | +-MAC-+-IP
           |     |    ^  +-IP ...
           |     |    |     ^
           |     |    |     |
           A     B    C     D

 - Larry

---

From: David Allan I <[email-masked]>
Date: Mon, 22 Apr 2013 20:38:44 +0000

hi Lothar:

Sorry for any confusion, referring to 4096 is my bad...

4094 is correct. 0x000 refers to a priority tagged frame. 0x0fff is reserved.

So 4094 is the correct VID count as to what is encoded in a 12 bit tag.

cheers
Dave

________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of Reith, Lothar
Sent: Monday, April 22, 2013 12:46 PM
To: David Allan I; 'Florian Mahr'
Cc: [email-masked]'
Subject: Re: [nvo3] Antw: Re: NVO3 Terminology changes

Hi Dave,

Reason:

Lothar

HI Lothar:

I hope this helps
Dave

You stated (excerpt):

Von: Reith, Lothar

Lothar

Von: Reith, Lothar

Heureka,

Lothar

Hi Florian,

Lothar

Hi Lothar,

Thanks,
Florian

Agreed?

Lothar

Hi Larry,

Regards
Lizhong

---------- Forwarded message ----------
From: "Larry Kreeger (kreeger)" <[email-masked]<mailto:[email-masked]>>
To: Qin Wu <[email-masked]<mailto:[email-masked]>>, Anoop Ghanwani <[email-masked]<mailto:[email-masked]>>, "Black, David" <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "Reith, Lothar" <[email-masked]<mailto:[email-masked]>>
Date: Wed, 17 Apr 2013 16:55:50 +0000
Subject: Re: [nvo3] NVO3 Terminology changes
Hi Qin,

         VNIC-+-VN-+-MAC-+-IP
           ^  |    |     +-IP ...
           |  |    |
           |  |    +-MAC-+-IP
           |  |          +-IP ...
           |  |
           |  +-VN-+-MAC-+-IP
           |     ^ |     +-IP ...
           |     | |
           |     | +-MAC-+-IP
           |     |    ^  +-IP ...
           |     |    |     ^
           |     |    |     |
           A     B    C     D

 - Larry

---

From: "Reith, Lothar" <[email-masked]>
Date: Mon, 22 Apr 2013 22:48:01 +0000

Hi Florian,

well, what I am trying to achieve?  I am trying to prevent damage.

1.       Damage with root cause “confused data model”

2.       Damage with root cause “standardization accident”.

3.       Damage to OSS IT systems, caused by wrong data models.

Trying to later fix a wrong data model (such as having to insert a forgotten object, which erroneously got modeled as attributes of other objects) may quickly become deterringly expensive, leading to workarounds in inter  IT-System interface adaptors, which further complicate the situation. At the end, the IT gets blamed for high cost, but the root cause may be poor definition of terms in the standards (or framework documents leading to standards).

For example, fixing a wrong modeling of an object “interface” can become very expensive, when there is a fundamental misconception involved in the design, such as:

1.       Is it a physical interface? Then it is always associated with a single location, e.g. where to send people for installation and troubleshooting.

2.       Is it a logical interface – then it may in future be associated with multiple locations, say when in future protected interface becomes a requirement, and thereby remain a single interface at 2 locations.

3.       Is it an interlayer thing, for example Layer 3 interface accessing a layer 2 service access point? And a layer2 Interface accessing a Layer1 service access point? And a layer1 service access point accessing a phycial medium that connects to the peer that is being faced by the physical interface.

4.       Is it network facing or customer (tenant) facing?

5.       Is it layer 1 or layer 2 or layer3 or a container for all layers?

6.       Is it a dual-sided object, that faces both the network and the customer (tenant)?

7.       Is it a vertex type object (modeled as vertex or node or point  in a mathematical graph theory graph representing the network, i.e. an object which may never have an attribute “distance”)?

8.       Is it an edge type object (modeled as edge between vertices in a mathematical graph, i.e. an object which may have an attribute “distance”)

The term tenant system Interface rang some of my personal alarm bells that multi million future IT dollars may be at risk, because depending on whom you ask, they may have a different understanding of the term interface. Not a very promising outlook for developing/enhancing a number of cooperating IT systems that SHOULD NOT soon get out of control because of overwhelming complexity introduced by “adaptors” fixing the different understandings of the nature of “interface”.

Lothar

Von: Florian Mahr [mailto:[email-masked]]
Gesendet: Montag, 22. April 2013 18:10
An: Reith, Lothar
Cc: [email-masked]
Betreff: Antw: AW: [nvo3] Antw: Re: NVO3 Terminology changes

Hi Lothar,

I do not really understand what you are trying to achieve by means of your "virtual yellow cable".
What the connection between a TSI and a VAP looks like depends on the kind of TS/TSI you have and where the VAP/NVE is located.
It can be a physical (Ethernet) link, a logical link, or a chain of physical and logical links.

It might be helpful to think about the TSI as having two "sides", but this is my personal interpretation:
One side of the TSI faces the TS and its operating system, and the other side faces the network.
In my opinion, it is outside the scope of NVO3 what the TS facing side looks like, because this normally
depends on the operating system the TS is running.

In regard to the VAP, I think of it as a physical or logical port on an NVE which can be identified by means
of a physical or logical interface identifier, e.g. a physical or logical port ID, a VLAN ID and so on. Inside
the NVE each VAP is associated with exactly one VNI.

Thanks,

Florian

Florian,

You stated (excerpt):

Von: Reith, Lothar

Lothar

Von: Reith, Lothar

Heureka,

Lothar

Hi Florian,

Lothar

Hi Lothar,

Thanks,
Florian

Agreed?

Lothar

Hi Larry,

Regards
Lizhong

---------- Forwarded message ----------
From: "Larry Kreeger (kreeger)" <[email-masked]<mailto:[email-masked]>>
To: Qin Wu <[email-masked]<mailto:[email-masked]>>, Anoop Ghanwani <[email-masked]<mailto:[email-masked]>>, "Black, David" <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "Reith, Lothar" <[email-masked]<mailto:[email-masked]>>
Date: Wed, 17 Apr 2013 16:55:50 +0000
Subject: Re: [nvo3] NVO3 Terminology changes
Hi Qin,

         VNIC-+-VN-+-MAC-+-IP
           ^  |    |     +-IP ...
           |  |    |
           |  |    +-MAC-+-IP
           |  |          +-IP ...
           |  |
           |  +-VN-+-MAC-+-IP
           |     ^ |     +-IP ...
           |     | |
           |     | +-MAC-+-IP
           |     |    ^  +-IP ...
           |     |    |     ^
           |     |    |     |
           A     B    C     D

 - Larry

---

From: "Florian Mahr" <[email-masked]>
Date: Tue, 23 Apr 2013 09:50:51 +0200

Hi Lothar,

It is quite early in the standardization process, and as you can see
when following the discussion,

the community is already trying to converge on a cleaner definition of
the term TSI. While several

people are contributing to this, it is quite normal that there are
different understandings of the term.

I am personally quite optimistic there will be consensus on what a TSI
is and how it is to be defined.

Since we are still talking about a work in progress, it might be a bad
idea to treat the model we

currently have as mandatory or a finalized standard.

Thanks,

Florian

>>> "Reith, Lothar" <[email-masked]> 23.04.13 0.48 Uhr >>>

Hi Florian,

Trying to later fix a wrong data model (such as having to insert a
forgotten object, which erroneously got modeled as attributes of other
objects) may quickly become deterringly expensive, leading to
workarounds in inter  IT-System interface adaptors, which further
complicate the situation. At the end, the IT gets blamed for high cost,
but the root cause may be poor definition of terms in the standards (or
framework documents leading to standards).

For example, fixing a wrong modeling of an object “interface” can become
very expensive, when there is a fundamental misconception involved in
the design, such as:

1.       Is it a physical interface? Then it is always associated with a
single location, e.g. where to send people for installation and
troubleshooting.

2.       Is it a logical interface – then it may in future be associated
with multiple locations, say when in future protected interface becomes
a requirement, and thereby remain a single interface at 2 locations.

3.       Is it an interlayer thing, for example Layer 3 interface
accessing a layer 2 service access point? And a layer2 Interface
accessing a Layer1 service access point? And a layer1 service access
point accessing a phycial medium that connects to the peer that is being
faced by the physical interface.

5.       Is it layer 1 or layer 2 or layer3 or a container for all
layers?

6.       Is it a dual-sided object, that faces both the network and the
customer (tenant)?

7.       Is it a vertex type object (modeled as vertex or node or point 
in a mathematical graph theory graph representing the network, i.e. an
object which may never have an attribute “distance”)? 

8.       Is it an edge type object (modeled as edge between vertices in
a mathematical graph, i.e. an object which may have an attribute
“distance”)

The term tenant system Interface rang some of my personal alarm bells
that multi million future IT dollars may be at risk, because depending
on whom you ask, they may have a different understanding of the term
interface. Not a very promising outlook for developing/enhancing a
number of cooperating IT systems that SHOULD NOT soon get out of control
because of overwhelming complexity introduced by “adaptors” fixing the
different understandings of the nature of “interface”.

Lothar

 

Hi Lothar,

 

It might be helpful One side of the TSI faces the TS and its operating system, and the other
side faces the network.

 

 

Thanks,

Florian

 

Florian,

 

You stated (excerpt): 

3.      If in addition a conceptual “wildcard” MAC address is bound to
the virtual yellow cable interface, then the TSI has the granularity of
a VN (like a protocol analyzer looking at all frames arriving at the
station or passing the station).

underlying interface, which enables thused the word vertice as if it meant edge, even though it refers to a

Von: Reith, Lothar 

Lothar

Von: Reith, Lothar 

Heureka, 

Lothar

 

Hi Florian,

Lothar

 

 

Hi Lothar,

 

 

network. This is the job of the NVE which conceptually consists of oGiven that the term TSI lead to a long discussion and perhaps even
confusion, I like to offer some abstraction help.

Agreed?

Lothar

 

Hi Larry,

 

 

 

Regards

Lizhong

 

---------- Forwarded message ----------
From: "Larry Kreeger (kreeger)" <[email-masked]>
To: Qin Wu <[email-masked]>, Anoop Ghanwani <[email-masked]>,

Hi Qin,

 

 

         VNIC-+-VN-+-MAC-+-IP

           ^  |    |     +-IP ...

           |  |    |

           |  |    +-MAC-+-IP

           |  |          +-IP ...

           |  |

           |  +-VN-+-MAC-+-IP

           |     ^ |     +-IP ...

           |     | |

           |     | +-MAC-+-IP

           |     |    ^  +-IP ...

           |     |    |     ^

           |     |    |     |

           A     B    C     D

 - Larry

---

From: Eric Gray <[email-masked]>
Date: Tue, 23 Apr 2013 16:54:55 +0000

This is why it is typically referred to as "4K" (which might not be either 4094 or 4096 but close
enough for discussion's sake).

How many people concern themselves with exactly how big a 1500 byte PDU is in any protocol
discussion?

Implementers mostly get it right, so we should rely on them to iron out the details and stick to
numbers that are approximately accurate for our purposes...

:)

From: [email-masked] [mailto:[email-masked]] On Behalf Of David Allan I
Sent: Monday, April 22, 2013 4:39 PM
To: Reith, Lothar; 'Florian Mahr'
Cc: [email-masked]'
Subject: Re: [nvo3] Antw: Re: NVO3 Terminology changes

hi Lothar:

cheers
Dave

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Reith, Lothar

Reason:

Lothar

HI Lothar:

I hope this helps
Dave

________________________________
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Reith, Lothar
Sent: Monday, April 22, 2013 3:03 AM
To: 'Florian Mahr'
Cc: [email-masked]'
Subject: Re: [nvo3] Antw: Re: NVO3 Terminology changes
Florian,

You stated (excerpt):

Von: Reith, Lothar
Gesendet: Montag, 22. April 2013 10:41
An: Reith, Lothar; Florian Mahr
Cc: [email-masked]<mailto:[email-masked]>
Betreff: AW: [nvo3] Antw: Re: NVO3 Terminology changes

Lothar

Von: Reith, Lothar
Gesendet: Montag, 22. April 2013 10:36
An: Reith, Lothar; Florian Mahr
Cc: [email-masked]<mailto:[email-masked]>
Betreff: AW: [nvo3] Antw: Re: NVO3 Terminology changes

Heureka,

Lothar

Von: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] Im Auftrag von Reith, Lothar
Gesendet: Montag, 22. April 2013 10:07
An: Florian Mahr
Cc: [email-masked]<mailto:[email-masked]>
Betreff: Re: [nvo3] Antw: Re: NVO3 Terminology changes

Hi Florian,

Lothar

Von: Florian Mahr [mailto:[email-masked]]
Gesendet: Sonntag, 21. April 2013 20:34
An: Reith, Lothar
Cc: [email-masked]<mailto:[email-masked]>
Betreff: Antw: Re: [nvo3] NVO3 Terminology changes

Hi Lothar,

Thanks,
Florian

>>> "Reith, Lothar" <[email-masked]<mailto:[email-masked]>> 21.04.13 13.44 Uhr >>>

Agreed?

Lothar
Von: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] Im Auftrag von Lizhong Jin
Gesendet: Freitag, 19. April 2013 19:05
An: [email-masked]<mailto:[email-masked]>; Lawrence Kreeger
Betreff: Re: [nvo3] NVO3 Terminology changes

Hi Larry,

Regards
Lizhong

---------- Forwarded message ----------
From: "Larry Kreeger (kreeger)" <[email-masked]<mailto:[email-masked]>>
To: Qin Wu <[email-masked]<mailto:[email-masked]>>, Anoop Ghanwani <[email-masked]<mailto:[email-masked]>>, "Black, David" <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "Reith, Lothar" <[email-masked]<mailto:[email-masked]>>
Date: Wed, 17 Apr 2013 16:55:50 +0000
Subject: Re: [nvo3] NVO3 Terminology changes
Hi Qin,

         VNIC-+-VN-+-MAC-+-IP
           ^  |    |     +-IP ...
           |  |    |
           |  |    +-MAC-+-IP
           |  |          +-IP ...
           |  |
           |  +-VN-+-MAC-+-IP
           |     ^ |     +-IP ...
           |     | |
           |     | +-MAC-+-IP
           |     |    ^  +-IP ...
           |     |    |     ^
           |     |    |     |
           A     B    C     D

 - Larry

---

From: "Pat Thaler" <[email-masked]>
Date: Tue, 23 Apr 2013 19:51:22 +0000

I agree that the number is 4094. There are a couple of more subtle points.
At a VLAN-aware port, untagged or priority-tagged traffic is not in a separate VLAN. It is in one of the 4094 VLANs - either it gets assigned a VLAN based on a classification rule (e.g. the Port and Protocol classification can assign a VLAN based on the Ethertype of the frame) or it is in the Port VLAN.

0x000 is the null value.

The 0xFFF value is not allowed to be sent in a VLAN tag. It isn't a way to broadcast something to all VLANs - there is no such provision because the VLANs are each separate. It may be used as a wildcard value in management operations and Filtering Database entries.

From: [email-masked] [mailto:[email-masked]] On Behalf Of David Allan I
Sent: Monday, April 22, 2013 1:39 PM
To: Reith, Lothar; 'Florian Mahr'
Cc: [email-masked]'
Subject: Re: [nvo3] Antw: Re: NVO3 Terminology changes

hi Lothar:

cheers
Dave

Reason:

Lothar

HI Lothar:

I hope this helps
Dave

You stated (excerpt):

Von: Reith, Lothar

Lothar

Von: Reith, Lothar

Heureka,

Lothar

Hi Florian,

Lothar

Hi Lothar,

Thanks,
Florian

Agreed?

Lothar

Hi Larry,

Regards
Lizhong

---------- Forwarded message ----------
From: "Larry Kreeger (kreeger)" <[email-masked]<mailto:[email-masked]>>
To: Qin Wu <[email-masked]<mailto:[email-masked]>>, Anoop Ghanwani <[email-masked]<mailto:[email-masked]>>, "Black, David" <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>, "Reith, Lothar" <[email-masked]<mailto:[email-masked]>>
Date: Wed, 17 Apr 2013 16:55:50 +0000
Subject: Re: [nvo3] NVO3 Terminology changes
Hi Qin,

         VNIC-+-VN-+-MAC-+-IP
           ^  |    |     +-IP ...
           |  |    |
           |  |    +-MAC-+-IP
           |  |          +-IP ...
           |  |
           |  +-VN-+-MAC-+-IP
           |     ^ |     +-IP ...
           |     | |
           |     | +-MAC-+-IP
           |     |    ^  +-IP ...
           |     |    |     ^
           |     |    |     |
           A     B    C     D

 - Larry