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

From: Martin Vigoureux <[email-masked]>
Date: Mon, 13 Feb 2017 23:07:27 +0100

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-forwarding/
[2] https://mailarchive.ietf.org/arch/msg/bess/cG3X1tTqb_vPC4rg56SEdkjqDpw

---

From: "Rabadan, Jorge (Nokia - US)" <[email-masked]>
Date: Mon, 13 Feb 2017 22:15:59 +0000

I support this document, as a co-author, for publication as Standard RFC.
Not aware of any IPR.
Thanks.
Jorge

On 2/13/17, 11:07 PM, "BESS on behalf of Martin Vigoureux" <[email-masked] on behalf of [email-masked]> wrote:

    Hello Working Group,

    

    
    
    Thank you,
    M&T
    
    [1] 
    
    _______________________________________________
    BESS mailing list
    [email-masked]
    https://www.ietf.org/mailman/listinfo/bess

---

From: "Oya Luengo, Roberto (Nokia - US)" <[email-masked]>
Date: Mon, 13 Feb 2017 22:57:33 +0000

Support

---

From: "Satya Mohanty (satyamoh)" <[email-masked]>
Date: Mon, 13 Feb 2017 23:10:57 +0000

Support.

Thanks,
—Satya

---

From: "Henderickx, Wim (Nokia - BE)" <[email-masked]>
Date: Tue, 14 Feb 2017 03:22:15 +0000

Support doc as co-author for publication as standard RFC

On 14/02/2017, 00:15, "BESS on behalf of Rabadan, Jorge (Nokia - US)" <[email-masked] on behalf of [email-masked]> wrote:

    
        Hello Working Group,

        

        
        
        Thank you,
        M&T
        
        [1]

---

From: Jeff Tantsura <[email-masked]>
Date: Tue, 14 Feb 2017 02:23:49 -0800

yes/support
 
Cheers,
Jeff

        Hello Working Group,

        

        
        
        Thank you,
        M&T
        
        [1] 
________________

---

From: "Liu, Hua" <[email-masked]>
Date: Tue, 14 Feb 2017 15:35:24 +0000

Yes/Support

Regards,
Autumn        

            Hello Working Group,

            

            
            
            Thank you,
            M&T
            
            [1]

---

From: "Ali Sajassi (sajassi)" <[email-masked]>
Date: Tue, 14 Feb 2017 18:46:36 +0000

Support as co-auhtor. Not aware of any non-disclosed IPR.

Regards,
Ali

---

From: John E Drake <[email-masked]>
Date: Tue, 14 Feb 2017 19:06:45 +0000

Support and I'm not aware of any IPR

Yours Irrespectively,

John

> -----Original Message-----
> From: BESS [mailto:[email-masked]] On Behalf Of Martin Vigoureux
> Sent: Monday, February 13, 2017 5:07 PM
> To: BESS <[email-masked]>
> Subject: [bess] WG Last Call for draft-ietf-bess-evpn-inter-subnet-forwarding-03
> 
> Hello Working Group,
> 
> 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).
> 
> 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].

---

From: "Patrice Brissette (pbrisset)" <[email-masked]>
Date: Tue, 14 Feb 2017 19:07:32 +0000

I support. I’m not aware of any IPR at this point of time.

Regards,
Patrice Brissette

On 2017-02-13, 5:07 PM, "BESS on behalf of Martin Vigoureux" <[email-masked] on behalf of [email-masked]> wrote:

    Hello Working Group,

    

    
    
    Thank you,
    M&T
    
    [1]

---

From: "Jeffrey (Zhaohui) Zhang" <[email-masked]>
Date: Fri, 17 Feb 2017 18:42:47 +0000

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

I'll send a follow up email about the symmetric section.

Thanks.

Jeffrey

> [2]
> https://mailarchive.ietf.org/arch/msg/bess/cG3X1tTqb_vPC4rg56SEdkjqDpw
>

---

From: "Ali Sajassi (sajassi)" <[email-masked]>
Date: Fri, 17 Feb 2017 22:25:26 +0000

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-masked] on behalf of [email-masked]> 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.

>   potentially be attached (or moved)

OK.

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

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

>   among multiple subnets belonging to same tenant can be simpler,

Done.

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

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

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

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

>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

>> Subject: [bess] WG Last Call for
>>draft-ietf-bess-evpn-inter-subnet-forwarding-03
>> 
>> Hello Working Group,
>>

---

From: Nabeel Cocker <[email-masked]>
Date: Fri, 17 Feb 2017 23:53:29 -0500

Support

Regards,
Nabeel

