[bess] Disccusion on draft-mohanty-bess-evpn-bum-opt-00

The draft I mentioned is draft-li-l2vpn-evpn-mcast-state-ad-01. It takes another solution to solve the similar issue as draft-mohanty-bess-evpn-bum-opt-00. ___ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess

Re: [bess] Call for adoption: draft-zzhang-bess-mvpn-msdp-sa-interoperation-01

Yes/support Cheers, Jeff On Feb 26, 2018, at 8:01 AM, "stephane.litkow...@orange.com" wrote: Hello working group, This email starts a two-week call for adoption on draft-zzhang-bess-mvpn-msdp-sa-interoperation-01 [1] as a BESS Working Group Document.

Re: [bess] Call for adoption: draft-zzhang-bess-mvpn-msdp-sa-interoperation-01

Support Regards, Nabeel > On Feb 26, 2018, at 8:01 AM, > wrote: > > Hello working group, > > This email starts a two-week call for adoption on > draft-zzhang-bess-mvpn-msdp-sa-interoperation-01 [1] as a BESS Working Group >

Re: [bess] Call for adoption: draft-zzhang-bess-mvpn-msdp-sa-interoperation-01

Support. Stig On Tue, Mar 20, 2018 at 8:13 AM, Dolganow, Andrew (Nokia - SG/Singapore) wrote: > Support > > Andrew > > Sent from my iPhone > > On Feb 26, 2018, at 8:01 AM, "stephane.litkow...@orange.com" > wrote: > > Hello working

Re: [bess] Call for adoption: draft-zzhang-bess-mvpn-msdp-sa-interoperation-01

Support Andrew Sent from my iPhone On Feb 26, 2018, at 8:01 AM, "stephane.litkow...@orange.com" > wrote: Hello working group, This email starts a two-week call for adoption on

Re: [bess] Call for adoption: draft-zzhang-bess-mvpn-msdp-sa-interoperation-01

+1 Sent from my iPhone On 20 Mar 2018, at 13:26, Eric C Rosen > wrote: While MSDP may be a mess, customers do use it, and this draft describes a scheme that is useful for many such customers, and which is often requested. So I support the

Re: [bess] [mpls] [sfc] Progress with draft-farrel-mpls-sfc

Jim, You said that you “simply need SR to realize the chain”, but actually if you want a path to be steered relying upon some information conveyed in the packet and to invoke specific SFs, then you need to define the structure of such information and its meaning. That is another piece of

Re: [bess] [mpls] [sfc] Progress with draft-farrel-mpls-sfc

I guess I am not being clear. The issue as I see it is that I do not require NSH to realize the creation of simple chains. I simply need SR to realize the chain. Why is the IETF forcing me to adopt technology that I do not need, while at the same time reducing the number of vendors that I may

Re: [bess] [mpls] [sfc] Progress with draft-farrel-mpls-sfc

Jim & Avinash, Please let's observe that Adrian removed any references to Segment Routing. What this means that the current proposal is based on vanilla MPLS labels which by base MPLS architecture have **local significance*. * You can't assume that out of the sudden label has domain wide or

Re: [bess] Call for adoption: draft-zzhang-bess-mvpn-msdp-sa-interoperation-01

While MSDP may be a mess, customers do use it, and this draft describes a scheme that is useful for many such customers, and which is often requested.  So I support the adoption of this draft by the WG. On 2/26/2018 3:01 AM, stephane.litkow...@orange.com wrote: Hello working group, This

Re: [bess] [mpls] [sfc] Progress with draft-farrel-mpls-sfc

For simple service chains, policy routing works fine as well (this was what was used before bess-service-chaining has come). It becomes a nightmare when the service chains are complex. From: Henderickx, Wim (Nokia - BE/Antwerp) [mailto:wim.henderi...@nokia.com] Sent: Tuesday, March 20, 2018

Re: [bess] [mpls] [sfc] Progress with draft-farrel-mpls-sfc

Jim whats wrong with this draft: https://tools.ietf.org/html/draft-ietf-bess-service-chaining-04 It provides simple service chaining using MPLS techniques From: "UTTARO, JAMES" Date: Tuesday, 20 March 2018 at 11:30 To: Stephane Litkowski ,

Re: [bess] [mpls] [sfc] Progress with draft-farrel-mpls-sfc

Jim and a few others started to document how we can use MPLS as transport to support service chaining with NSH. The draft needs a lot of work and is right now focussed on SR but will also work on any MPLS transport: LDP, RSVP, SPRING, etc etc + how to use in IP-VPN/EVPN. We will refine it and

Re: [bess] [sfc] [mpls] Progress with draft-farrel-mpls-sfc

Dear Avinash, But these various encapsulation options (VXLAN, IP-in-IP,..) are already there thanks to the transport-agnostic approach endorsed by the SFC WG. An alternative approach would be to mimic NSH for each of the mechanisms you listed. That approach is suboptimal, IMO. FWIW, we used

Re: [bess] [mpls] [sfc] Progress with draft-farrel-mpls-sfc

> Same approach that IETF took for EVPN with various encap options like MPLS, > VXLAN, GENEVE,.. Well you do have the same thing with SFC/NSH, you can use any type of transport underneath: MPLS, VXLAN, GRE,UDP,… In your example EVPN provides the service, then you pick the transport you want.

Re: [bess] [sfc] [mpls] Progress with draft-farrel-mpls-sfc

I support this effort and I agree with Jim. As an operator we would like to see various encapsulation options for SFC. This would help an operator to pick the suitable encapsulation option for their networks. Same approach that IETF took for EVPN with various encap options like MPLS, VXLAN,