Re: About ALL-ZERO-MAC's encapsulation in EVPN MAC/IP Advertisement route. //Re: Poll for adoption: draft-bonica-l3vpn-orf-covering-prefixes
Zhuangshunwan <zhuangshunwan@huawei.com> Thu, 03 July 2014 00:52 UTC
Return-Path: <zhuangshunwan@huawei.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 913E71A0652;
Wed, 2 Jul 2014 17:52:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.852
X-Spam-Level:
X-Spam-Status: No, score=-4.852 tagged_above=-999 required=5
tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.651,
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 WgJMih63dzj8; Wed, 2 Jul 2014 17:52:14 -0700 (PDT)
Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17])
(using TLSv1 with cipher RC4-SHA (128/128 bits))
(No client certificate requested)
by ietfa.amsl.com (Postfix) with ESMTPS id DBF5F1A0301;
Wed, 2 Jul 2014 17:52:13 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml404-hub.china.huawei.com)
([172.18.7.190])
by lhrrg02-dlp.huawei.com (MOS 4.3.7-GA FastPath queued)
with ESMTP id BGS70733; Thu, 03 Jul 2014 00:52:11 +0000 (GMT)
Received: from SZXEML407-HUB.china.huawei.com (10.82.67.94) by
lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server
(TLS) id 14.3.158.1; Thu, 3 Jul 2014 01:52:10 +0100
Received: from peky1z001750051 (10.111.80.111) by smtpscn.huawei.com
(10.82.67.94) with Microsoft SMTP Server (TLS) id 14.3.158.1; Thu, 3 Jul 2014
08:52:06 +0800
From: Zhuangshunwan <zhuangshunwan@huawei.com>
To: "'Rabadan, Jorge (Jorge)'" <jorge.rabadan@alcatel-lucent.com>, "'Thomas
Morin'" <thomas.morin@orange.com>, <l3vpn@ietf.org>
References: <53AD7DDA.3060806@orange.com> <000001cf95cb$a60d8f80$f228ae80$@com>
<CFD9113F.466D1%jorge.rabadan@alcatel-lucent.com>
In-Reply-To: <CFD9113F.466D1%jorge.rabadan@alcatel-lucent.com>
Subject: Re: About ALL-ZERO-MAC's encapsulation in EVPN MAC/IP Advertisement
route. //Re: Poll for adoption: draft-bonica-l3vpn-orf-covering-prefixes
Date: Thu, 3 Jul 2014 08:52:06 +0800
Message-ID: <002401cf9659$0372baa0$0a582fe0$@com>
MIME-Version: 1.0
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: Ac+SExWDkUZULLIjQ3Odnfgnctqh2wDtUxpQ//+aCID//nuaIA==
Content-Language: zh-cn
X-Originating-IP: [10.111.80.111]
X-CFilter-Loop: Reflected
Archived-At: http://mailarchive.ietf.org/arch/msg/l2vpn/6DwWR2bbRVblMgvwpdFqx_tI05U
Cc: l2vpn@ietf.org, draft-bonica-l3vpn-orf-covering-prefixes@tools.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: Thu, 03 Jul 2014 00:52:16 -0000
Jorge, I'm much obliged to you for your detailed comments. Thank you. Shunwan -----邮件原件----- 发件人: Rabadan, Jorge (Jorge) [mailto:jorge.rabadan@alcatel-lucent.com] 发送时间: 2014年7月2日 18:32 收件人: Zhuangshunwan; 'Thomas Morin'; l3vpn@ietf.org 抄送: l2vpn@ietf.org; draft-bonica-l3vpn-orf-covering-prefixes@tools.ietf.org 主题: Re: About ALL-ZERO-MAC's encapsulation in EVPN MAC/IP Advertisement route. //Re: Poll for adoption: draft-bonica-l3vpn-orf-covering-prefixes Hi Shunwan, That’s a good point. A couple of comments about it and why I think we should use a length = 48. - I don’t know about draft-bonica, but there is already at least one shipping implementation using 00:..:00/48 as per draft-rabadan-l2vpn-dci-evpn-overlay - There are a few reasons why we decided to use length 48: 1) The EVPN base draft only allows a MAC length = 48 and says other length is out of scope 2) In the IP world, there is subneting so a default route with length /0 makes sense. In the MAC world, there is no subnetting (at least in real implementations where MACs are not managed) so some implementations might have issues with lengths different than 48. 3) the meaning of 00:..:00/48 is a bit different than only a default route. We actually decided to call it “unknown mac route” since you might want to advertise it from different gateway devices to attract all the unknown traffic to ONLY those devices. In draft-rabadan-l2vpn-dci-evpn-overlay you can see that the ingress PE needs to send unknown traffic to all the egress PEs advertising the unknown-mac-route, as opposed to only one. Thank you. Jorge -----Original Message----- From: Zhuangshunwan <zhuangshunwan@huawei.com> Date: Wednesday, July 2, 2014 at 1:00 AM To: 'Thomas Morin' <thomas.morin@orange.com>om>, "l3vpn@ietf.org" <l3vpn@ietf.org> Cc: "l2vpn@ietf.org" <l2vpn@ietf.org>rg>, "draft-bonica-l3vpn-orf-covering-prefixes@tools.ietf.org" <draft-bonica-l3vpn-orf-covering-prefixes@tools.ietf.org> Subject: About ALL-ZERO-MAC's encapsulation in EVPN MAC/IP Advertisement route. //Re: Poll for adoption: draft-bonica-l3vpn-orf-covering-prefixes >Dear all, > >I have got into knots for presentment of ALL-ZERO-MAC's encapsulation in >EVPN MAC/IP Advertisement route. > >draft-bonica-l3vpn-orf-covering-prefixes-03 defines the "Default MAC >Route ": > > o Default MAC Route (DMR) - An EVPN MAC/IP Advertisement Route with > MAC Address length equal to 0. > >But draft-rabadan-l2vpn-dci-evpn-overlay-01 said: > >2.5.1 Use of the Unknown MAC route to reduce unknown flooding > > The solution suggested in this document is based on the use of an > "Unknown MAC route" that is advertised by the Designated Forwarder > DC GW. The Unknown MAC route is a regular EVPN MAC/IP > Advertisement route where the MAC Address Length is set to 48 and > the MAC address to 00:00:00:00:00:00 (IP length is set to 0). > > >Can we use a uniform way? > > >Regards, >Shunwan (Vincent) > >-----邮件原件----- >发件人: L3VPN [mailto:l3vpn-bounces@ietf.org] 代表 Thomas Morin >发送时间: 2014年6月27日 22:21 >收件人: l3vpn@ietf.org >抄送: draft-bonica-l3vpn-orf-covering-prefixes@tools.ietf.org >主题: Poll for adoption: draft-bonica-l3vpn-orf-covering-prefixes > >Hello working group, > >This email starts a two-week poll on adopting >draft-bonica-l3vpn-orf-covering-prefixes-03 [1] as a working group item. > >Please send comments to the list and state if you support adoption or >not (in the later case, please also state the reasons). > >This poll runs until July 12th. > > >*Coincidentally*, we are also polling for knowledge of any IPR that >applies to this draft, to ensure that IPR has been disclosed in >compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 >and 5378 for more details). > >==> *If you are listed as a document author or contributor* please >respond to this email and indicate whether or not you are aware of any >relevant IPR. > >The draft will not be adopted until a response has been received from >each author and contributor. > >If you are on the L3VPN WG mailing list but are not listed as an author >or contributor, then please explicitly respond only if you are aware of >any IPR that has not yet been disclosed in conformance with IETF rules. > >Thank you, > >Martin & Thomas >l3vpn chairs > >[1] http://tools.ietf.org/html/draft-bonica-l3vpn-orf-covering-prefixes-03 >
- About ALL-ZERO-MAC's encapsulation in EVPN MAC/IP… Zhuangshunwan
- Re: About ALL-ZERO-MAC's encapsulation in EVPN MA… Rabadan, Jorge (Jorge)
- Re: About ALL-ZERO-MAC's encapsulation in EVPN MA… Robert Raszuk
- RE: About ALL-ZERO-MAC's encapsulation in EVPN MA… Yakov Rekhter
- Re: About ALL-ZERO-MAC's encapsulation in EVPN MA… Ali Sajassi (sajassi)
- Re: About ALL-ZERO-MAC's encapsulation in EVPN MA… Zhuangshunwan