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 protected]> 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:

 

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.       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 protected]
Betreff: AW: [nvo3] Antw: Re: NVO3 Terminology changes



 

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 protected]
Betreff: AW: [nvo3] Antw: Re: NVO3 Terminology changes



 

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



 

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 protected]] 
Gesendet: Sonntag, 21. April 2013 20:34
An: Reith, Lothar
Cc: [email protected]
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 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 protected]> 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?

 

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 protected] [mailto:[email protected]] Im Auftrag von
Lizhong Jin
Gesendet: Freitag, 19. April 2013 19:05
An: [email protected]; 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 protected]>
To: Qin Wu <[email protected]>, Anoop Ghanwani <[email protected]>,
"Black, David" <[email protected]>
Cc: "[email protected]" <[email protected]>, "Reith, Lothar"
<[email protected]>
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





 



 - Larry



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

Reply via email to