Hi Qin, Responses are below with LK>.
- Larry From: Qin Wu <[email protected]<mailto:[email protected]>> Date: Wednesday, April 17, 2013 9:01 PM To: Larry Kreeger <[email protected]<mailto:[email protected]>>, Anoop Ghanwani <[email protected]<mailto:[email protected]>>, David Black <[email protected]<mailto:[email protected]>> Cc: "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>>, "Reith, Lothar" <[email protected]<mailto:[email protected]>> Subject: 答复: [nvo3] 答复: 答复: 答复: 答复: NVO3 Terminology changes Hi, : Sorry, my figure is filtered out. So I send it again. Regards! -Qin 发件人: Larry Kreeger (kreeger) [mailto:[email protected]] 发送时间: 2013年4月18日 0:56 收件人: Qin Wu; Anoop Ghanwani; Black, David 抄送: [email protected]<mailto:[email protected]>; Reith, Lothar 主题: 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. [Qin]: Okay, I should agree with you since I didn’t see more granularity either and still doubt about 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 >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 >>>> [Qin]:Firstly I agree with Pat about having TSI at point D LK> There is a problem with this if the VN service is at layer 2 allowing any L3 protocol above it to be carried transparently. The IP address must be optional. In the meanwhile I think we could also having TSI at point B. Point C doesn't make sense to me since each VNIC only MUST be assigned one unique MAC address based on my understanding, when VNIC connects multiple VNs, you can not use one MAC address to distinct different TSI. LK> Just because a NIC/vNIC has one "burned in" address, it doesn't mean the tenant system will not have traffic with more than one MAC address. For example, if the TS is a router, it may use the burned-in MAC and also have a virtual MAC for supporting VRRP. If the TS is a bridge, it will send/receive frames with the MAC address of all the entities it is bridging traffic for. Some routers use different MAC addresses on different VLANs. Point A is also having problem, as I mentioned earlier below, , if we regard vNIC as TSI, you may have case to associate one TSI with multiple NVEs when vNIC connect to multiple VNs. LK> Is this a problem because you are assuming different external NVEs will support different VNs? My assumption is that any VN can be terminated by any external NVE. If not, I'm not sure what the problem is. Secondly, VNIC Containment Relationship in the figure you described above introduces a little bit confusing, since you didn't distinguish the entity or objects from identifiers since vNIC and VN are both objects while MAC address and IP address are both identifier. LK> I don't see why a MAC or IP address cannot be considered an object as well as an identifier. Yes, VNICs and VNs need identifiers, but I think they are separate from the addresses in frames/packets that may pass over them. So I proposed to change the figure you described above as follows: +---------------------+ | | | VM (Tenant System) | | | +-+--------+--------+-+ | | | | | | | | | + + ...... + vNIC1/pNIC1 vNIC2 vNICx | | |--------+------+------+ | | | | | | | | VN1 VN2 VN3 Non-VN Tenant System Interfaces(TSI): TSIa [VNID1,MAC1,IP addr1]corresponding to vNIC TSIb [VNID2,MAC1,IP addr2]corresponding to vNIC TSIc [VNID3,MAC1,IP addr3]corresponding to vNIC TSId [ ,MAC1,IP add4] corresponding to pNIC You don’t need to care about the relation between vNIC and TSI is 1:1 or 1: N. Each TSI is identifier by combination of VNID, MAC address of vNIC, IP address of vNIC, when going to pNIC, TSI can be identified by only combination of MAC address and IP address, not necessary adding VNID. LK> I don't see any distinction between a TSI for a vNIC vs pNIC vs some other type of TSI. They all need to at least one VN, otherwise what is the point of knowing their MAC or IP addresses? Note that for one vNIC, it uses the same MAC address for all the TSIs belonging to the same vNIC. LK> I would not assume that in all cases. For L2 and L3 service distinction, you can add additional identifier to [VNID, MAC address, IP address], e.g., VLAN Tag to distinct L2 from L3. I think this proposed change above also considers both NIC and vNIC and address the concerns what we discussed on this list and is also still getting in line with what pat observed. >> - Larry
_______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
