Hi John, We will take your feedback into account.
Thanks, —Satya From: "jdr...@juniper.net<mailto:jdr...@juniper.net>" <jdr...@juniper.net<mailto:jdr...@juniper.net>> Date: Monday, March 26, 2018 at 6:00 AM To: satyamoh <satya...@cisco.com<mailto:satya...@cisco.com>>, Sandy Breeze <sandy.bre...@eu.clara.net<mailto:sandy.bre...@eu.clara.net>>, "Rabadan, Jorge (Nokia - US/Mountain View)" <jorge.raba...@nokia.com<mailto:jorge.raba...@nokia.com>>, Eric Rosen <ero...@juniper.net<mailto:ero...@juniper.net>>, "bess@ietf.org<mailto:bess@ietf.org>" <bess@ietf.org<mailto:bess@ietf.org>> Subject: RE: [bess] draft-mohanty-bess-evpn-bum-opt-00 - clarification on problem description Satya, Comment inline. Yours Irrespectively, John [John] Wouldn’t it be better to have this draft define a bit in the Multicast Flags extended community (https://tools.ietf.org/html/draft-ietf-bess-evpn-igmp-mld-proxy-01<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dietf-2Dbess-2Devpn-2Digmp-2Dmld-2Dproxy-2D01&d=DwMGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=-DXB84eU9m4cIlq2OOcCJCQQAwJXQQswyu3F0kG0VNo&m=rs8r_tXnIDIv9e5NNgiXOy5yYuE10r6x9al8H6FgK04&s=V42kiY3ngmDNxMKmk5GgHmy9LcMGdOXpcvbereFtUR8&e=>) indicating that that the originating PE is neither DF nor backup DF for this broadcast domain on any ES to which it is attached? This allows us to always advertise the IMET route and makes the situation explicit. I think the consensus is that this situation is rare so the number of IMET route updates shouldn’t be excessive and we could also say that this bit is only set by EVPN DC GWs. [Sandy] We discussed the use of extended community to signal NDF, this is indeed a viable alternative approach and one we’re not against. We didn’t choose it over not sending IMET because we don’t have a good reason why not sending IMET at an NDF is actually a bad idea, for our use case. That said, if the consensus of this list is to use an extended community then a flag in EVPN extended community sub-types registry is a possible fit [Satya] Just to make clear, the Multicast Flags extended community is only sent with the IMET when IGMP proxy is supported. If the BD does not support IGMP/MLD, then this won’t work as Jorge pointed out earlier (BUM with IR only). Perhaps, if there were available flag fields in the PMSI Tunnel attr, one could have used it. Also, creation of a new extended community for the purpose of this optimization looks to me to be adding extra complexity to the CP. So we did not prefer doing that. Setting the label to 0 would have worked, but the value 0 now has the semantics that Sandy points out below. [JD] I don’t think this is correct. The IGMP Proxy draft defines the Multicast Flags extended community, which means that your draft would need to have a normative reference to that draft. However, your draft would be free to define a new bit in the extended community and indicate that support for the that bit is not contingent upon support for the IGMP Proxy draft.
_______________________________________________ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
