Subject: [nvo3] unified encapsulation headers for both Layer2 and Layer3 VPN overlays?

From: Xuxiaohu <[email-masked]>
Date: Fri, 21 Sep 2012 10:10:58 +0000

Hi all,

It's well-known that MPLS encapsulation can be used in both Layer2 VPN overlay (e.g., MAC-in-MPLS-in-GRE) and Layer3 VPN overlay (e.g., IP-in-MPLS-in-GRE). Meanwhile, although NVGRE is targeted only for Layer2 VPN overlay (i.e., MAC over IP overlay) scheme at present, the protocol type field in the GRE header however provides a possibility of supporting Layer3 VPN overlay (i.e., IP over IP overlay) if needed in the future. However, as per the encapsulation format described in the current version of VXLAN draft, there is no such protocol type field in the VXLAN header yet. Hence I suggest the VXLAN co-authors could consider using some reserved bits as the protocol type field. In this way, the VXLAN encapsulation header could also be applicable to the Layer3 VPN overlay scheme if needed in the future.

Best regards,
Xiaohu

---

From: Kireeti Kompella <[email-masked]>
Date: Fri, 21 Sep 2012 06:44:29 -0700

Hi,

For a number of reasons, including the current "vigorous discussion" on
multiple encaps for L2-in-L3, I would STRONGLY URGE the group to not go
there.

There are more than enough L3-in-L3 encaps already: sufficient unto the day
....

Regards,
Kireeti.

On Fri, Sep 21, 2012 at 3:10 AM, Xuxiaohu <[email-masked]> wrote:

>  Hi all,****
>
> ** **
>
> It’s well-known that MPLS encapsulation can be used in both Layer2 VPN
> overlay (e.g., MAC-in-MPLS-in-GRE) and Layer3 VPN overlay (e.g.,
> IP-in-MPLS-in-GRE). Meanwhile, although NVGRE is targeted only for Layer2
> VPN overlay (i.e., MAC over IP overlay) scheme at present, the protocol
> type field in the GRE header however provides a possibility of supporting
> Layer3 VPN overlay (i.e., IP over IP overlay) if needed in the future.
> However, as per the encapsulation format described in the current version
> of VXLAN draft, there is no such protocol type field in the VXLAN header
> yet. Hence I suggest the VXLAN co-authors could consider using some
> reserved bits as the protocol type field. In this way, the VXLAN
> encapsulation header could also be applicable to the Layer3 VPN overlay
> scheme if needed in the future.****
>
> ** **
>
> Best regards,****
>
> Xiaohu****
>
> _______________________________________________
> nvo3 mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/nvo3
>
>

-- 
Kireeti

---

From: Yakov Rekhter <[email-masked]>
Date: Fri, 21 Sep 2012 06:55:52 -0700

Kireeti,

> There are more than enough L3-in-L3 encaps already: sufficient unto 

I certainly agree with you that there are more than enough L3-in-L3
encaps that are IETF standard.

But do you think we have a shortage of L2-in-L3 encaps that are
IETF standards ?

Yakov.

> > It=92s well-known that MPLS encapsulation can be used in both Layer2 VPN
> --=20
> --047d7b33db625f3c7104ca36702c
> Content-Type: text/html; charset=windows-1252
> Content-Transfer-Encoding: quoted-printable
> 
> Hi,<div><br></div><div>For a number of reasons, including the current &quo
t=
> ;vigorous discussion&quot; on multiple encaps for L2-in-L3, I would STRONG
L=
> Y URGE the group to not go there.<br><br></div><div>There are more than en
o=
> ugh L3-in-L3 encaps already: sufficient unto the day ....</div>
> <div><br></div><div>Regards,</div><div>Kireeti.</div><div><br><div class=3
D=
> "gmail_quote">On Fri, Sep 21, 2012 at 3:10 AM, Xuxiaohu <span dir=3D"ltr">
&=
> lt;<a href=3D"mailto:[email-masked]" target=3D"_blank">xuxiaohu@huawe
i=
> .com</a>&gt;</span> wrote:<br>
> <blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1
p=
> x #ccc solid;padding-left:1ex">
> 
> 
> 
> 
> 
> <div lang=3D"ZH-CN" link=3D"blue" vlink=3D"purple">
> <div>
> <p class=3D"MsoNormal"><span lang=3D"EN-US">Hi all,<u></u><u></u></span></
p=
> >
> <p class=3D"MsoNormal"><span lang=3D"EN-US"><u></u>=A0<u></u></span></p>
> <p class=3D"MsoNormal"><span lang=3D"EN-US">It=92s well-known that MPLS en
c=
> apsulation can be used in both Layer2 VPN overlay (e.g., MAC-in-MPLS-in-GR
E=
> ) and Layer3 VPN overlay (e.g., IP-in-MPLS-in-GRE). Meanwhile, although NV
G=
> RE is targeted only for Layer2 VPN overlay
>  (i.e., MAC over IP overlay) scheme at present, the protocol type field in
 =
