Hi, We are not specifying the solution, the encapsulation header in this case, but rather that such an identifier must be present in the encapsulation solution that is to be further defined/adopted. There had been additional proposed solutions to what you mentioned.
Thanks, Nabil From: Lizhong Jin <[email protected]<mailto:[email protected]>> Date: Wed, 23 May 2012 10:28:31 -0400 To: "LASSERRE, MARC (MARC)" <[email protected]<mailto:[email protected]>>, "Bitar, Nabil N" <[email protected]<mailto:[email protected]>> Cc: "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>> Subject: Re: New dataplane requirements draft Hi Marc, Nabil, In draft section 3.3.1.1, it describes the functions of VNID: "A VNID MUST be included in the overlay encapsulation header on the ingress NVE when encapsulating a tenant Ethernet frame or IP packet on the overlay tunnel. The egress NVE uses the VNID to identify the VN context in which the encapsulated frame should be processed. The VNID can be either a globally unique identifier (on a per-administrative domain) or a locally significant identifier. It MUST be easily parsed and processed by the data path and MAY be distributable by a control-plane or configured via a management plane." It does not implicit any format of the VNID. There are potentially two formats, one is like MPLS lable allocation which is implicit for dataplane and mapping with control plane information, the other is like VLAN format, which is explicit for dataplane and could work without control plane. In http://www.ietf.org/id/draft-kj-nvo3-pion-architecture-00.txt, section 5.3, it describes this. We should gather some requirement about this, and hope to see more comments. Lizhong
_______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
