Subject: [nvo3] question and comment on gross-geneve draft

From: Lucy yong <[email-masked]>
Date: Mon, 10 Mar 2014 18:48:13 +0000

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.

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

---

From: Tom Herbert <[email-masked]>
Date: Mon, 10 Mar 2014 12:28:54 -0700

On Mon, Mar 10, 2014 at 11:48 AM, Lucy yong <[email-masked]> wrote:
> Hi Authors,
>
>
>
>    “Transit device.  A forwarding element along the path of the tunnel.
>
>    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).
>
>
>
> 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/nvo3
>

---

From: Lucy yong <[email-masked]>
Date: Mon, 10 Mar 2014 19:49:16 +0000

-----Original Message-----
From: Tom Herbert [mailto:[email-masked]] 
Sent: Monday, March 10, 2014 2:29 PM
To: Lucy yong
Cc: [email-masked]; [email-masked]
Subject: Re: [nvo3] question and comment on gross-geneve draft

On Mon, Mar 10, 2014 at 11:48 AM, Lucy yong <[email-masked]> wrote:
> 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).
>
>
>
> (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. 

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
>
>
>
>
>
>

---

From: AshwoodsmithPeter <[email-masked]>
Date: Mon, 10 Mar 2014 19:56:35 +0000

> 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.

I think if you want the OAM and user data packets to follow the same ECMP path then as long as the EtherType is not included in the hash that produces the source of entropy (i.e. the UDP source port in the case of VXLAN) then yes you could use a different EtherType for OAM, otherwise if EtherType is included in the hash you need a bit outside the hash.

Cheers,

Peter

---

From: Tom Herbert <[email-masked]>
Date: Mon, 10 Mar 2014 13:22:30 -0700

> 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…
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).

Tom

---

From: Lucy yong <[email-masked]>
Date: Mon, 10 Mar 2014 20:29:27 +0000

Please see in-line below w/ [Lucy1]

-----Original Message-----
From: Tom Herbert [mailto:[email-masked]] 
Sent: Monday, March 10, 2014 3:23 PM
To: Lucy yong
Cc: [email-masked]; [email-masked]
Subject: Re: [nvo3] question and comment on gross-geneve draft

On Mon, Mar 10, 2014 at 12:49 PM, Lucy yong <[email-masked]> wrote:
>> 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.
>>
>>
>>
>> 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.
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.

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.
>>
>>
>>

---

From: Tom Herbert <[email-masked]>
Date: Mon, 10 Mar 2014 13:33:50 -0700

> [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 tho…

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.