> the GRE header however provides a possibility of supporting Layer3 VPN ove
r=
> lay (i.e., IP over IP overlay) if needed in the future. However, as per th
e=
>  encapsulation format described
>  in the current version of VXLAN draft, there is no such protocol type fie
l=
> d in the VXLAN header yet. Hence I suggest the VXLAN co-authors could cons
i=
> der using some reserved bits as the protocol type field. In this way, the 
V=
> XLAN encapsulation header could
>  also be applicable to the Layer3 VPN overlay scheme if needed in the futu
r=
> e.<u></u><u></u></span></p>
> <p class=3D"MsoNormal"><span lang=3D"EN-US"><u></u>=A0<u></u></span></p>
> <p class=3D"MsoNormal"><span lang=3D"EN-US">Best regards,<u></u><u></u></s
p=
an></p>
> <p class=3D"MsoNormal"><span lang=3D"EN-US">Xiaohu<u></u><u></u></span></p
>
> </div>
> </div>
> 
> <br>_______________________________________________<br>
> nvo3 mailing list<br>
> <a href=3D"mailto:[email-masked]">[email-masked]</a><br>
> <a href=3D"https://www.ietf.org/mailman/listinfo/nvo3" target=3D"_blank">h
t=
> tps://www.ietf.org/mailman/listinfo/nvo3</a><br>
> <br></blockquote></div><br><br clear=3D"all"><div><br></div>-- <br>Kireeti
<=
> br>
> </div>
> 
> --047d7b33db625f3c7104ca36702c--
> 
> --===============6747870849911718800==
> Content-Type: text/plain; charset="us-ascii"
> MIME-Version: 1.0
> Content-Transfer-Encoding: 7bit
> Content-Disposition: inline
> 
> --===============6747870849911718800==--

---

From: Kireeti Kompella <[email-masked]>
Date: Fri, 21 Sep 2012 11:44:15 -0700

Hi Yakov,

> But do you think we have a shortage of L2-in-L3 encaps that are

Not at all!  Sadly, there seems to be more interest in coming up with new encaps than in coming up with a control plane that can actually deal with the problems of large scale multi-tenant data centers.  However, taking these new encaps as a pragmatic reality, having a single control plane that can signal across all of them is a Good Thing.

Just to be clear, these new encaps are not yet IETF standards (but it seems likely that some of them will be.)

Kireeti.

---

From: "NAPIERALA, MARIA H" <[email-masked]>
Date: Fri, 21 Sep 2012 18:48:53 +0000

> Not at all!  Sadly, there seems to be more interest in coming up with
> new encaps than in coming up with a control plane that can actually
> deal with the problems of large scale multi-tenant data centers.
> However, taking these new encaps as a pragmatic reality, having a
> single control plane that can signal across all of them is a Good
> Thing.

Doesn't it though "encourage" standardization of those new encaps?
 
Maria

---

From: Kireeti Kompella <[email-masked]>
Date: Fri, 21 Sep 2012 11:50:57 -0700

Hi Maria,

On Sep 21, 2012, at 11:48 AM, "NAPIERALA, MARIA H" <[email-masked]> wrote:

> Doesn't it though "encourage" standardization of those new encamps?

Perhaps.  As I said, "pragmatic reality" … not ideal :-)

---

From: Yakov Rekhter <[email-masked]>
Date: Fri, 21 Sep 2012 12:04:06 -0700

Kireeti,

> Not at all!  Sadly, there seems to be more interest in coming up
> with new encaps than in coming up with a control plane that can
> actually deal with the problems of large scale multi-tenant data
> centers.  However, taking these new encaps as a pragmatic reality,
> having a single control plane that can signal across all of them
> is a Good Thing.
> 
> Just to be clear, these new encaps are not yet IETF standards (but
> it seem s likely that some of them will be.)

