Re: [bess] Shepherd's review of draft-ietf-bess-mvpn-expl-track

2018-02-07 Thread Eric C Rosen
On 1/16/2018 11:29 AM, Eric C Rosen wrote: “If the LIR-pF flag is set in a given PTA, the LIR flag of that PTA    SHOULD also be set.” [SLI] Why not using a MUST ? [Eric] If all the PEs support the LIR-pF flag, the procedures will work as intended even if the LIR flag is not set.  So I don't

Re: [bess] Shepherd's review of draft-ietf-bess-evpn-ac-df

2018-02-07 Thread stephane.litkowski
Hi, > In that case, two PEs in the same ES supporting type=255 should rely on local > policy to decide what to. If type=255 is used, the local policy should be applied and it becomes the job of the operator to ensure that the policy is the same everywhere. > And two PEs in the same ES

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

2018-02-07 Thread wang.yubao2
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

Re: [bess] Shepherd's review of draft-ietf-bess-evpn-ac-df

2018-02-07 Thread Rabadan, Jorge (Nokia - US/Mountain View)
Hi Stephane, When a new type comes up, we normally encourage people to publish a draft and register a temporary type with IANA, so that others can interop. Having said that, I think your idea is good and we could reserve type=255 for vendor-specific or experimental purposes, so that people can

Re: [bess] Shepherd's review of draft-ietf-bess-evpn-ac-df

2018-02-07 Thread stephane.litkowski
Hi Jorge, This perfectly fills my comment. Speaking as doc shepherd and WG member, I think it could make sense to have a vendor specific DF election type allocated. This would allow a vendor to develop a specific algorithm to address a niche use case, not supported by other vendors. What do