Subject: [nvo3] Encapsulation considerations

From: Erik Nordmark <[email-masked]>
Date: Wed, 25 Mar 2015 16:01:29 -0500

I presented part of this at the most recent NVO3 interim meeting.The 
full 12 areas of considerations where presented at RTGWG earlier this week.
  The draft is
    http://datatracker.ietf.org/doc/draft-rtg-dt-encap/
  and the slides are at
   http://www.ietf.org/proceedings/92/slides/slides-92-rtgwg-8.pdf

There is probably additional things in there to consider for NVO3, and 
advice that can be reused to make it easier to move NVO3 forward.

Regards,
    Erik

---

From: Lucy yong <[email-masked]>
Date: Wed, 25 Mar 2015 21:23:18 +0000

Here is a suggestion to the draft.

There are two distinct encapsulation purposes.
1) an encapsulation for tunneling purpose, i.e. transport related encapsulation, e.g. nvo3.
2) an encapsulation for a service, i.e. transport independent encapsulation, e.g. sfc.

Considerations for two types of encapsulations have difference. It is good for the draft to point out that and give separate considerations.

Thanks,
Lucy  

-----Original Message-----
From: nvo3 [mailto:[email-masked]] On Behalf Of Erik Nordmark
Sent: Wednesday, March 25, 2015 4:01 PM
To: [email-masked]
Subject: [nvo3] Encapsulation considerations

I presented part of this at the most recent NVO3 interim meeting.The full 12 areas of considerations where presented at RTGWG earlier this week.
  The draft is
    http://datatracker.ietf.org/doc/draft-rtg-dt-encap/
  and the slides are at
   http://www.ietf.org/proceedings/92/slides/slides-92-rtgwg-8.pdf

There is probably additional things in there to consider for NVO3, and advice that can be reused to make it easier to move NVO3 forward.

Regards,
    Erik

_______________________________________________
nvo3 mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/nvo3

---

From: Erik Nordmark <[email-masked]>
Date: Fri, 27 Mar 2015 22:32:06 -0700

> Considerations for two types of encapsulations have difference. It is good for the draft to point out that and give separate considerations.

Lucy,

which considerations in the draft are different for the two types you 
suggest?

Thanks,
    Erik

---

From: Lucy yong <[email-masked]>
Date: Mon, 30 Mar 2015 20:16:06 +0000

Hi Eric,

Here is my thought.

Congestion considerations, Header Protection, Entropy, MTU and Fragmentation, and QoS are specific for an encapsulation for tunneling. 

Next-protocol, OAM, extensibility, Security, layering, and middle-box are applied to both types of encapsulations.

Service model may only apply to the encapsulation for a service.

Regards,
Lucy

-----Original Message-----
From: Erik Nordmark [mailto:[email-masked]] 
Sent: Saturday, March 28, 2015 12:32 AM
To: Lucy yong; [email-masked]
Subject: Re: [nvo3] Encapsulation considerations

Lucy,

which considerations in the draft are different for the two types you suggest?

Thanks,
    Erik

---

From: Anoop Ghanwani <[email-masked]>
Date: Tue, 31 Mar 2015 17:05:20 -0700

I'm having trouble separating encapsulations into the categories mentioned.

When we talk about an encapsulation for NVO3 does it include the VXLAN
header only, or does it include the UDP header as well?  Am I allowed to
use the VXLAN header on an MPLS tunnel?  I'm not proposing we do this, just
trying to see if there is a better way to communicate this separation.

Anoop

On Mon, Mar 30, 2015 at 1:16 PM, Lucy yong <[email-masked]> wrote:

> Hi Eric,
>
> Here is my thought.
>
> Congestion considerations, Header Protection, Entropy, MTU and
> Fragmentation, and QoS are specific for an encapsulation for tunneling.
>
> > Considerations for two types of encapsulations have difference. It is
> good for the draft to point out that and give separate considerations.
>
> Lucy,
>

---

From: "Larry Kreeger (kreeger)" <[email-masked]>
Date: Wed, 1 Apr 2015 02:53:01 +0000

Hi Anoop,

IMO, the "encapsulation" includes both the VXLAN header and the UDP header and even the outer IP header.  Basically, everything that is added on the the original packet to delivery it from one VTEP to another.  Using VXLAN with MPLS instead of UDP/IP makes no sense to me, but maybe I lack imagination :-)

 - Larry

From: Anoop Ghanwani <[email-masked]<mailto:[email-masked]>>
Date: Tuesday, March 31, 2015 5:05 PM
To: Lucy yong <[email-masked]<mailto:[email-masked]>>
Cc: Erik Nordmark <[email-masked]<mailto:[email-masked]>>, "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [nvo3] Encapsulation considerations

When we talk about an encapsulation for NVO3 does it include the VXLAN header only, or does it include the UDP header as well?  Am I allowed to use the VXLAN header on an MPLS tunnel?  I'm not proposing we do this, just trying to see if there is a better way to communicate this separation.

Anoop

On Mon, Mar 30, 2015 at 1:16 PM, Lucy yong <[email-masked]<mailto:[email-masked]>> wrote:
Hi Eric,

Here is my thought.

Regards,
Lucy

-----Original Message-----
From: Erik Nordmark [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Saturday, March 28, 2015 12:32 AM
To: Lucy yong; [email-masked]<mailto:[email-masked]>
Subject: Re: [nvo3] Encapsulation considerations

Lucy,

Thanks,
    Erik

> From: nvo3 [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Erik Nordmark
> To: [email-masked]<mailto:[email-masked]>
> [email-masked]<mailto:[email-masked]>

_______________________________________________
nvo3 mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/nvo3

---

From: Erik Nordmark <[email-masked]>
Date: Tue, 31 Mar 2015 21:57:49 -0700

Lucy,

I'm not sure I have a crisp definition of a "service" vs. "tunneling".

But looking at your examples I think there are less differences than you 
claim.
For instance, if a "service" adds a header of some sort it needs to 
consider the MTU/frag implications of that header. And it needs to 
consider whether it needs to protect the header against bit errors (that 
are undetected by the link layer).

Furthermore, if the "service" can be applied to non-congestion 
controlled traffic, e.g., arbitrary Ethernet payload, then congestion 
needs to be considered.

So if we keep in mind that these are considerations and not 
requirements, then I don't think we need to try to find some way to 
separate them out. Upon considering something for e.g., SFC, it might 
turn out that no action is needed.

Thanks,
    Erik