I would like the WG chairs (and the appropriate ADs) to comment
on what criteria will be used to decide which these encaps be
IETF standards.

Yakov.

---

From: Thomas Nadeau <[email-masked]>
Date: Fri, 21 Sep 2012 15:11:23 -0400

+1

From: Kireeti Kompella <[email-masked]<mailto:[email-masked]>>
Date: Friday, September 21, 2012 6:44 AM
To: Xuxiaohu <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [nvo3] unified encapsulation headers for both Layer2 and Layer3 VPN overlays?

Hi,

For a number of reasons, including the current "vigorous discussion" on multiple encaps for L2-in-L3, I would STRONGLY URGE the group to not go there.

There are more than enough L3-in-L3 encaps already: sufficient unto the day ....

Regards,
Kireeti.

On Fri, Sep 21, 2012 at 3:10 AM, Xuxiaohu <[email-masked]<mailto:[email-masked]>> wrote:
Hi all,

It’s well-known that MPLS encapsulation can be used in both Layer2 VPN overlay (e.g., MAC-in-MPLS-in-GRE) and Layer3 VPN overlay (e.g., IP-in-MPLS-in-GRE). Meanwhile, although NVGRE is targeted only for Layer2 VPN overlay (i.e., MAC over IP overlay) scheme at present, the protocol type field in the GRE header however provides a possibility of supporting Layer3 VPN overlay (i.e., IP over IP overlay) if needed in the future. However, as per the encapsulation format described in the current version of VXLAN draft, there is no such protocol type field in the VXLAN header yet. Hence I suggest the VXLAN co-authors could consider using some reserved bits as the protocol type field. In this way, the VXLAN encapsulation header could also be applicable to the Layer3 VPN overlay scheme if needed in the future.

Best regards,
Xiaohu

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

--
Kireeti

---

From: Aldrin Isaac <[email-masked]>
Date: Fri, 21 Sep 2012 18:58:51 -0400

++1

This echos what I said yesterday at the interim meeting.  There need to be
requirements directed at dataplane encapsulations including extensibility
-- as opposed to requirements on CP and operators to conform to the
encapsulation of the day.

On Friday, September 21, 2012, Yakov Rekhter wrote:

> [email-masked] <javascript:;>

---

From: Xuxiaohu <[email-masked]>
Date: Sat, 22 Sep 2012 01:18:09 +0000

> -----邮件原件-----
> 发件人: Yakov Rekhter [mailto:[email-masked]]
> 发送时间: 2012年9月21日 21:56
> 收件人: Kireeti Kompella
> 抄送: Xuxiaohu; [email-masked]
> 主题: Re: [nvo3] unified encapsulation headers for both Layer2 and Layer3 VPN
> overlays?
> 
> Kireeti,
> 
> > Hi,
> >

That's an interesting question that I had ever wanted to ask Kireeti.

Best regards,
Xiaohu

> > <p class=3D"MsoNormal"><span
> lang=3D"EN-US"><u></u>=A0<u></u></span></p>
> > <p class=3D"MsoNormal"><span
> lang=3D"EN-US"><u></u>=A0<u></u></span></p>
> > <p class=3D"MsoNormal"><span
> lang=3D"EN-US">Xiaohu<u></u><u></u></span></p
> >
> > </div>
> > </div>
> >

---

From: Xuxiaohu <[email-masked]>
Date: Sat, 22 Sep 2012 02:15:57 +0000

> -----邮件原件-----
> 发件人: [email-masked] [mailto:[email-masked]] 代表 Kireeti
> Kompella
> 发送时间: 2012年9月22日 2:44
> 收件人: Yakov Rekhter
> 抄送: Xuxiaohu; Kireeti Kompella; [email-masked]
> Not at all!  Sadly, there seems to be more interest in coming up with new
> encaps than in coming up with a control plane that can actually deal with the
> problems of large scale multi-tenant data centers.  However, taking these
> new encaps as a pragmatic reality, having a single control plane that can signal
> across all of them is a Good Thing.

Hi Kireeti,

