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

[Jeffrey (Zhaohui) Zhang]

Hi Ali,

> >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."

I thought it was a given that the mac address in the ARP reply is the same as 
the mac address that the device uses when it routes a packet out of the IRB 
interface?

> >
> >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².

For conciseness, it may be better to simply remove 4.2 because of the reasons 
mentioned above.

> >
> >   ... 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.

I just realized that the spec only mentions a default route in the IP-VRF but 
it does not mention how it is advertised. Is it advertised as IP-VPN (SAFI 128) 
route or the unknown mac route in EVPN? If IP-VPN, there is only one such route 
and it is not tied to the destination subnet; if it is the unknown mac route, I 
assume it is one per subnet, but eventually only one is selected as active, and 
it may not be tied to the destination subnet? On the other hand, between the 
source NVE and its local GW, it does not really matter which subnet is used. 
The text should be clear though: a) how is the default route advertised; b) how 
is the traffic forwarded between the source NVE and its local GW - looks like 
only IP payload is needed (similar to the symmetric case)?

I looked at the updated 4.3 but the text is still confusing.

BTW - if an NVE/GW advertises an unknown mac route, when we install an IP route 
to the IP VRF, should we install subnet's prefix route instead of the default 
route?
BTW - I could not figure out in which draft the unknown mac route is defined. 
The virtual hub and spoke draft says:

   [I-D.EVPN-overlay] defines the notion of the unknown MAC route for an
   EVI which is analogous to a VPN-IP default route for a VPN.  

But the EVPN overlay draft does not have the details. It only  mentions unknown 
mac route.

> 
> >
> >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.

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

[Nabeel Cocker]

Support

Regards,
Nabeel

> On Feb 17, 2017, at 5:25 PM, Ali Sajassi (sajassi)  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"
>  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

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

[Jeffrey (Zhaohui) Zhang]

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.

Isn't requirement R1 covered by R2?

   This is an environment where all NVEs to which an EVPN instance could
   potentially be attached (or moved)

Strike the "(or moved)"?

>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? Also, what does 
"this default gateway" refer to? Each NVE's "own default gateway" or "the same 
conceptual gateway"?
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?

   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?

3.2 Heterogeneous Environment

   .. Even though policies
   among multiple subnets belonging to same tenant can be simpler,

s/simpler/simple/?

   ... 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".

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.

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.

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.

   ... 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? Also does that mean GW1 and GW2 must be attached to all 
subnets? 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, 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).

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.

4.5 Use of Centralized Gateway

   In this scenario, the NVEs