Hi, Comments inline
Yours Irrespectively, John From: Sandy Breeze <[email protected]> Sent: Thursday, March 22, 2018 1:42 PM To: John E Drake <[email protected]>; Rabadan, Jorge (Nokia - US/Mountain View) <[email protected]>; Eric Rosen <[email protected]>; [email protected] Subject: Re: [bess] draft-mohanty-bess-evpn-bum-opt-00 - clarification on problem description Hi John, On 22/03/2018, 15:50, "John E Drake" <[email protected]<mailto:[email protected]>> wrote: Hi, 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=CRB2tJiQePk0cT-h5LGhEWH-s_xXXup3HzvBSMRj5VE&m=1qUG2zcOnBYVgqYAruIyYwYTWI_ccvWmgqpVaj6nw_g&s=VPDaymo2gpPzYJstfpbXMMhH21sHQWFlZM5dWELsiPY&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’d considered alternative methods other than withdraw, such as extended community or something specific in PMSI Tunnel Attribute. Withdraw/don’t advertise RT3 approach was chosen for the following reasons; - Requires no change to protocol - Is computationally easier on all participating PE’s, to deal with a simple withdraw than to look for something in an update. For instance, on transition from BDF to NDF for example [JD] I think what Eric and I are saying is that this is a bad idea. As an example, it breaks IGMP Proxy because we no longer no whether all of the PEs attached to a given ES support it which effectively disables IGMP Proxy on that ES. It would also break OISM because, again, we would no longer know the capabilities of the PEs attached to that ES. [Sandy] You mention only applicable to EVPN DC GWs. In my world this is a converged EVPN PE router. How would you declare an EVPN DC GW and treat it differently from an EVPN PE? [JD] The normal case is that a PE is attached to a multiplicity of ESEs As an aside, I think Ali’s suggestion of using local configuration to set the ESI to zero in the HRW is fine. However, given the you are using local configuration to do this, why isn’t preference-based DF election (https://tools.ietf.org/html/draft-ietf-bess-evpn-pref-df-00<https://urldefense.proofpoint.com/v2/url?u=https-3A__tools.ietf.org_html_draft-2Dietf-2Dbess-2Devpn-2Dpref-2Ddf-2D00&d=DwMGaQ&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=CRB2tJiQePk0cT-h5LGhEWH-s_xXXup3HzvBSMRj5VE&m=1qUG2zcOnBYVgqYAruIyYwYTWI_ccvWmgqpVaj6nw_g&s=26lcqkrOqqDHo5faivKsv2-uJQ_3Qbe17Zmkolbiht8&e=>) a better solution? I.e., we should have specific DF election type for a specific set of situations rather than trying to parameterize the HRW DF election to handle a multiplicity of situations. [Sandy] I don’t think in my specific case, I’m reliant on setting ESI to zero to since I am only 1 ES per BD. [JD] I don’t think this is consistent w/ the DCI interconnect draft and I don’t see any reason for doing this. I.e., there is supposed to be any interconnect ESI for the DC as a whole.. In the more general case however, as Satya mentions in an earlier thread, this may be desirable to set ESI to 0 for optimal NDF position where all BD’s share the same ES and there are many ES’s. [JD] I have heard this assertion from both you and Satya. Do you have any evidence to support it? [Sandy] As with any existing DF type I know of, preference DF is fine as a selection mechanism, but it doesn’t stop NDF’s attracting traffic unnecessarily which is what I’m trying to achieve here. [JD] That is why I am suggesting the bit in the Multicast Flags extended community. Regards Sandy Yours Irrespectively, John From: BESS <[email protected]<mailto:[email protected]>> On Behalf Of Rabadan, Jorge (Nokia - US/Mountain View) Sent: Thursday, March 22, 2018 10:58 AM To: Eric Rosen <[email protected]<mailto:[email protected]>>; Sandy Breeze <[email protected]<mailto:[email protected]>>; [email protected]<mailto:[email protected]> Subject: Re: [bess] draft-mohanty-bess-evpn-bum-opt-00 - clarification on problem description Eric, The way the draft is described makes me think there are no IRB interfaces and this is limited to Ingress Replication. But should be clarified. Also my interpretation of RFC7432 is that IMET routes are mandatory to enable the handling of multi-destination traffic in a BD. But in a non-DF PE for a given ES and with no other ACs in the BD, assuming Ingress Replication, there is no such multi-destination traffic (Tx or Rx). So one could interpret that RFC7432 is ok with withdrawing the IMET route in that case. Assuming the above, my reasoning is that advertising/withdrawing an IMET route does not change any procedures or modifies any routes. Other than that, I fully agree with you this is a corner case scenario. And if this goes one, it must explain clearly what the use-case is. Thank you. Jorge From: Eric C Rosen <[email protected]<mailto:[email protected]>> Date: Thursday, March 22, 2018 at 1:57 PM To: "Rabadan, Jorge (Nokia - US/Mountain View)" <[email protected]<mailto:[email protected]>>, Sandy Breeze <[email protected]<mailto:[email protected]>>, "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>> Subject: Re: [bess] draft-mohanty-bess-evpn-bum-opt-00 - clarification on problem description On 3/21/2018 12:36 PM, Rabadan, Jorge (Nokia - US/Mountain View) wrote: This scenario definitively helps understand the use-case better. Still a bit specific but I think you should add this scenario to the draft, and again, make it Informational since there is no control plane change for this. If I understand correctly, the draft does make a control plane change, since it describes situations in which IMET routes should not be originated. This contradicts RFC 7432, and so would have to be considered a update to that, and hence a standards track document. Since I wasn't at the BESS meeting (but did watch the video), it's possible I missed some of the discussion, but from my reading of the draft, I have the following concerns. I'm not sure the draft properly describes the situations in which one may omit the IMET route. It describes the situation in which a PE doesn't need to propagate, on any of its ACs, BUM traffic that it receives from the backbone. However, if the PE has IRB interfaces, doesn't it need to receive some of the BUM traffic in order to process that traffic itself? For example, if a PE is configured to be a PIM router attached to two Broadcast Domains, BD1 and BD2, won't it need to receive PIM Hellos from BD1, even if it doesn't actually propagate those out the local AC attaching it to BD1? At the meeting a DF election scheme was proposed in which, for a given <ES,BD> pair, there could be a different DF for each(S,G) multicast flow. I don't think the draft takes this into account. I wonder how many other scenarios there are which the draft fails to consider. Many EVPN drafts have been written on the presumption that IMET routes will always be originated. Some of the drafts add flags or communities to the IMET routes to advertise capabilities of one sort or another. Every one of those drafts would need to be checked to see if it still works when some nodes do not originate IMET routes. As future EVPN drafts are written, the authors (and reviewers) will now have to remember that they cannot presume that all the PEs attached to a given BD are originating IMET routes for that BD. This creates more complexity, more corner cases, and ultimately, more specification bugs. Still, one might consider adopting this complication if it were a big win. But it only seems to apply to one specific (and not very common) scenario, and from the discussion at the microphone it wasn't clear to me that the co-authors are even on the same page about just what that scenario is (recall the discussion about whether the diagram in the draft does or does not depict the intended use case).
_______________________________________________ BESS mailing list [email protected] https://www.ietf.org/mailman/listinfo/bess
