> -----邮件原件----- > 发件人: [email protected] [mailto:[email protected]] 代表 Kireeti > Kompella > 发送时间: 2012年9月22日 2:44 > 收件人: Yakov Rekhter > 抄送: Xuxiaohu; Kireeti Kompella; [email protected] > 主题: Re: [nvo3] unified encapsulation headers for both Layer2 and Layer3 VPN > overlays? > > Hi Yakov, > > On Sep 21, 2012, at 6:55 AM, Yakov Rekhter <[email protected]> wrote: > > > Kireeti, > > > >> 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 > > > > 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 ? > > 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 > Just to be clear, these new encaps are not yet IETF standards (but it seems > likely that some of them will be.) > > Kireeti. > > > Yakov. > > > >> .... > >> > >> Regards, > >> Kireeti. > >> > >> On Fri, Sep 21, 2012 at 3:10 AM, Xuxiaohu <[email protected]> wrote: > >> > >>> Hi all,**** > >>> > >>> ** ** > >>> > >>> It=92s 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 Layer > > 2 > >>> VPN overlay (i.e., MAC over IP overlay) scheme at present, the protocol > >>> type field in the GRE header however provides a possibility of supportin > > g > >>> Layer3 VPN overlay (i.e., IP over IP overlay) if needed in the future. > >>> However, as per the encapsulation format described in the current versio > > n > >>> 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 protected] > >>> https://www.ietf.org/mailman/listinfo/nvo3 > >>> > >>> > >> > >> > >> --=20 > >> Kireeti > >> > >> --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" 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 protected]"; > target=3D"_blank">xuxiaohu@huawe > > i= > >> .com</a>></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 protected]";>[email protected]</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 > >> > >> _______________________________________________ > >> nvo3 mailing list > >> [email protected] > >> https://www.ietf.org/mailman/listinfo/nvo3 > >> > >> --===============6747870849911718800==-- > > _______________________________________________ > nvo3 mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/nvo3 _______________________________________________ nvo3 mailing list [email protected] https://www.ietf.org/mailman/listinfo/nvo3
