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