RE: MAC route with IP

Jakob Heitz <jakob.heitz@ericsson.com> Tue, 13 May 2014 16:28 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 B87E41A00BC for <l2vpn@ietfa.amsl.com>; Tue, 13 May 2014 09:28:32 -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 pNzopIfH29pV for <l2vpn@ietfa.amsl.com>; Tue, 13 May 2014 09:28:30 -0700 (PDT)
Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) by ietfa.amsl.com (Postfix) with ESMTP id B8F831A00B2 for <l2vpn@ietf.org>; Tue, 13 May 2014 09:28:29 -0700 (PDT)
X-AuditID: c6180641-f799b6d000000b0f-15-5371f664f844
Received: from EUSAAHC001.ericsson.se (Unknown_Domain [147.117.188.75]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id F2.B3.02831.466F1735; Tue, 13 May 2014 12:39:32 +0200 (CEST)
Received: from EUSAAMB109.ericsson.se ([147.117.188.126]) by EUSAAHC001.ericsson.se ([147.117.188.75]) with mapi id 14.03.0174.001; Tue, 13 May 2014 12:28:22 -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+kA=
Date: Tue, 13 May 2014 16:28:21 +0000
Message-ID: <2F3EBB88EC3A454AAB08915FBF0B8C7E03055EE4@eusaamb109.ericsson.se>
References: <2F3EBB88EC3A454AAB08915FBF0B8C7E03053BF0@eusaamb109.ericsson.se> <CF96FC89.D38FD%sajassi@cisco.com>
In-Reply-To: <CF96FC89.D38FD%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_2F3EBB88EC3A454AAB08915FBF0B8C7E03055EE4eusaamb109erics_"
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrBLMWRmVeSWpSXmKPExsUyuXSPt27qt8Jgg+f8Fo+/HWK3eHe2mcWB yWPK742sHkuW/GQKYIrisklJzcksSy3St0vgyvgwaS5bwcdTjBU3509hbWC8tpmxi5GTQ0LA ROJBwwlmCFtM4sK99WxdjFwcQgJHGSVOb1rMBpIQEljOKPFkLhOIzSagI/HtehdYg4hAiMTp vhawQcwCZhKdNyezg9jCAnISnzuOMkHUyEs0/ljLCmH7SXR/ecsCYrMIqEo82XsBbA6vgK/E jT1vWCB2FUk8mTIdaA4HB6eAvsTzeX4gYUag276fWsMEsUpc4taT+UwQNwtILNlzHup+UYmX j/+xQthKEpOWnmOFqM+XuPRyHRPEKkGJkzOfsExgFJ2FZNQsJGWzkJRBxHUkFuz+xAZha0ss W/iaGcY+c+AxE7L4Akb2VYwcpcWpZbnpRoabGIFRdUyCzXEH44JPlocYBTgYlXh4F8wuCBZi TSwrrsw9xCjNwaIkzpv+KTZYSCA9sSQ1OzW1ILUovqg0J7X4ECMTB6dUA+Osov9XNgQI3TC2 EdEv5J/9diGTVVFbRqn+m5OnZ6SejBeUO+J+SVXO+WfXjs3PpzxSYEjWUnl/RHVXn8u0vd+2 3Du2eeH3wASP6y+mSqWEBO2IlrdTVukvvZTwIF8j7sG6y8xvL/rIVXMWHLdU5+Jv90rZcDYk 6BfjI+X0y/cXSM6cvrih2VmJpTgj0VCLuag4EQDs2LTDiwIAAA==
Archived-At: http://mailarchive.ietf.org/arch/msg/l2vpn/do07ULIHN0aRz-Mxwa7sPSCzpAw
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 16:28:32 -0000

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