Support Regards, Nabeel
> On Feb 17, 2017, at 5:25 PM, Ali Sajassi (sajassi) <[email protected]> wrote: > > Hi Jeffrey, > > Thanks for your comments, please refer inline for my responses ... > > On 2/17/17, 10:42 AM, "BESS on behalf of Jeffrey (Zhaohui) Zhang" > <[email protected] on behalf of [email protected]> wrote: > >> Hi, >> >> I have the following nits/questions/comments. This email is only about >> the asymmetric section - I may send another one about symmetric section. >> >> "inter-subnet switching" is confusing. Shouldn't it be "inter-subnet >> routing" instead of "intra-subnet switching"? While it's EVPN aware, it >> still goes through routing first. > > The term ³switching² applies to both L2 and L3; whereas, the term > ³bridging² applies to only L2 and the term ³routing² applies to only L3. > >> >> Isn't requirement R1 covered by R2? > > Yup, will remove R1. > >> >> This is an environment where all NVEs to which an EVPN instance could >> potentially be attached (or moved) >> >> Strike the "(or moved)"? > > OK. > >> >>> From RFC 7432: >> >> 10.1. Default Gateway >> ... >> The IP Address field of the MAC/IP Advertisement route is set to the >> default gateway IP address for that subnet (e.g., an EVPN instance). >> For a given subnet (e.g., a VLAN or EVPN instance), the default >> gateway IP address is the same across all the participant PEs. The >> inclusion of this IP address enables the receiving PE to check its >> configured default gateway IP address against the one received in the >> MAC/IP Advertisement route for that subnet (or EVPN instance), and if >> there is a discrepancy, then the PE SHOULD notify the operator and >> log an error message. >> >> This draft: >> >> 2. Each NVE of a given EVPN instance uses its own default gateway IP >> and MAC addresses, and these addresses are aliased to the same >> conceptual gateway through the use of the Default Gateway extended >> community as specified in [EVPN], which is carried in the EVPN MAC >> Advertisement routes. On each NVE, this default gateway IP/MAC >> address correspond to the IRB interface connecting the MAC-VRF of >> that EVI to the corresponding IP-VRF. >> >> The above 2nd model seems to be conflicting with RFC 7432? > > > Thanks for catching it. The 2nd case is supposed to be ³the same IP > anycast address but different MAC addresses" - ie, the two use cases in > this draft correspond to the two uses cases in section 10.1 of RFC 7432. > So, the new text reads as follow: > > ³2. Each NVE of a given EVPN instance uses the same anycast default > gateway IP address but its own MAC address. These MAC addresses are > aliased to the same anycast default gateway IP address through the use of > the Default Gateway extended community as specified in [EVPN], which is > carried in the EVPN MAC/IP Advertisement routes. On each NVE, this default > gateway IP address along with its associated MAC addresses correspond to > the IRB interface connecting the MAC-VRF of that EVI to the corresponding > IP-VRF.² > > >> Also, what does "this default gateway" refer to? Each NVE's "own default >> gateway" or "the same conceptual gateway"? > > Default gateway with respect to TS¹s as mentioned in the 2nd para of > section 3.1 > > >> Is it that besides their own default gateway, an additional common >> gateway is advertised using that extended community? If so, what's the >> purpose to call those different IP addresses on the IRB interfaces >> "default gateway"? I assume the hosts will be using the common gateway >> address? > > This comment should be already addressed by above clarification. > >> >> It is worth noting that if the applications that are running on the >> TS's are employing or relying on any form of MAC security, then the >> first model (i.e. using anycast addresses) would be required to >> ensure that the applications receive traffic from the same source MAC >> address that they are sending to. >> >> Why is that? As long as an NVE changes the source MAC to the one it sends >> in the ARP reply, it should work even with the 2nd model? > > If it changes, yes but if it doesn¹t change it, it creates issue for MAC > security. Modified the paragraph to provide further clarification: > > "It is worth noting that if the applications that are running on the TS's > are employing or relying on any form of MAC security, then either the > first model (i.e. using anycast MAC address) should be used to ensure that > the applications receive traffic from the same IRB interface MAC address > that they are sending to, or if the second model is used, then the IRB > interface MAC address MUST be the one used in the initial ARP reply for > that TS." > > >> >> 3.2 Heterogeneous Environment >> >> .. Even though policies >> among multiple subnets belonging to same tenant can be simpler, >> >> s/simpler/simple/? > > Done. > >> >> ... Therefore, there can be a mixed environment where an NVE >> performs inter-subnet switching for some EVPN instances and the L3GW >> for others. >> >> For the above sentence, it helps a lot if the last part reads "and the >> L3GW performs inter-subnet switching for other EVPN instances". > > Done. > >> >> 4.1 Among EVPN NVEs within a DC >> >> ... It also rewrites the source MAC address with its IRB >> Interface MAC address. >> >> Need to make it clear that the above mentioned IRB interface is for the >> destination subnet. Same issue in 4.2. > > Changed it to: > > "It also rewrites the source MAC address with its IRB Interface MAC > address for the destination subnet.² > >> >> For section 4.2, the processing on the ingress and egress NVE is no >> different from 4.1; the processing on the ASBRs is vanilla EVPN >> forwarding and not specific to inter-subnet forwarding at all; therefore, >> 4.2 is not really needed? Additionally, the section is about "w/o GW", >> yet the text talks about ingress/egress Gateway. It's better to replace >> Gateway with ASBRs. > > Changed ³GW" in the diagram to ³ASBR². > >> >> 4.3 Among EVPN NVEs in Different DCs with GW >> >> ... It also rewrites the >> source MAC address with its own IRB Interface MAC address. >> >> Similar to 4.1, the above needs to be clear that it's the IRB interface >> for the subnet between the NVE and the GW. More below on this. > > Done. Added "for the destination subnet (i.e., the subnet between NVE1 and > GW1)." > >> >> ... This implies that the GW1 needs to keep the remote >> host MAC addresses along with the corresponding EVPN labels in the >> adjacency entries of the IP-VRF table (i.e., its ARP table). >> >> Does that mean GW1 needs to keep all type-2 IP/MAC addresses that GW2 >> learns from NVEs in DC2? > > Yes it does. > >> Also does that mean GW1 and GW2 must be attached to all subnets? > > That¹s correct. > >> If so, between the source NVE and its local GW, when the source NVE >> route the traffic to the GW, I assume it's the destination subnet's IRB >> interface's mac address that will be used as the source mac address, > > Correct. It is NVE1¹s destination subnet¹s IRB interface MAC address. > >> and GW1's IRB mac address for the destination subnet is used as the dst >> mac address. It is true that an NVE may have the same system mac address >> for all its IRB interfaces, but it's good to point out which IRB is used >> (and if different IRB mac address is used, things will still work out). > > I update the section 4.3. Please take a look at it (refer to the > attachment) and let me know if you have any further comments. > >> >> Also, while each subnet is attached to each NVE, the IP routing process >> (e.g. TTL decrement) happens twice - first on the source NVE and then on >> the source GW. That's probably OK, but better point out all these details. > > TTL decrement is given when IP lookup is performed at each hop. > >> >> 4.5 Use of Centralized Gateway >> >> In this scenario, the NVEs within a given data center need to forward >> traffic in L2 to a centralized L3GW for a number of reasons: a) they >> don't have IRB capabilities or b) they don't have required policy for >> switching traffic between different tenants or security zones. >> >> For b), do we configure IRB on those non-centralized gateways at all? I >> assume not (even though the NVE could support IRB) - It's better to be >> clear. > > Yes, no IRB configuration. I added a sentence. > >> >> I'll send a follow up email about the symmetric section. > > OK. It sounds good. > > Cheers, > Ali > >> >> Thanks. >> >> Jeffrey >> >>> -----Original Message----- >>> From: BESS [mailto:[email protected]] On Behalf Of Martin Vigoureux >>> Sent: Monday, February 13, 2017 5:07 PM >>> To: BESS <[email protected]> >>> Subject: [bess] WG Last Call for >>> draft-ietf-bess-evpn-inter-subnet-forwarding-03 >>> >>> Hello Working Group, >>> >>> This email starts a Working Group Last Call on >>> draft-ietf-bess-evpn-inter-subnet-forwarding-03 [1] which is considered >>> mature and ready for a final working group review. >>> Note that this call is longer than usual because we are pushing two >>> correlated documents together. >>> >>> Please read this document if you haven't read the most recent >>> version yet, and send your comments to the list, no later than >>> *5th of March*. >>> Note that this is *not only* a call for comments on the document; it is >>> also a call for support (or not) to publish this document as a Proposed >>> Standard RFC. >>> >>> *Coincidentally*, we are also polling for knowledge of any IPR that >>> applies to draft-ietf-bess-evpn-inter-subnet-forwarding, to ensure that >>> IPR has been disclosed in compliance with IETF IPR rules (see RFCs 3979, >>> 4879, 3669 and 5378 for more details). >>> >>> *If* you are listed as a document author or contributor of >>> draft-ietf-bess-evpn-inter-subnet-forwarding-03 please respond to this >>> email and indicate whether or not you are aware of any relevant IPR. >>> >>> Note that, as of today, no IPR has been disclosed against this document >>> or its earlier versions. >>> >>> We are also polling for knowledge of implementations of part or all of >>> what this document specifies. This information is expected as per [2]. >>> Please inform the mailing list, or the chairs, or only one of the >>> chairs. >>> >>> Thank you, >>> M&T >>> >>> [1] >>> >>> https://datatracker.ietf.org/doc/draft-ietf-bess-evpn-inter-subnet-forwar >>> ding/ >>> [2] >>> https://mailarchive.ietf.org/arch/msg/bess/cG3X1tTqb_vPC4rg56SEdkjqDpw >>> >>> _______________________________________________ >>> BESS mailing list >>> [email protected] >>> https://www.ietf.org/mailman/listinfo/bess >> >> _______________________________________________ >> BESS mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/bess > > <draft-ietf-bess-evpn-inter-subnet-forwarding-03.txt> > _______________________________________________ > BESS mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/bess _______________________________________________ BESS mailing list [email protected] https://www.ietf.org/mailman/listinfo/bess