> On Feb 17, 2017, at 5:25 PM, Ali Sajassi (sajassi) <[email-masked]> wrote:
> 
> Hi Jeffrey,
> 
> <draft-ietf-bess-evpn-inter-subnet-forwarding-03.txt>

---

From: Nabeel Cocker <[email-masked]>
Date: Fri, 17 Feb 2017 23:54:41 -0500

Support

Regards,
Nabeel

> On Feb 13, 2017, at 5:07 PM, Martin Vigoureux <[email-masked]> wrote:
> 
> 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.
> 
> 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).
> 
> 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-forwarding/

---

From: "Jeffrey (Zhaohui) Zhang" <[email-masked]>
Date: Sat, 18 Feb 2017 05:09:40 +0000

Hi Ali,

> interface MAC address MUST be the one used in the initial ARP reply for

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?

> Changed ³GW" in the diagram to ³ASBR².

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

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

> TTL decrement is given when IP lookup is performed at each hop.

True; my point is that when a router is connected to every subnet, routing would only happen once. In this case, routing happens twice even though every subnet is connected to every NVE.

Jeffrey

---

From: Eric C Rosen <[email-masked]>
Date: Mon, 20 Feb 2017 11:25:11 -0500

I have a number of comments on this draft.  I've attached a copy of the 
draft with comments in-line; look for lines beginning with "****".

I don't think the document is ready to advance at the present time.

Issues:

- Most of this document is a discussion of various Data Center use 
cases, with an informal discussion of how EVPN procedures could be used 
to get IP datagrams into or out of a DC.  A little bit of the document 
is the specification of EVPN protocols and procedures that is specific 
to inter-subnet-forwarding.  However, these two parts are not clearly 
separated.  This makes it very hard to know which parts of the document 
are normative (i.e., suitable for Proposed Standard status) and which 
are just use case descriptions (as one might find in an Informational 
document).  This really needs to be fixed; I don't see how one would 
expect interoperable implementations to result from this document.

- These seems to be an architectual model hidden here, in which 'IRB 
interfaces' connect IP-VRFs to Bridge Tables (or something). However, 
there doesn't seem to be a clear description of this model.

- The use cases discussed in section 4 (Asymmetric Forwarding) are 
different than the use cases in section 5 (Symmetric Forwarding). 
However, I don't think there is an implication that certain use cases 
require asymmetric forward and certain require symmetric forwarding.  
I'm really confused about how to interpret sections 4 and 5.

- It is not always clear whether the discussion of use cases is or is 
not intended to be normative.

- The sections discussing the use cases contain a lot of text that is 
repeated verbatim (or almost verbatim) from other sections. This makes 
almost impossible to see what is done differently for the different use 
cases.  I think this repeated text needs to be refactored or removed.

- The discussion of routing packets between an "EVPN domain" (my term) 
and the "outside world" (Internet, IPVPN, other EVPN domain) does not 
provide much information on how one actually makes that happen 
correctly.  (The only thing that is really covered is routing between 
two subnets of the same tenant; everything else seems like just a 
placeholder for sections that were never actually written).

- Much of the terminology is not precisely defined, and normative 
references are not given to documents where the terminology is defined.

- No attempt is made to use a consistent set of terms.  This often 
leaves on wondering: "it says 'Broadcast Domain' here, it says 'subnet' 
there, it says 'MAC-VRF' in the other place, are these terms being used 
interchangeably, or is there some difference that needs to be attended 
to?".

- In a number of places, there seems to be a presupposition that an EVI 
contains one Broadcast Domain.  This is not true for all the variants of 
EVPN service.

In order for this document to advance, I think it needs the following:

- Decide whether it is a protocol spec or an applicability guide. If 
both, separate the normative from the descriptive part in a clear way.

- Clarify the architectural model.

- Eliminate the large sections of repeated text.

- Tighten up the terminology.

- Eliminate the sections that don't really say anything (e.g., the 
sections on routing between an IPVPN and an EVPN, the section on 
mobility).  Alternatively, provide content.

Having said all that, I would like to see this document go forward, but 
I don't think it is ready.

More comments in the attachment.

---

From: "Ali Sajassi (sajassi)" <[email-masked]>
Date: Tue, 21 Feb 2017 07:11:55 +0000

Hi Jeffrey,

My comments in line ...

On 2/17/17, 9:09 PM, "Jeffrey (Zhaohui) Zhang" <[email-masked]> wrote:

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

