On Mon, Mar 10, 2014 at 1:29 PM, Lucy yong <lucy.y...@huawei.com> wrote: > Please see in-line below w/ [Lucy1] > > -----Original Message----- > From: Tom Herbert [mailto:therb...@google.com] > Sent: Monday, March 10, 2014 3:23 PM > To: Lucy yong > Cc: draft-gross-gen...@tools.ietf.org; nvo3@ietf.org > Subject: Re: [nvo3] question and comment on gross-geneve draft > > On Mon, Mar 10, 2014 at 12:49 PM, Lucy yong <lucy.y...@huawei.com> wrote: >> >> >> -----Original Message----- >> From: Tom Herbert [mailto:therb...@google.com] >> Sent: Monday, March 10, 2014 2:29 PM >> To: Lucy yong >> Cc: draft-gross-gen...@tools.ietf.org; nvo3@ietf.org >> Subject: Re: [nvo3] question and comment on gross-geneve draft >> >> 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. >> [Lucy] because it is the general understanding (or assumption) in NVO that >> tunnel egress terminates the packet and forwards based on inner address on >> the packet. In case, a service function such as firewall is a tenant system >> and attaches to a NVE (say egress). If another NVE (say ingress) receives >> the packets from its attached Tenant system and needs to forward packets to >> the firewall first, it needs to encapsulate the packet and send that egress >> NVE. The ingress NVE has the choice to forward the packet to the destination >> TS directly or send to a service function based on the policy. Upon >> receiving a packet from tunnel, egress NVE also needs to know if it should >> perform inner address based forwarding or forward based on the other >> information. >> >> I am not in favor of using EtherType to determine what action that egress >> NVE should do in NVO because EtherType introduces another layer from network >> perspective. We use protocol type or ethertype to differ client layer from >> server layer (i.e. network). Here it is about what actions the network >> overlay layer to take. >> > EtherType is very important in the encapsulation. It serves to both identify > the type of the packet being encapsulated and indicates the processing entry > point of the packet (e.g. switch (EtherType) ...)-- I these properties should > be invariant. Adding alternative paths or interpretations of the enclosed > data muddles its definition and convolutes the fast path. If a different > packet format is needed where EtherType does not indicate the type of the > enclosed data, I would suggest type (version) 0x1 of the encap protocol be > defined with it's own format which can be optimized for the alternative > format (like a version 0x1 in case of geneve). > > [Lucy1] Yes, EtherType is very important. Geneve header has the EtherType > field. My point is that we should not use EtherType for tunnel egress to > determine which forwarding mechanism to use. I thought that the version usage > is for backward compatibility, not for different type of encap. protocol. >
Sorry, that's the way I would do it in GUE which has a type-version field :-) If there's a field called "protocol type" in an encapsulation header then that's what it should be. I'd be really worried if the interpretation of the field depended on flags or other parts of the packet. > Lucy > > Tom > > >> Regards, >> Lucy >> >>> >>> >>> >>> 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 _______________________________________________ nvo3 mailing list nvo3@ietf.org https://www.ietf.org/mailman/listinfo/nvo3
