Re: MAC route with IP
"Ali Sajassi (sajassi)" <sajassi@cisco.com> Tue, 13 May 2014 16:10 UTC
Return-Path: <sajassi@cisco.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 4E46B1A011D
for <l2vpn@ietfa.amsl.com>; Tue, 13 May 2014 09:10:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -15.151
X-Spam-Level:
X-Spam-Status: No, score=-15.151 tagged_above=-999 required=5
tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5,
RP_MATCHES_RCVD=-0.651, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5]
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 JLs2d_-OKOLm for <l2vpn@ietfa.amsl.com>;
Tue, 13 May 2014 09:10:35 -0700 (PDT)
Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79])
by ietfa.amsl.com (Postfix) with ESMTP id 688241A00BC
for <l2vpn@ietf.org>; Tue, 13 May 2014 09:08:26 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;
d=cisco.com; i=@cisco.com; l=36839; q=dns/txt;
s=iport; t=1399997300; x=1401206900;
h=from:to:subject:date:message-id:in-reply-to:mime-version;
bh=0Vsc1NEpfpSqg6rioLtemSNkOvQ/AJIUIrk6g7SA6es=;
b=YGvtUq7ETO/xE9HZtH5xo8kMa/fLltYAe+O/U+BYr38hR9yZ4+ygoSnP
3KheM2vJDN8sVnAUXk3fbXWh+KxZoOGlfoX3NcltzM9Wf3PQEvMHF+iXo
ZViSPD8PPlDkiiiENHifmX+kA1uRa3Y/Z6DMVfNb/QWyCQISDNvEFgO7p o=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AiEFAJk9clOtJA2K/2dsb2JhbABZgkIjIU9YxXoBgSIWdIIlAQEBBA4fOCYBCBEDAQEBIQEGORQJCAIEARKIQQHQaheNZ1oXAYRABIV4k1CTB4M2gi8
X-IronPort-AV: E=Sophos;i="4.97,1044,1389744000";
d="scan'208,217";a="324547875"
Received: from alln-core-5.cisco.com ([173.36.13.138])
by rcdn-iport-8.cisco.com with ESMTP; 13 May 2014 15:45:10 +0000
Received: from xhc-aln-x13.cisco.com (xhc-aln-x13.cisco.com [173.36.12.87])
by alln-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id s4DFjAbp009591
(version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL);
Tue, 13 May 2014 15:45:10 GMT
Received: from xmb-aln-x13.cisco.com ([fe80::5404:b599:9f57:834b]) by
xhc-aln-x13.cisco.com ([173.36.12.87]) with mapi id 14.03.0123.003; Tue, 13
May 2014 10:45:10 -0500
From: "Ali Sajassi (sajassi)" <sajassi@cisco.com>
To: Antoni Przygienda <antoni.przygienda@ericsson.com>, Jakob Heitz
<jakob.heitz@ericsson.com>, "l2vpn@ietf.org" <l2vpn@ietf.org>
Subject: Re: MAC route with IP
Thread-Topic: MAC route with IP
Thread-Index: AQHPbsJRaQfHHQKqR0C1MGMVDrT48w==
Date: Tue, 13 May 2014 15:45:08 +0000
Message-ID: <CF970326.D3932%sajassi@cisco.com>
In-Reply-To: <2E4BB27CAB87BF43B4207C0E55860F1812B4DF@eusaamb103.ericsson.se>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/14.3.4.130416
x-originating-ip: [10.128.2.48]
Content-Type: multipart/alternative;
boundary="_000_CF970326D3932sajassiciscocom_"
MIME-Version: 1.0
Archived-At: http://mailarchive.ietf.org/arch/msg/l2vpn/71dXvf2d0NHw7ezTfq75qjZPX3Y
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:10:38 -0000
Antoni,
From: Antoni Przygienda <antoni.przygienda@ericsson.com<mailto:antoni.przygienda@ericsson.com>>
Date: Sunday, May 11, 2014 11:23 PM
To: Cisco Employee <sajassi@cisco.com<mailto:sajassi@cisco.com>>, Jakob Heitz <jakob.heitz@ericsson.com<mailto:jakob.heitz@ericsson.com>>, "l2vpn@ietf.org<mailto:l2vpn@ietf.org>" <l2vpn@ietf.org<mailto:l2vpn@ietf.org>>
Subject: RE: MAC route with IP
Ali,
there are at least two cases when receiving updates from peers which are tad hairy given the encoding:
1. We receive a MAC/no-IP & a set of MAC/IP routes & then someone just withdraws the MAC/no-IP. It does not seem very logical that the MAC/IP routes are still valid to me or at least that could be emphasized in the draft that they do (i.e. all routes are truly independent).
MAC/IP routes will be independent from MAC-only route. If both are advertised, then withdrawing the MAC/IP route should clean up the ARP table but not remove the entry in the MAC-VRF.
2. Since we have mac based disposition there is nothing that prevents a neighbor to advertise multiple MAC/IP routes with different labels. It should obviously not imply that we have to lookup the IP address on the packet (if we even have one) to decide which label is needed. Should all this labels be considered pointing to the same MAC & equivalent ? Such a condition considered invalid transient and MAC labels for this MAC ignored completely ? What if we get one route with the label & another without ? We use the label nevertheless for the same MAC ?
The label represents the MAC address in case of label per MAC advertisement. So, even when you advertise multiple IP addresses for the same MAC, they all should use the same label.
And my final interesting observation:
A single primary/single backup case would be simple & easy, the way the protocol spec stands today, I don’t think there is anything that prevents it from operating in multiple-primaries, multiple-backup mode (as in two guys clear the single-active bits & all other set them) [unless I misunderstood something massively]. Do we load balance the primaries until both fail & then either flood (multiple backups) or fail back on the secondary ?
For a given ES, all PEs should advertise the same redundancy group mode (either all-active or single-active mode) for that ES. Otherwise, an error should be logged.
Cheers,
Ali
Otherwise, very good draft I think solving tons of hard problems in (for the customer and in terms of protocols mechanics) fairly elegant way.
--- tony
From: Ali Sajassi (sajassi) [mailto:sajassi@cisco.com]
Sent: Sunday, May 11, 2014 10:53 PM
To: Jakob Heitz; l2vpn@ietf.org<mailto:l2vpn@ietf.org>
Cc: Antoni Przygienda
Subject: Re: MAC route with IP
Yes, but that's the case when that MAC address is associated with other IP addresses per my example below. And as long as there are other ARP entry (or entries) for that MAC address after deleting that IP/MAC pair, the MAC address will remain in the MAC-VRF.
Cheers,
Ali
From: Jakob Heitz <jakob.heitz@ericsson.com<mailto:jakob.heitz@ericsson.com>>
Date: Sunday, May 11, 2014 10:38 PM
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
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