RE: MAC route with IP
Jakob Heitz <jakob.heitz@ericsson.com> Tue, 13 May 2014 23:26 UTC
Return-Path: <jakob.heitz@ericsson.com>
X-Original-To: l2vpn@ietfa.amsl.com
Delivered-To: l2vpn@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1])
by ietfa.amsl.com (Postfix) with ESMTP id AB69F1A0205
for <l2vpn@ietfa.amsl.com>; Tue, 13 May 2014 16:26:30 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Level:
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5
tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_PASS=-0.001]
autolearn=ham
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 C5r-ns9Lqsik for <l2vpn@ietfa.amsl.com>;
Tue, 13 May 2014 16:26:26 -0700 (PDT)
Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65])
by ietfa.amsl.com (Postfix) with ESMTP id D18F11A01E5
for <l2vpn@ietf.org>; Tue, 13 May 2014 16:26:25 -0700 (PDT)
X-AuditID: c6180641-f799b6d000000b0f-8a-537258536404
Received: from EUSAAHC002.ericsson.se (Unknown_Domain [147.117.188.78])
by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id
10.7A.02831.35852735; Tue, 13 May 2014 19:37:24 +0200 (CEST)
Received: from EUSAAMB109.ericsson.se ([147.117.188.126]) by
EUSAAHC002.ericsson.se ([147.117.188.78]) with mapi id 14.03.0174.001; Tue,
13 May 2014 19:26:17 -0400
From: Jakob Heitz <jakob.heitz@ericsson.com>
To: "Ali Sajassi (sajassi)" <sajassi@cisco.com>, "l2vpn@ietf.org"
<l2vpn@ietf.org>
Subject: RE: MAC route with IP
Thread-Topic: MAC route with IP
Thread-Index: Ac9tnTVAaQfHHQKqR0C1MGMVDrT48///65IA///deaD//7hWkIACA6eA//8w+kAAMBG6gP//3aLA///WaoD//yEw4A==
Date: Tue, 13 May 2014 23:26:16 +0000
Message-ID: <2F3EBB88EC3A454AAB08915FBF0B8C7E03056935@eusaamb109.ericsson.se>
References: <2F3EBB88EC3A454AAB08915FBF0B8C7E03055FE7@eusaamb109.ericsson.se>
<CF979A14.D39CB%sajassi@cisco.com>
In-Reply-To: <CF979A14.D39CB%sajassi@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [147.117.188.10]
Content-Type: multipart/alternative;
boundary="_000_2F3EBB88EC3A454AAB08915FBF0B8C7E03056935eusaamb109erics_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrJLMWRmVeSWpSXmKPExsUyuXSPn25IRFGwwbWNHBaPvx1it3h3tpnF
gcljyu+NrB5LlvxkCmCK4rJJSc3JLEst0rdL4Mr4/H4zc8H7/UwV3V/NGhj7ZjN1MXJySAiY
SLxYsQrKFpO4cG89WxcjF4eQwFFGibafd6Cc5YwSz6fMZAWpYhPQkfh2vYsZxBYRCJE43dfC
CGIzC5hJdN6czA5iCwvISXzuOMoEUSMv0fhjLSuEnSUxbdMqNhCbRUBVYvPBdUA1HBy8Ar4S
c74WgYSFBIokzp5YAdbKKaAvcWHDX7CRjEDHfT+1hglilbjErSfzoY4WkFiy5zwzhC0q8fLx
P1YIW0li0tJzrBD1+RKfe/ewgNi8AoISJ2c+YZnAKDoLyahZSMpmISmDiOtILNj9iQ3C1pZY
tvA1M4x95sBjJmTxBYzsqxg5SotTy3LTjQw3MQLj6pgEm+MOxgWfLA8xCnAwKvHwJqoWBQux
JpYVV+YeYpTmYFES503/FBssJJCeWJKanZpakFoUX1Sak1p8iJGJg1OqgVGacW363uCOU8pr
2fc/vHlE5kZY0vsds4rCDv9RFXy6+8Ss6UFpHV4HulwZBI0Ofv5VO+mJxmaJpRlz1RkzMyLK
NbbYyzWfka6Z+e1n0XsVh1O2VpdY0r0qXstVKE9KFrgVeW+lfZ3bj/tNNpMjqzgWRKiJB2dm
TdWdeOhSqFr3n/QvZz14diqxFGckGmoxFxUnAgBmV8bzjAIAAA==
Archived-At: http://mailarchive.ietf.org/arch/msg/l2vpn/5RBgpPzVmiJmgllC0tirXexr0RU
Cc: Antoni Przygienda <antoni.przygienda@ericsson.com>
X-BeenThere: l2vpn@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Layer 2 Virtual Private Networks <l2vpn.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/l2vpn>,
<mailto:l2vpn-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/l2vpn/>
List-Post: <mailto:l2vpn@ietf.org>
List-Help: <mailto:l2vpn-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/l2vpn>,
<mailto:l2vpn-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 13 May 2014 23:26:30 -0000
Thanks Ali. I recognize the case where a MAC only route is not needed. My text does not preclude that. My text is advisory to avoid the small time of flooding in an unlikely scenario. I do recognize that it is not necessary to ensure correctness of the draft. With that: I have studied the draft and consider it ready for publication. Thanks, Jakob. From: Ali Sajassi (sajassi) [mailto:sajassi@cisco.com] Sent: Tuesday, May 13, 2014 10:01 AM To: Jakob Heitz; l2vpn@ietf.org Cc: Antoni Przygienda Subject: Re: MAC route with IP I can understand that if route reflector receives different routes from different speakers, then it can re-order them. But we are talking about different routes from the same speaker (same BGP session and TCP/IP connection). In your scenario below, the if the MAC is learned via data-plane learning, then the sender has already sent a MAC-only advertisement anyway, so there is no issue. There can be scenarios in which both MAC/IP and MAC-only routes are advertise for the same MAC and there are scenarios where only MAC/IP routes are advertised. I don't want to constrain the solution unnecessarily by saying that MAC-only route must be accompanied with MAC/IP route. Again, I am not precluding what you are saying. I just don't want to make it a requirement. Cheers, Ali From: Jakob Heitz <jakob.heitz@ericsson.com<mailto:jakob.heitz@ericsson.com>> Date: Tuesday, May 13, 2014 9:43 AM To: Cisco Employee <sajassi@cisco.com<mailto:sajassi@cisco.com>>, "l2vpn@ietf.org<mailto:l2vpn@ietf.org>" <l2vpn@ietf.org<mailto:l2vpn@ietf.org>> Cc: Antoni Przygienda <antoni.przygienda@ericsson.com<mailto:antoni.przygienda@ericsson.com>> Subject: RE: MAC route with IP Then if a sender withdraws a MAC/IP route, say because the ARP cache timed out, but the MAC is still known, it must send a MAC only route before it withdraws the MAC/IP route. Now, because route reflectors can reorder route advertisements (but not announce/withdraw of the same route), the receiver can receive the withdrawal of the MAC/IP before it receives the announcement of the MAC only. To prevent this glitch, I propose Whenever a PE advertises one or more MAC advertisement routes with IP address for a particular MAC address, it MUST also advertise one MAC advertisement route without an IP address for that MAC address. Thanks, Jakob. From: Ali Sajassi (sajassi) [mailto:sajassi@cisco.com] Sent: Tuesday, May 13, 2014 9:35 AM To: Jakob Heitz; l2vpn@ietf.org<mailto:l2vpn@ietf.org> Cc: Antoni Przygienda Subject: Re: MAC route with IP Jakob, If there is no MAC-only route, then it is fine as well - e.g., we don't need the MAC-only route for the MAC/IP route to work. If there is only MAC/IP route, the FIB entry will be populated based on that route and if it is withdrawn, then FIB entry gets deleted. However, if there are both MAC/IP route and MAC-only route, and one of them gets withdrawn, then the FIB entry will still exist. This is the correct behavior. Cheers, Ali From: Jakob Heitz <jakob.heitz@ericsson.com<mailto:jakob.heitz@ericsson.com>> Date: Tuesday, May 13, 2014 9:28 AM To: Cisco Employee <sajassi@cisco.com<mailto:sajassi@cisco.com>>, "l2vpn@ietf.org<mailto:l2vpn@ietf.org>" <l2vpn@ietf.org<mailto:l2vpn@ietf.org>> Cc: Antoni Przygienda <antoni.przygienda@ericsson.com<mailto:antoni.przygienda@ericsson.com>> Subject: RE: MAC route with IP My concern is not that a MAC/IP withdrawal might delete a MAC only route. It is that there might not be a MAC only route there at all. Thanks, Jakob. From: Ali Sajassi (sajassi) [mailto:sajassi@cisco.com] Sent: Monday, May 12, 2014 11:21 PM To: Jakob Heitz; l2vpn@ietf.org<mailto:l2vpn@ietf.org> Cc: Antoni Przygienda Subject: Re: MAC route with IP Jakob, Antoni: Agreed that the ARP entries can timeout independent from the MAC table and thus the entries in MAC-VRF and ARP table can be deleted independent of each other. However, the existing text is still accurate. It already covers the scenario that is interest to you where there are multiple IP/MAC pair advertisement for a given MAC plus MAC-only advertisement. In such case, the withdraw of a IP/MAC pair will remove the corresponding IP/MAC entry in the ARP table but it doesn't remove the MAC entry in the MAC-VRF table. I added the following couple of sentences to the end of 2nd para of section 10 for further clarification: "If the receiving PE has already received a MAC-only advertisement for MACx in addition to the IPx/MACx advertisement, then when it receives a withdraw message for the IPx/MACx, it MUST delete the corresponding entry from the ARP table. However, it MUST not delete the MACx entry from the MAC-VRF table unless it receives a withdraw message for MACx only." Cheers, Ali From: Jakob Heitz <jakob.heitz@ericsson.com<mailto:jakob.heitz@ericsson.com>> Date: Sunday, May 11, 2014 10:59 PM To: Jakob Heitz <jakob.heitz@ericsson.com<mailto:jakob.heitz@ericsson.com>>, Cisco Employee <sajassi@cisco.com<mailto:sajassi@cisco.com>>, "l2vpn@ietf.org<mailto:l2vpn@ietf.org>" <l2vpn@ietf.org<mailto:l2vpn@ietf.org>> Cc: Antoni Przygienda <antoni.przygienda@ericsson.com<mailto:antoni.przygienda@ericsson.com>> Subject: RE: MAC route with IP People clear ARP caches when they get too big. When that happens, the bridge table may not be cleared at the same time or at all. An ARP cache may have a different timeout than the bridge table. A bridge can snoop ARP messages to learn bindings and those bindings can time out. However, many other packets can come from the same MAC address, keeping the MAC alive in the bridge table. In this case, the MAC-IP binding will be lost without the MAC address itself being lost. IP-MAC bindings can be learnt other than by snooping ARPs, by configuration, for example. Such configurations can be removed. Cheers, Jakob. From: L2vpn [mailto:l2vpn-bounces@ietf.org] On Behalf Of Jakob Heitz Sent: Sunday, May 11, 2014 10:39 PM To: Ali Sajassi (sajassi); l2vpn@ietf.org<mailto:l2vpn@ietf.org> Cc: Antoni Przygienda Subject: RE: MAC route with IP When the IP address is dissociated with the MAC address, but the MAC address still exits. Cheers, Jakob. From: Ali Sajassi (sajassi) [mailto:sajassi@cisco.com] Sent: Sunday, May 11, 2014 10:34 PM To: Jakob Heitz; l2vpn@ietf.org<mailto:l2vpn@ietf.org> Cc: Antoni Przygienda Subject: Re: MAC route with IP Hi Jakob, I believe the currency text is correct and sufficient. What use case do you have in mind? EVPN PE devices that only do L2 (w/ flooding), only advertise MAC route (w/o IP address) and EVPN PE devices that do L2 w/ ARP suppression, advertise both MAC and IP. In the latter case, if there are several IP addresses map to the same MAC address, then the MAC address from MAC-VRF only gets removed, when there is no more ARP entry with that MAC address. Cheers, Ali From: Jakob Heitz <jakob.heitz@ericsson.com<mailto:jakob.heitz@ericsson.com>> Date: Sunday, May 11, 2014 9:56 PM To: "l2vpn@ietf.org<mailto:l2vpn@ietf.org>" <l2vpn@ietf.org<mailto:l2vpn@ietf.org>> Cc: Antoni Przygienda <antoni.przygienda@ericsson.com<mailto:antoni.przygienda@ericsson.com>> Subject: MAC route with IP We have another issue In section 10: ARP and ND, the draft says: If there are multiple IP addresses associated with a MAC address, then multiple MAC advertisement routes MUST be generated, one for each IP address. For instance, this may be the case when there are both an IPv4 and an IPv6 address associated with the MAC address. When the IP address is dissociated with the MAC address, then the MAC advertisement route with that particular IP address MUST be withdrawn. If such a route is withdrawn and no MAC route without IP exists, then the MAC address will be forgotten. Therefore, we would like to add a sentence: Whenever a PE advertises one or more MAC advertisement routes with IP address for a particular MAC address, it MUST also advertise one MAC advertisement route without an IP address for that MAC address. Thanks, Jakob.
- MAC route with IP Jakob Heitz
- Re: MAC route with IP Ali Sajassi (sajassi)
- RE: MAC route with IP Jakob Heitz
- Re: MAC route with IP Ali Sajassi (sajassi)
- RE: MAC route with IP Jakob Heitz
- RE: MAC route with IP Antoni Przygienda
- Re: MAC route with IP Ali Sajassi (sajassi)
- RE: MAC route with IP Antoni Przygienda
- Re: MAC route with IP Ali Sajassi (sajassi)
- RE: MAC route with IP Jakob Heitz
- Re: MAC route with IP Ali Sajassi (sajassi)
- Re: MAC route with IP Ali Sajassi (sajassi)
- RE: MAC route with IP Jakob Heitz
- Re: MAC route with IP Ali Sajassi (sajassi)
- RE: MAC route with IP Jakob Heitz
- RE: MAC route with IP Jakob Heitz
- RE: MAC route with IP Antoni Przygienda
- Re: MAC route with IP Ali Sajassi (sajassi)
- RE: MAC route with IP Jakob Heitz
- Re: MAC route with IP Rabadan, Jorge (Jorge)
- RE: MAC route with IP Jakob Heitz
- Re: MAC route with IP Ali Sajassi (sajassi)
- Re: MAC route with IP Rabadan, Jorge (Jorge)
- RE: MAC route with IP John E Drake
- RE: MAC route with IP John E Drake
- Re: MAC route with IP Ali Sajassi (sajassi)
- Re: MAC route with IP Rabadan, Jorge (Jorge)
- Re: MAC route with IP Aldrin Isaac
- Re: MAC route with IP Ali Sajassi (sajassi)
- RE: MAC route with IP Jakob Heitz
- Re: MAC route with IP Aldrin Isaac
- Re: MAC route with IP Ali Sajassi (sajassi)
- Re: MAC route with IP Jakob Heitz
- Re: MAC route with IP Ali Sajassi (sajassi)
- Re: MAC route with IP Jakob Heitz
- Re: MAC route with IP Aldrin Isaac
- Re: MAC route with IP Aldrin Isaac
- RE: MAC route with IP Jakob Heitz
- RE: MAC route with IP Linda Dunbar