Re: MAC route with IP
Aldrin Isaac <aldrin.isaac@gmail.com> Tue, 13 May 2014 18:14 UTC
Return-Path: <aldrin.isaac@gmail.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 ADFF51A0189
for <l2vpn@ietfa.amsl.com>; Tue, 13 May 2014 11:14:41 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5
tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, 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 7TFWb6v_MDR3 for <l2vpn@ietfa.amsl.com>;
Tue, 13 May 2014 11:14:39 -0700 (PDT)
Received: from mail-yh0-x233.google.com (mail-yh0-x233.google.com
[IPv6:2607:f8b0:4002:c01::233])
by ietfa.amsl.com (Postfix) with ESMTP id 542211A010C
for <l2vpn@ietf.org>; Tue, 13 May 2014 11:14:39 -0700 (PDT)
Received: by mail-yh0-f51.google.com with SMTP id f73so664838yha.38
for <l2vpn@ietf.org>; Tue, 13 May 2014 11:14:32 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
h=mime-version:in-reply-to:references:date:message-id:subject:from:to
:cc:content-type;
bh=beTBodDDRZ+/yl/bE71P6qYaMqDV/8k8cRsuRz345HU=;
b=HQC9DsYVsuycz5FHElV+kW2N/vQ/xxJ64LfZJ1shI9xtL+fGs43hFH+8abQixgCcKn
c+0ZhZVgBinhE6GARw9H7+RVNB9WHiaArDZnZ9QlWeXWcD+ZIk0NZmI57OVmibk2SKBS
3usK2uMqWSAusbs5i8tnh6nuuazpNlTi0et9llXOGbnj1P9uIvUW+iAAAAr7FUqga7ZD
6CKb4qS77CHFPce5b5DFzZ13v7dPvoKYG6GGjXfjXFuM8ZAMydWWGr0DsCRMglOrinWb
akc+FS4oI9kqJl5fDWVkyJz4H60zDysv5mKRiPdZhIwxbcvu0VRHlHHnyHELb54zTcG1
iAuA==
MIME-Version: 1.0
X-Received: by 10.236.166.169 with SMTP id g29mr5981973yhl.135.1400004872730;
Tue, 13 May 2014 11:14:32 -0700 (PDT)
Received: by 10.170.75.136 with HTTP; Tue, 13 May 2014 11:14:32 -0700 (PDT)
In-Reply-To: <CF97A870.D3A1B%sajassi@cisco.com>
References: <bdc24c5c43e745c3aabd2c99a08b9f93@BLUPR05MB562.namprd05.prod.outlook.com>
<CF97A870.D3A1B%sajassi@cisco.com>
Date: Tue, 13 May 2014 14:14:32 -0400
Message-ID: <CAOA2mbyfVfRYqgsnZAuc8cpt=zdD1hFPijbXTkkrqV+T3MA=uQ@mail.gmail.com>
Subject: Re: MAC route with IP
From: Aldrin Isaac <aldrin.isaac@gmail.com>
To: "Ali Sajassi (sajassi)" <sajassi@cisco.com>
Content-Type: multipart/alternative; boundary=20cf303f6cb21f7d8b04f94c09cd
Archived-At: http://mailarchive.ietf.org/arch/msg/l2vpn/vQVrv894T7wro5D1_WNQeh-t7lc
Cc: Antoni Przygienda <antoni.przygienda@ericsson.com>,
"l2vpn@ietf.org" <l2vpn@ietf.org>
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 18:14:41 -0000
Would it be worthwhile to mention that MAC/IP routes should not be used as a proxy for MAC-only route? On Tuesday, May 13, 2014, Ali Sajassi (sajassi) <sajassi@cisco.com> wrote: > > Yes, although my email and Jorge's emails crossed each others, we are > both saying exactly the same thing. > > That's why I think the existing text is sufficient and we don't need to > add any thing more because both of the scenarios I mentioned below can > happen and the existing text covers them both. > > Cheers, > Ali > > > > From: John E Drake <jdrake@juniper.net<javascript:_e(%7B%7D,'cvml','jdrake@juniper.net');> > > > Date: Tuesday, May 13, 2014 10:44 AM > To: Cisco Employee <sajassi@cisco.com<javascript:_e(%7B%7D,'cvml','sajassi@cisco.com');>>, > Jakob Heitz <jakob.heitz@ericsson.com<javascript:_e(%7B%7D,'cvml','jakob.heitz@ericsson.com');>>, > "l2vpn@ietf.org <javascript:_e(%7B%7D,'cvml','l2vpn@ietf.org');>" < > l2vpn@ietf.org <javascript:_e(%7B%7D,'cvml','l2vpn@ietf.org');>> > Cc: Antoni Przygienda <antoni.przygienda@ericsson.com<javascript:_e(%7B%7D,'cvml','antoni.przygienda@ericsson.com');> > > > Subject: RE: MAC route with IP > > Ali, > > > > As both Jorge and you have pointed out, there may indeed be cases for > which there should not be a MAC only route. > > > > Yours Irrespectively, > > > > John > > > > *From:* L2vpn [mailto:l2vpn-bounces@ietf.org] *On Behalf Of *Ali Sajassi > (sajassi) > *Sent:* Tuesday, May 13, 2014 10:38 AM > *To:* Jakob Heitz; l2vpn@ietf.org > *Cc:* Antoni Przygienda > *Subject:* Re: MAC route with IP > > > > > > Even if there is reordering by route reflector, then as I said, I don't > see an issue here :-) In your example, the receiver sees the withdrawn of > the IP/MAC route before receiving the MAC-only route. In that case, the > traffic toward that MAC address will get flooding (or dropped if flooding > is disabled) till it receives the MAC-only route. However, why does the > sender has to wait till it withdraws the IP/MAC advertisement before > sending the MAC-only advertisement – e.g., why doesn't the sender send > MAC-only advertisement as soon as it learns it. > > > > Again, there are scenarios in which learning is done in data-plane along > with ARP suppression. In such scenarios, the sender should send MAC-only > route as soon as it learns it and MAC/IP route when it snoops the ARP. > However, there are other scenarios where there is no MAC learning in > data-plane. In such scenario, when a VM becomes known, the MAC/IP route is > advertised and if the VM goes away, MAC/IP is withdrawn. In such scenarios, > we don't want to advertise an extra route (MAC-only route) unnecessarily. > > > > Cheers, > > Ali > > > > *From: *Jakob Heitz <jakob.heitz@ericsson.com> > *Date: *Tuesday, May 13, 2014 10:13 AM > *To: *Cisco Employee <sajassi@cisco.com>om>, "l2vpn@ietf.org" <l2vpn@ietf.org > > > *Cc: *Antoni Przygienda <antoni.przygienda@ericsson.com> > *Subject: *RE: MAC route with IP > > > > A route reflector can and frequently does reorder routes from the same > speaker. > > For example, a version walk of a tree does not walk in version order, it > walks in key order. > >
- 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