From a technical point of view, if the VXLAN and other similarities continue to rely on multicast trees to emulate broadcast domains, rather than resorting to a control plane protocol (e.g., BGP or ISIS) to realize VN membership auto-discovery , the globally significant VN ID (e.g., VXLAN ID) on the data plane is absolutely necessary. Otherwise (if they use a control plane protocol for VN membership auto-discovery), the globally significant VN ID on the data plane seems not much necessary anymore since the locally significant VN context ID (e.g., MPLS label) can be signaled as well by using the same control plane protocol. 

Best regards,
Xiaohu

---

From: Kireeti Kompella <[email-masked]>
Date: Fri, 21 Sep 2012 20:22:44 -0700

Hi Xiaohu,

On Sep 21, 2012, at 19:15, Xuxiaohu <[email-masked]> wrote:
...

> Hi Kireeti,
> 
> From a technical point of view, if the VXLAN and other similarities continue to rely on multicast trees to emulate broadcast domains, rather than resorting to a control plane protocol (e.g., BGP or ISIS)

Well, the draft in question is trying to change that. 

> to realize VN membership auto-discovery , the globally significant VN ID (e.g., VXLAN ID) on the data plane is absolutely necessary.

Actually not. The management plane that programs the VNID could (in principle) use a different value per NVE. But practically, yes. 

> Otherwise (if they use a control plane protocol for VN membership auto-discovery), the globally significant VN ID on the data plane seems not much necessary anymore since the locally significant VN context ID (e.g., MPLS label) can be signaled as well by using the same control plane protocol. 

Agreed. The benefit of each NVE doing the VNID allocation is that it can optimize for receipt and lookup. MPLS got a few things right, but this isn't always widely recognized. 

Kireeti

---

From: Xuxiaohu <[email-masked]>
Date: Sat, 22 Sep 2012 03:49:03 +0000

> -----邮件原件-----
> 发件人: Kireeti Kompella [mailto:[email-masked]]
> 发送时间: 2012年9月22日 11:23
> 收件人: Xuxiaohu
> 抄送: Yakov Rekhter; [email-masked]
> > From a technical point of view, if the VXLAN and other similarities continue to
> rely on multicast trees to emulate broadcast domains, rather than resorting to
> a control plane protocol (e.g., BGP or ISIS)
> 
> > to realize VN membership auto-discovery , the globally significant VN ID (e.g.,
> VXLAN ID) on the data plane is absolutely necessary.
> 
> Actually not. The management plane that programs the VNID could (in principle)
> use a different value per NVE. But practically, yes.
> 
> > Otherwise (if they use a control plane protocol for VN membership
> auto-discovery), the globally significant VN ID on the data plane seems not
> much necessary anymore since the locally significant VN context ID (e.g., MPLS
> label) can be signaled as well by using the same control plane protocol.
> 
> Agreed. The benefit of each NVE doing the VNID allocation is that it can
> optimize for receipt and lookup. MPLS got a few things right, but this isn't
> always widely recognized.

Hi Kireeti,

As a Ambassador of MPLS, you could actually help more people to recognize that benefit more comprehensively if you are available.

Best regards,
Xiaohu

---

From: Somesh Gupta <[email-masked]>
Date: Mon, 24 Sep 2012 11:57:50 -0700

the reason folks came up with VxLAN is to solve an urgent
problem (VM placement) while leverage existing data center
L2/L3 switches.

1. We are having a hard enough time agreeing on naming while
   IAAS providers have to compete with likes of Amazon
2. What other existing encapsulation would do the work with
   legacy equipment?
   a. MPLS is not implemented in DC switches
   b. Implementations of GRE (in merchant ASICs) do not support
      a tenant field
   c. How would ECMP be supported in existing equipment
   d. And we could go on to other encaps (not widely implemented,
      L2 only etc)
3. Not require a new control plane implementation in the virtual
   switches - which we seem to be spending a lot of effort on
   -- When the entire software driven data center is orchestrated
      centrally, why would hypervisor/vswitch vendors all of a
      sudden not use all of the knowledge they already have and
      implement and depend on yet another mechanism (even if
      as cool as BGP).

Unless we start looking at the problem from the point
of view of centrally managed/orchestrated software defined data center
instead of distributed protocol problem, we might
end up with something no-one really cares about.

Somesh

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Yakov Rekhter
> Sent: Friday, September 21, 2012 12:04 PM
> To: Kireeti Kompella
> Cc: [email-masked]
> > >> There are more than enough L3-in-L3 encaps already: sufficient
> unto
> > >> the day
> > >