Re: [bess] Some questions on E-Tree (RFC8317) services with VXLAN Encapsulation: is it feasible? is it necessary? is it under definition already?

<wang.yubao2@zte.com.cn> Tue, 27 February 2018 10:14 UTC

Message-ID: <2018020718175481991562110@zte.com.cn>
Mime-Version: 1.0
From: wang.yubao2@zte.com.cn
To: jorge.rabadan@nokia.com
Cc: bess@ietf.org, sajassi@cisco.com, ssalam@cisco.com, jdrake@juniper.net, ju1738@att.com, sboutros@vmware.com
Content-Type: multipart/alternative; boundary="=====_003_next====="
Archived-At: <https://mailarchive.ietf.org/arch/msg/bess/SNuwaxRrswCpEJY8vYClypLmzbc>
Subject: Re: [bess] Some questions on E-Tree (RFC8317) services with VXLAN Encapsulation: is it feasible? is it necessary? is it under definition already?
Precedence: list
Date: Tue, 27 Feb 2018 10:14:30 -0000

Thanks for your explanations.


So the extensions is based on GENEVE and RFC8317, 


Glad to see your working on EVPN extensions for GENEVE in the future.


I have mixed GENEVE with VXLAN, and I didn't see a leaf-label extension in GENEVE, so I asked the question.


I get the point now,


Best wishes.





//Hi,

// 

//Since the overlay tunnel  encapsulation selected by NVO3 is GENEVE, IMHO we should only work on EVPN  extensions for GENEVE. VXLAN does not have the required //extensibility.  

//And indeed, we are  working on EVPN extensions for GENEVE that will address RFC8317 E-Tree  services.

// 

//SRv6 is a different  beast.

// 

//Finally, Local Bias can  be used for all-active multi-homing, but not for E-Tree, or at least I fail to  see how you would do it.

// 

//My 2  cents.

//Jorge

 

 


From: "wang.yubao2@zte.com.cn"  <wang.yubao2@zte.com.cn>
Date: Wednesday, February 7, 2018 at  8:22 AM
To: "sajassi@cisco.com" <sajassi@cisco.com>,  "ssalam@cisco.com" <ssalam@cisco.com>, "jdrake@juniper.net"  <jdrake@juniper.net>, "ju1738@att.com" <ju1738@att.com>,  "sboutros@vmware.com" <sboutros@vmware.com>, "Rabadan, Jorge (Nokia -  US/Mountain View)" <jorge.rabadan@nokia.com>
Cc: "bess@ietf.org"  <bess@ietf.org>
Subject: Some questions on E-Tree (RFC8317)  services with VXLAN Encapsulation: is it feasible? is it necessary? is it under  definition already?


 


 


Hi  folks,


 


I have some questions on E-Tree  services with VXLAN Encapsulation,


 


1) It seems that RFC8317 only  defines E-Tree service in MPLS (or PBB over MPLS EVPN)  encapsulation.


  but there are other EVPN  encapsulations, VXLAN and SRv6,


  and the SRv6 EVPN solution also  defined the E-Tree procedures framework with Arg.FE2 included in DT2M  SIDs


  so, is the E-Tree service with  VXLAN Encapsulation feasible? is it necessary? is it under definition  already?


 


2) i think the primary design  with E-tree over MPLS EVPN is ESI/Leaf Label,


  but in VXLAN encapsulation,  there is no ESI Label or Leaf Label,


  so, although it can do ESI  filtering procedures with "Local Bias" procedure and without ESI Label  information,


  the VXLAN Encapsulation can't  do E-tree filtering procedures without Leaf Label?


  is it right or i have missed  something?


 


Best  Regards,


Wang  Yubao

Re: [bess] Some questions on E-Tree (RFC8317) se… wang.yubao2
Re: [bess] Some questions on E-Tree (RFC8317) se… wang.yubao2
Re: [bess] Some questions on E-Tree (RFC8317) se… wang.yubao2
Re: [bess] Some questions on E-Tree (RFC8317) se… wang.yubao2
Re: [bess] Some questions on E-Tree (RFC8317) se… wang.yubao2
Re: [bess] Some questions on E-Tree (RFC8317) se… wang.yubao2
Re: [bess] Some questions on E-Tree (RFC8317) se… wang.yubao2