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

"Ali Sajassi (sajassi)" <sajassi@cisco.com> Tue, 21 February 2017 07:11 UTC

Return-Path: <sajassi@cisco.com>
X-Original-To: bess@ietfa.amsl.com
Delivered-To: bess@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 71E6B129872 for <bess@ietfa.amsl.com>; Mon, 20 Feb 2017 23:11:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -14.522
X-Spam-Level:
X-Spam-Status: No, score=-14.522 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, RP_MATCHES_RCVD=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cisco.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P6_Olp6KJWzm for <bess@ietfa.amsl.com>; Mon, 20 Feb 2017 23:11:58 -0800 (PST)
Received: from alln-iport-7.cisco.com (alln-iport-7.cisco.com [173.37.142.94]) (using TLSv1.2 with cipher DHE-RSA-SEED-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 350F31293EC for <bess@ietf.org>; Mon, 20 Feb 2017 23:11:58 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9796; q=dns/txt; s=iport; t=1487661118; x=1488870718; h=from:to:subject:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=UXykYya82oVlQoFhcMiO7l9A3byt2XMM5TqHHX0Yh5s=; b=PwFF3NUoopi/JhL6V155YBXkfuAGDWVtj5Sy9bnEpFksaXpj9n1OuH71 CuKu6JbdIiYSuui8EvtcSs3gbIRibBZNwnaSuHLrQ8tER8WQyWpWcHalP iRbgSUjCADCom7RWFh7RA9G11fgXKTNr0omry7QSawp5dOPL474Cz/Lhy o=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: A0BSAQCT56tY/4MNJK1eGQEBAQEBAQEBAQEBBwEBAQEBg1GBageDVIoIp0qCDYYiAhqCPD8YAQIBAQEBAQEBYiiEcQYdF1UCAQgcKAICMCUCBAESFIlakEqdUAaCKItYAQEBAQEBAQECAQEBAQEBASGBBYo2hFSDAIJlBZwIAZIcgXuFG4l4iDSKbwEfOIEAUxWFDRiBYXWKA4ENAQEB
X-IronPort-AV: E=Sophos;i="5.35,188,1484006400"; d="scan'208";a="388215943"
Received: from alln-core-1.cisco.com ([173.36.13.131]) by alln-iport-7.cisco.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 21 Feb 2017 07:11:57 +0000
Received: from XCH-RTP-005.cisco.com (xch-rtp-005.cisco.com [64.101.220.145]) by alln-core-1.cisco.com (8.14.5/8.14.5) with ESMTP id v1L7BuLO027496 (version=TLSv1/SSLv3 cipher=AES256-SHA bits=256 verify=FAIL); Tue, 21 Feb 2017 07:11:57 GMT
Received: from xch-rtp-005.cisco.com (64.101.220.145) by XCH-RTP-005.cisco.com (64.101.220.145) with Microsoft SMTP Server (TLS) id 15.0.1210.3; Tue, 21 Feb 2017 02:11:56 -0500
Received: from xch-rtp-005.cisco.com ([64.101.220.145]) by XCH-RTP-005.cisco.com ([64.101.220.145]) with mapi id 15.00.1210.000; Tue, 21 Feb 2017 02:11:56 -0500
From: "Ali Sajassi (sajassi)" <sajassi@cisco.com>
To: "Jeffrey (Zhaohui) Zhang" <zzhang@juniper.net>, Martin Vigoureux <martin.vigoureux@nokia.com>, BESS <bess@ietf.org>
Thread-Topic: [bess] WG Last Call for draft-ietf-bess-evpn-inter-subnet-forwarding-03
Thread-Index: AQHSiU2rYnFxtyJTk0iiZtg+5MhcyaFtlI+AgAD3EQCABFMIgA==
Date: Tue, 21 Feb 2017 07:11:55 +0000
Message-ID: <D4D08BF1.1CC281%sajassi@cisco.com>
References: <89d9ab4e-309f-d7f5-a2b7-ac79a663618b@nokia.com> <DM5PR05MB314525CD2AF52FA0A0FA6848D45D0@DM5PR05MB3145.namprd05.prod.outlook.com> <D4CC888A.1CBFC2%sajassi@cisco.com> <MWHPR05MB3151542E2BE28AFC77B5AD36D45C0@MWHPR05MB3151.namprd05.prod.outlook.com>
In-Reply-To: <MWHPR05MB3151542E2BE28AFC77B5AD36D45C0@MWHPR05MB3151.namprd05.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/14.7.0.161029
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.19.76.56]
Content-Type: text/plain; charset="euc-kr"
Content-ID: <E7C2371EFD887D43AB12956017BCF4E8@emea.cisco.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/bess/w5SEWfQPVDJDj6bDaA4T6mAW5KU>
Subject: Re: [bess] WG Last Call for draft-ietf-bess-evpn-inter-subnet-forwarding-03
X-BeenThere: bess@ietf.org
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: BGP-Enabled ServiceS working group discussion list <bess.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/bess>, <mailto:bess-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/bess/>
List-Post: <mailto:bess@ietf.org>
List-Help: <mailto:bess-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/bess>, <mailto:bess-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 21 Feb 2017 07:11:59 -0000

Hi Jeffrey,

My comments in line ...

On 2/17/17, 9:09 PM, "Jeffrey (Zhaohui) Zhang" <zzhang@juniper.net> wrote:

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

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

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

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

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.

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

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

I’ll add the reference for 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.
>
>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

>
>Jeffrey
>