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