Re: [bess] WG Last Call for draft-ietf-bess-evpn-inter-subnet-forwarding-03

[Nabeel Cocker <[e-mail]>]

Support

Regards,
Nabeel

> On Feb 17, 2017, at 5:25 PM, Ali Sajassi (sajassi) <[e-mail]> 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"
> <[e-mail] on behalf of [e-mail]> 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:[e-mail]] On Behalf Of Martin Vigoureux
>>> Sent: Monday, February 13, 2017 5:07 PM
>>> To: BESS <[e-mail]>
>>> 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
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/bess
>> 
>> _______________________________________________
>> BESS mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/bess
> 
> <draft-ietf-bess-evpn-inter-subnet-forwarding-03.txt>
> _______________________________________________
> BESS mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/bess