Return-Path: X-Original-To: bess@ietfa.amsl.com Delivered-To: bess@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id EA4D2120302 for ; Fri, 29 Mar 2019 13:18:10 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.749 X-Spam-Level: X-Spam-Status: No, score=-1.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, KHOP_DYNAMIC=0.85, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no 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 MM-81uCs2pFl for ; Fri, 29 Mar 2019 13:18:09 -0700 (PDT) Received: from mx0a-00191d01.pphosted.com (mx0b-00191d01.pphosted.com [67.231.157.136]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EBE5312026B for ; Fri, 29 Mar 2019 13:18:08 -0700 (PDT) Received: from pps.filterd (m0049462.ppops.net [127.0.0.1]) by m0049462.ppops.net-00191d01. (8.16.0.27/8.16.0.27) with SMTP id x2TK8aZ9035334; Fri, 29 Mar 2019 16:18:03 -0400 Received: from alpi155.enaf.aldc.att.com (sbcsmtp7.sbc.com [144.160.229.24]) by m0049462.ppops.net-00191d01. with ESMTP id 2rhsh21ggr-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 29 Mar 2019 16:18:03 -0400 Received: from enaf.aldc.att.com (localhost [127.0.0.1]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id x2TKI2VP021221; Fri, 29 Mar 2019 16:18:02 -0400 Received: from zlp27126.vci.att.com (zlp27126.vci.att.com [135.66.87.47]) by alpi155.enaf.aldc.att.com (8.14.5/8.14.5) with ESMTP id x2TKHsXF021113 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Fri, 29 Mar 2019 16:17:55 -0400 Received: from zlp27126.vci.att.com (zlp27126.vci.att.com [127.0.0.1]) by zlp27126.vci.att.com (Service) with ESMTP id C77DB4013FA5; Fri, 29 Mar 2019 20:17:54 +0000 (GMT) Received: from MISOUT7MSGHUBAE.ITServices.sbc.com (unknown [130.9.129.149]) by zlp27126.vci.att.com (Service) with ESMTPS id AF92C400069B; Fri, 29 Mar 2019 20:17:54 +0000 (GMT) Received: from MISOUT7MSGUSRCD.ITServices.sbc.com ([169.254.4.152]) by MISOUT7MSGHUBAE.ITServices.sbc.com ([130.9.129.149]) with mapi id 14.03.0439.000; Fri, 29 Mar 2019 16:17:53 -0400 From: "UTTARO, JAMES" To: Ryan Bickhart , Sandy Breeze , "bess@ietf.org" Thread-Topic: Question about draft-rbickhart-evpn-ip-mac-proxy-adv Thread-Index: AQHU5VR4IGuWpxFJd0qKs5LaDbkbs6Yi+YdwgAAS5ZA= Date: Fri, 29 Mar 2019 20:17:53 +0000 Message-ID: References: <867D94CC-421F-4524-B594-BCA04F1F1591@eu.clara.net> In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [135.76.93.1] Content-Type: multipart/alternative; boundary="_000_B17A6910EEDD1F45980687268941550F4D834382MISOUT7MSGUSRCD_" MIME-Version: 1.0 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-03-29_12:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_policy_notspam policy=outbound_policy score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1810050000 definitions=main-1903290138 Archived-At: Subject: Re: [bess] Question about draft-rbickhart-evpn-ip-mac-proxy-adv X-BeenThere: bess@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: BGP-Enabled ServiceS working group discussion list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 29 Mar 2019 20:18:11 -0000 --_000_B17A6910EEDD1F45980687268941550F4D834382MISOUT7MSGUSRCD_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Ryan, My take here is that we are trying to approach the notion of = routing to the "customer" without actually routing.. PE2 and PE3 never rece= ive the MAC as expected in data plane learning.. This is forcing the MAC vi= a the origination at PE2 and PE3 to seem like it was "learned" there. The n= otion of EVPN was Data Plane learning to the customer, control plane learni= ng to in the EVPN signaling domain. Why can't the state simple be persisted= if there are still valid PEs ( PE2, PE3 ) the ESI.. IMO this seems to acco= mplish your goal without changing the paradigm. I believe the draft below c= omes close to what you want.. addl text would be needed to persist if ESI i= s valid.. Thanks, Jim Uttaro https://www.ietf.org/archive/id/draft-uttaro-idr-bgp-persistence-04.txt From: BESS On Behalf Of Ryan Bickhart Sent: Friday, March 29, 2019 3:38 PM To: Sandy Breeze ; bess@ietf.= org Subject: Re: [bess] Question about draft-rbickhart-evpn-ip-mac-proxy-adv Hi Sandy, It is intentional that PE4 sees an RT2 for the CE1 MAC/IP advertised from P= E2 and PE3 as well as PE1. The reason is that we want to cover the transiti= on cases of link or node failure occurring on PE1. PE4 might be using CE1's= IP carried in the RT2 for IRB or routing purposes and it is desirable for = PE4 to maintain constant awareness of the existence of the CE1 IP across fa= ilures on PE1. Under normal 7432 behavior, if PE1 were the only PE advertis= ing the RT2 for CE1's MAC/IP and PE1's link to the multihomed site goes dow= n, PE1 might withdraw the RT2 before PE2/PE3 are able to learn the CE1 IP->= MAC binding in the data plane and advertise it as a RT2 to PE4. By having P= E2/PE3 originate the proxy advertisements, we avoid the case where the CE1 = MAC/IP might completely disappear and later reappear in the EVPN when there= is a failure on PE1. (Maybe a general L2 way of phrasing this concept is t= hat you can do aliasing only for entities that you know about. If there is = no trace of a MAC's existence left in the EVPN, you would flood rather than= use aliasing.) Thanks, -Ryan Juniper Internal From: BESS > On Behalf = Of Sandy Breeze Sent: Thursday, March 28, 2019 3:53 AM To: bess@ietf.org Subject: [bess] Question about draft-rbickhart-evpn-ip-mac-proxy-adv Hi Wen, First, thank you for this work, I see the problem you're trying to solve an= d support trying to do that. I have some questions. Lets say for example, PEs: 1,2,3 have CE1 attached on the same all-active E= S. PE4 is a remote PE participating in the same EVPN. CE1's MAC/IP is lea= rned in the dataplane by PE1 only, and PE1 originates the RT2 initially. At this point, with standard 7432 mechanisms, PE4 can already have aliasing= and backup paths to CE1 via PEs 2 and 3 without the need to see an RT2 fro= m either PE2 or PE3. What PE2 and PE3 might be missing locally, however, i= s ARP/ND state for CE1, which is and which your draft looks to solve in BGP= . (If my understanding is correct?) Now if PE2 and PE3 support the proxy-adv mechanism, then they sync ARP/ND u= pon receipt of the RT2 from PE1. Why do PE2 and PE3 then need to originate= their own RT2? If they originate RT2's then this can influence the forwar= ding decisions at other remote PE's like PE4, who lets say doesn't understa= nd the proxy-adv bit in the ARP/ND extended community and will see the RT2 = as originating from 3 different PE's. Is that the intention of the draft o= r just a consequence? Or is it the intention to keep the proxy-adv mechani= sm for use amongst the multihomed PE's only? Thanks Sandy --_000_B17A6910EEDD1F45980687268941550F4D834382MISOUT7MSGUSRCD_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Ryan,

 

            &n= bsp; My take here is that we are trying to approach the notion of routing t= o the “customer” without actually routing.. PE2 and PE3 never r= eceive the MAC as expected in data plane learning.. This is forcing the MAC via the origination at PE2 and PE3 to s= eem like it was “learned” there. The notion of EVPN was Data Pl= ane learning to the customer, control plane learning to in the EVPN signali= ng domain. Why can’t the state simple be persisted if there are still valid PEs ( PE2, PE3 ) the ESI.. IMO this seems to acco= mplish your goal without changing the paradigm. I believe the draft below c= omes close to what you want.. addl text would be needed to persist if ESI i= s valid..

 

Thanks,

            &n= bsp; Jim Uttaro

 

https://www.ietf.org/archive/id/draft-uttaro-idr-bgp-persistence-= 04.txt

 

From:= BESS <bess-bounces@ietf.org> On Behalf Of Ryan Bickhart
Sent: Friday, March 29, 2019 3:38 PM
To: Sandy Breeze <sandy.breeze=3D40eu.clara.net@dmarc.ietf.org>= ;; bess@ietf.org
Subject: Re: [bess] Question about draft-rbickhart-evpn-ip-mac-proxy= -adv

 

Hi Sandy,

 

It is intentional t= hat PE4 sees an RT2 for the CE1 MAC/IP advertised from PE2 and PE3 as well = as PE1. The reason is that we want to cover the transition cases of link or= node failure occurring on PE1. PE4 might be using CE1's IP carried in the RT2 for IRB or routing purposes and= it is desirable for PE4 to maintain constant awareness of the existence of= the CE1 IP across failures on PE1. Under normal 7432 behavior, if PE1 were= the only PE advertising the RT2 for CE1's MAC/IP and PE1's link to the multihomed site goes down, PE1 migh= t withdraw the RT2 before PE2/PE3 are able to learn the CE1 IP->MAC bind= ing in the data plane and advertise it as a RT2 to PE4. By having PE2/PE3 o= riginate the proxy advertisements, we avoid the case where the CE1 MAC/IP might completely disappear and late= r reappear in the EVPN when there is a failure on PE1. (Maybe a general L2 = way of phrasing this concept is that you can do aliasing only for entities = that you know about. If there is no trace of a MAC's existence left in the EVPN, you would flood rather tha= n use aliasing.)

 

Thanks,<= /span>

-Ryan

 

 

 

Juniper Internal=

From:= BESS <bess-bounces@ietf.org> On Behalf Of Sandy Breeze
Sent: Thursday, March 28, 2019 3:53 AM
To: bess@ietf.org
Subject: [bess] Question about draft-rbickhart-evpn-ip-mac-proxy-adv=

 

Hi W= en,

 

Firs= t, thank you for this work, I see the problem you’re trying to solve = and support trying to do that.  I have some questions.

 

Lets= say for example, PEs: 1,2,3 have CE1 attached on the same all-active ES.&n= bsp; PE4 is a remote PE participating in the same EVPN.  CE1’s M= AC/IP is learned in the dataplane by PE1 only, and PE1 originates the RT2 initially.

 

At t= his point, with standard 7432 mechanisms, PE4 can already have aliasing and= backup paths to CE1 via PEs 2 and 3 without the need to see an RT2 from ei= ther PE2 or PE3.  What PE2 and PE3 might be missing locally, however, is ARP/ND state for CE1, which is and which y= our draft looks to solve in BGP.  (If my understanding is correct?)

 

Now = if PE2 and PE3 support the proxy-adv mechanism, then they sync ARP/ND upon = receipt of the RT2 from PE1.  Why do PE2 and PE3 then need to originat= e their own RT2?  If they originate RT2’s then this can influence the forwarding decisions at other remote PE’s lik= e PE4, who lets say doesn’t understand the proxy-adv bit in the ARP/N= D extended community and will see the RT2 as originating from 3 different P= E’s.  Is that the intention of the draft or just a consequence?  Or is it the intention to keep the proxy-adv mec= hanism for use amongst the multihomed PE’s only?

 

Than= ks

Sand= y

 

--_000_B17A6910EEDD1F45980687268941550F4D834382MISOUT7MSGUSRCD_--