Hi Satya, I don’t follow your point about SHALL vs. MUST. The two are defined by RFC 2119 to be synonyms.
—John On Oct 10, 2020, at 8:32 PM, Satya Mohanty (satyamoh) <satya...@cisco.com> wrote: Hi Ali and John, In the DMZ Link bandwidth draft https://tools.ietf.org/html/draft-ietf-idr-link-bandwidth-07<https://urldefense.com/v3/__https://tools.ietf.org/html/draft-ietf-idr-link-bandwidth-07__;!!NEt6yMaO-gk!Vxr2nCjAMuJKkJ-a-H-vPXJzThAn7BdOtDcw4bvFCnWbkyd5721Jrr5so69MkA$> sec. 2, we have the following sentence. “No more than one link bandwidth extended community SHALL be attached to a route.” Can we add similar wording in here as similar logic applies? It is still a “SHALL” rather than “must”, so even if the speaker receives multiple router-macs, the way you describe below will work. Thanks, --Satya From: BESS <bess-boun...@ietf.org> on behalf of "Ali Sajassi (sajassi)" <sajassi=40cisco....@dmarc.ietf.org> Date: Thursday, October 8, 2020 at 12:15 PM To: "John G. Scudder" <j...@juniper.net> Cc: "draft-ietf-bess-evpn-inter-subnet-forward...@ietf.org" <draft-ietf-bess-evpn-inter-subnet-forward...@ietf.org>, BESS <bess@ietf.org> Subject: Re: [bess] Second try: Router's MAC Extended Community in draft-ietf-bess-evpn-inter-subnet-forwarding Hi John, Thanks for your feedback. I was also thinking along the line of (2). I’ll take care of it in the next rev. soon. Cheers, Ali From: John Scudder <j...@juniper.net> Date: Thursday, October 8, 2020 at 11:57 AM To: Cisco Employee <saja...@cisco.com> Cc: "draft-ietf-bess-evpn-inter-subnet-forward...@ietf.org" <draft-ietf-bess-evpn-inter-subnet-forward...@ietf.org>, BESS <bess@ietf.org> Subject: Re: Second try: Router's MAC Extended Community in draft-ietf-bess-evpn-inter-subnet-forwarding Resent-From: <alias-boun...@ietf.org> Resent-To: Cisco Employee <saja...@cisco.com>, <ssa...@cisco.com>, <stho...@cisco.com>, <jdr...@juniper.net>, <jorge.raba...@nokia.com> Resent-Date: Thursday, October 8, 2020 at 11:57 AM Thanks, Ali. Yes, I think this should be explicit in the spec. I’d also suggest being explicit about what “ignore the rest” means. It could mean one of two things — 1. Don’t pay attention to the extra ones for purposes of computing the local forwarding table, but store them and propagate them. 2. Also don’t store or propagate them. I’m guessing option 2 is better in this case. The problem with propagating them is sometimes implementations reorder things, so you could end up with inconsistency in the network. —John On Oct 8, 2020, at 2:42 PM, Ali Sajassi (sajassi) <saja...@cisco.com<mailto:saja...@cisco.com>> wrote: Hi John, Sorry for the delay. The answer to your 1st question is no and the answer to your 2nd question is that the receiver should pick the first one in the list and ignore the rest. If it helps, I can add couple of lines to that affect to the corresponding section. Cheers, Ali From: John Scudder <j...@juniper.net<mailto:j...@juniper.net>> Date: Thursday, October 8, 2020 at 11:12 AM To: "draft-ietf-bess-evpn-inter-subnet-forward...@ietf.org<mailto:draft-ietf-bess-evpn-inter-subnet-forward...@ietf.org>" <draft-ietf-bess-evpn-inter-subnet-forward...@ietf.org<mailto:draft-ietf-bess-evpn-inter-subnet-forward...@ietf.org>> Cc: BESS <bess@ietf.org<mailto:bess@ietf.org>> Subject: Second try: Router's MAC Extended Community in draft-ietf-bess-evpn-inter-subnet-forwarding Resent-From: <alias-boun...@ietf.org<mailto:alias-boun...@ietf.org>> Resent-To: Cisco Employee <saja...@cisco.com<mailto:saja...@cisco.com>>, <ssa...@cisco.com<mailto:ssa...@cisco.com>>, <stho...@cisco.com<mailto:stho...@cisco.com>>, <jdr...@juniper.net<mailto:jdr...@juniper.net>>, <jorge.raba...@nokia.com<mailto:jorge.raba...@nokia.com>> Resent-Date: Thursday, October 8, 2020 at 11:12 AM Hi Authors, I haven’t seen a reply to this message from almost a month ago, trying again. Even if you are still debating the answer amongst yourselves, it would be comforting to me to receive a reply to the effect of “we’re still thinking about this and will get back to you by $date”. Thanks, —John Begin forwarded message: From: "John G. Scudder" <j...@juniper.net<mailto:j...@juniper.net>> Subject: Router's MAC Extended Community in draft-ietf-bess-evpn-inter-subnet-forwarding Date: September 10, 2020 at 9:27:31 AM EDT To: draft-ietf-bess-evpn-inter-subnet-forward...@ietf.org<mailto:draft-ietf-bess-evpn-inter-subnet-forward...@ietf.org> Cc: BESS <bess@ietf.org<mailto:bess@ietf.org>> Hi Authors, I just went through draft-ietf-bess-evpn-inter-subnet-forwarding to look for answers to two questions: 1. Can a router advertise multiple different Router’s MAC values? If yes, what is the receiver supposed to do? 2. Assuming the answer to question 1 is “no”, what is the receiver supposed to do if it receives multiple Router’s MAC Extended Communities (with different values) anyway, for example due to a bug or configuration error? This is a very real possibility since many BGP implementations allow policy to produce arbitrary communities. Thanks, —John
_______________________________________________ BESS mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
