On Mon, Mar 10, 2014 at 11:48 AM, Lucy yong <lucy.y...@huawei.com> wrote: > Hi Authors, > > > > “Transit device. A forwarding element along the path of the tunnel. > > A transit device MAY be capable of understanding the Geneve frame > > format but does not originate or terminate Geneve packets.” > > > > Could you give an example of such transit device? I do not call a firewall > device as a transit device or forwarding element. If you mean that, please > use the term of service function and recheck if the definition fit or not. > > > > NVO technology aims in tunneling packets across a underlay network, and > tunnel terminates at network virtualization edge (NVEs). > > > > I think that all the metadata description relates to this transit device and > is very confused. > > > > The fields in a tunnel encapsulation header are for tunnel ingress end point > (EP) to convey some information (state) for tunnel egress EP, so egress EP > can react on it. To design such header, we should be very clear what kind of > actions tunnel egress EP can or should act on it. There are three: one is to > terminate the tunnel and forward the packet based on inner address on the > packet; the second is to terminate the tunnel and forward it based on other > information (i.e. not inner address on the packets); third are OAM action. > Is there other beside these three? We have OAM flag in the geneve header, we > need another flag to differ between the first action and the second.
Why does the header need to indicate how the packet is to be forwarded? Since the packet is terminated, how to forward it or process it is an otherwise local decision. OAM would be better served to be expressed in an EtherType to eliminate awkward semantics of the bit, so then all geneve packets are processed first based on EtherType. > > > > It is possible that some of other information in the second action may be > carried by the encapsulated packet, which is what SFC WG is working on and > names it as SFC header. But the tunnel encapsulation header just needs to > distinguish the two actions and treats SFC header as a metadata in the > second action. > > > > We should separate the states that a tenant system needs to pass to the > other tenant system from the tunnel encapsulation format because the tunnel > terminates at an NVE not tenant system. The critical optional flag in > geneve header is too general without clear requirements. > > > > Regards, > > Lucy > > > > > > > _______________________________________________ > nvo3 mailing list > nvo3@ietf.org > https://www.ietf.org/mailman/listinfo/nvo3 > _______________________________________________ nvo3 mailing list nvo3@ietf.org https://www.ietf.org/mailman/listinfo/nvo3