No, it not that simple if there is no ARP request upon a MAC move! VM1
with (MAC1, IP1) first appears behind PE1 with IRB-x (MAC-x, and IP-x).
Then it moves to PE2 with IRB―y (MAC-y, IP-x). The VM1 move may not
trigger an ARP request. So, the packets from the VM1 with MAC-DA of MAC-x
need to aliased to IRB-y. In the reverse direction, the packets from PE2
to VM1 will typically have MAC-SA as MAC-y (IRB interface of PE2);
however, if VM1 expects to receive packets with MAC-SA as MAC-x (for MAC
sec. application), then PE2 needs to use the MAC address of IRB-x (on PE1)
which is the MAC address of “initial ARP” initiated by PE1.

>For conciseness, it may be better to simply remove 4.2 because of the

It is a different scenario than 4.1 and thus deserves different
explanation. I may make reference 4.1 and remove duplicate texts.

>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)?

We need to look at this scenario with respect to both NVE and GW:
From NVE perspective, the inter-subnet traffic within its own DC, is
handle based on section 4.1. For inter-DC inter-subnet traffic, it is
handled similar to symmetric IRB case.
From GW perspective, the inter-subnet traffic between the GW is handled
based on asymmetric IRB of 4.1.
I will add some additional explanation.

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

GW should advertise default route to NVE - ie, in this scenario we want
the NVE only maintain routes for their own DC and not any other DCs.

>BTW - I could not figure out in which draft the unknown mac route is
>defined. The virtual hub and spoke draft says:
>

I’ll add the reference for unknown MAC route.

>True; my point is that when a router is connected to every subnet,
>routing would only happen once. In this case, routing happens twice even
>though every subnet is connected to every NVE.

It happens twice (one on the ingress NVE and another on the ingress GW).
The reason it happens twice is the ingress NVE only has default route to
ingress GW for all routes from other DCs.

Cheers,
Ali

---

From: "Jeffrey (Zhaohui) Zhang" <[email-masked]>
Date: Tue, 21 Feb 2017 19:26:56 +0000

Hi Ali,

Please see below.

> From: Ali Sajassi (sajassi) [mailto:[email-masked]]
> Sent: Tuesday, February 21, 2017 2:12 AM
> To: Jeffrey (Zhaohui) Zhang <[email-masked]>; Martin Vigoureux
> <[email-masked]>; BESS <[email-masked]>
> Subject: Re: [bess] WG Last Call for draft-ietf-bess-evpn-inter-subnet-
> forwarding-03
> 
> 
> Hi Jeffrey,
> 
> My comments in line ...
> 

When PE1 did the initial ARP reply, it would not go to PE2, right? How does PE know to use IRB-x after the MAC move?
Does that mean that the 2nd option can't be used after all? That's fine as long as it is clearly explained.

> I will add some additional explanation.

Yes this is an important clarification.

> I’ll add the reference for unknown MAC route.

Please include the details like how the default route is advertised. It is not clear whether it is via the unknown mac route. If yes, in theory, the unknown mac route should encode the BD's subnet address in the IP part?

Thanks.
Jeffrey

---

From: "Jeffrey (Zhaohui) Zhang" <[email-masked]>
Date: Wed, 22 Feb 2017 14:44:02 +0000

Questions/comments for the symmetric  model:

  Each NVE advertises an RT-2 route with two Route Targets (one
   corresponding to its MAC-VRF and the other corresponding to its IP-
   VRF. Furthermore, the RT-2 is advertised with two BGP Extended
   Communities. The first BGP Extended Community identifies the tunnel
   type per section 4.5 of [TUNNEL-ENCAP] and the second BGP Extended
   Community includes the MAC address of the NVE (e.g., MACx for NVE1 or
   MACy for NVE2) as defined in section 6.1.

Is the first EC needed for MPLS encapsulation? For intra-subnet forwarding using MPLS, there is no need for such EC; inter-subnet should not be different in that regard?

   In this symmetric IRB scenario, inter-subnet traffic between NVEs
   will always use the IP-VRF VNID/MPLS label. For instance, traffic
   from TS2 to TS4 will be encapsulated by NVE1 using NVE2's IP-VRF
   VNID/MPLS label, as long as TS4's host IP is present in NVE1's IP-
   VRF.

Because IP-VRF VNID/MPLS label is always used and IP lookup is done after removing the Ethernet header, the Ethernet header is really not useful? while with vxlan the ether header is always present, do we really need to signal the egress NVE's system mac address and put it in the ether header (since the header is not used to identify the IP VRF anywaty)? If this is because of certain hardware property (i.e., with vxlan certain chips always look up dst mac first no matter what), then it should be made clear. If the egress NVE does require a valid system mac address of its own is required, it can signal that via the EC; otherwise it does not have to and the ingress NVE should be free to put anything in the ether header?

5.2 IRB forwarding on NVEs for Subnets behind Tenant Systems

Should this section be moved to the prefix-advertisement draft?

Jeffrey