Re: [bess] comment on draft-ietf-bess-ir
Lucy yong <lucy.yong@huawei.com> Wed, 23 September 2015 14:47 UTC
Return-Path: <lucy.yong@huawei.com>
X-Original-To: bess@ietfa.amsl.com
Delivered-To: bess@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B6C31A6F67; Wed, 23 Sep 2015 07:47:47 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.211
X-Spam-Level:
X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] 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 cWT7O9dqPR47; Wed, 23 Sep 2015 07:47:45 -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 A140F1A21C7; Wed, 23 Sep 2015 07:47:44 -0700 (PDT)
Received: from 172.18.7.190 (EHLO lhreml402-hub.china.huawei.com) ([172.18.7.190]) by lhrrg01-dlp.huawei.com (MOS 4.3.7-GA FastPath queued) with ESMTP id CBQ41783; Wed, 23 Sep 2015 14:47:42 +0000 (GMT)
Received: from DFWEML705-CHM.china.huawei.com (10.193.5.142) by lhreml402-hub.china.huawei.com (10.201.5.241) with Microsoft SMTP Server (TLS) id 14.3.235.1; Wed, 23 Sep 2015 15:47:41 +0100
Received: from DFWEML701-CHM.china.huawei.com ([10.193.5.50]) by dfweml705-chm ([10.193.5.142]) with mapi id 14.03.0235.001; Wed, 23 Sep 2015 07:47:35 -0700
From: Lucy yong <lucy.yong@huawei.com>
To: "Jeffrey (Zhaohui) Zhang" <zzhang@juniper.net>, Eric Rosen <erosen@juniper.net>, "draft-ietf-bess-ir@ietf.org" <draft-ietf-bess-ir@ietf.org>
Thread-Topic: [bess] comment on draft-ietf-bess-ir
Thread-Index: AQHQ5PL2CCp0RPOPn0WfbtWHCw0C/J4roSwwgB1KyFSAAVaRQIAAfdWA//+LziCAAHdoAP//ivtQgAB3GAD//42BUA==
Date: Wed, 23 Sep 2015 14:47:35 +0000
Message-ID: <2691CE0099834E4A9C5044EEC662BB9D571F5F58@dfweml701-chm>
References: <2691CE0099834E4A9C5044EEC662BB9D571D7792@dfweml701-chm> <BLUPR0501MB1715C4449A20759976E757F5D46A0@BLUPR0501MB1715.namprd05.prod.outlook.com> <2691CE0099834E4A9C5044EEC662BB9D571D78FA@dfweml701-chm> <55E60759.3090502@juniper.net> <2691CE0099834E4A9C5044EEC662BB9D571D85E5@dfweml701-chm> <560007CF.6010206@juniper.net> <2691CE0099834E4A9C5044EEC662BB9D571F4F1E@dfweml701-chm> <56018DB6.2000202@juniper.net> <2691CE0099834E4A9C5044EEC662BB9D571F5EC2@dfweml701-chm> <BLUPR0501MB1715038ECC4C03238112F800D4440@BLUPR0501MB1715.namprd05.prod.outlook.com> <2691CE0099834E4A9C5044EEC662BB9D571F5F19@dfweml701-chm> <BLUPR0501MB1715A058BB9C62D159A23021D4440@BLUPR0501MB1715.namprd05.prod.outlook.com> <2691CE0099834E4A9C5044EEC662BB9D571F5F35@dfweml701-chm> <BLUPR0501MB1715BC1F748922363B412264D4440@BLUPR0501MB1715.namprd05.prod.outlook.com>
In-Reply-To: <BLUPR0501MB1715BC1F748922363B412264D4440@BLUPR0501MB1715.namprd05.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.47.153.248]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-CFilter-Loop: Reflected
Archived-At: <http://mailarchive.ietf.org/arch/msg/bess/eXEy_emUZa9LPW8GwCXU2wJeJ0E>
Cc: "bess@ietf.org" <bess@ietf.org>
Subject: Re: [bess] comment on draft-ietf-bess-ir
X-BeenThere: bess@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: BGP-Enabled ServiceS working group discussion list <bess.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/bess>, <mailto:bess-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/bess/>
List-Post: <mailto:bess@ietf.org>
List-Help: <mailto:bess-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/bess>, <mailto:bess-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 23 Sep 2015 14:47:47 -0000
Jeff, RR does not change BGP next hop on the update. N1 and N2 can determine P-tunnel neighbor based on BGP next hop. Lucy -----Original Message----- From: Jeffrey (Zhaohui) Zhang [mailto:zzhang@juniper.net] Sent: Wednesday, September 23, 2015 9:36 AM To: Lucy yong; Eric Rosen; draft-ietf-bess-ir@ietf.org Cc: bess@ietf.org Subject: RE: [bess] comment on draft-ietf-bess-ir Lucy, Perhaps you can elaborate the following then? There is no BGP session between N1/N2 and N3. RR does not understand "upstream/downstream" neighbor. Even on N1/N2/N3, upstream/downstream are wrt different flows. How do you configure such policies? > > [Lucy] If each BGP session keeps track of P-tunnel neighbor state: > > 1) the downstream neighbor, 2) the upstream neighbor, or 3) N/A. A > > simple policy can suppress a lot distribution: redistribute a Leaf > > A-D route if and only if it is sent by a downstream neighbor. This > > ensures that ingress PE receives all the Leaf A-D routes from all the egress PEs. Jeffrey > -----Original Message----- > From: Lucy yong [mailto:lucy.yong@huawei.com] > Sent: Wednesday, September 23, 2015 10:31 AM > To: Jeffrey (Zhaohui) Zhang <zzhang@juniper.net>; Eric Rosen > <erosen@juniper.net>; draft-ietf-bess-ir@ietf.org > Cc: bess@ietf.org > Subject: RE: [bess] comment on draft-ietf-bess-ir > > Hi Jeff, > > As I said before, RR always need to distribute Leaf A-D routes. > > Lucy > > -----Original Message----- > From: Jeffrey (Zhaohui) Zhang [mailto:zzhang@juniper.net] > Sent: Wednesday, September 23, 2015 9:28 AM > To: Lucy yong; Eric Rosen; draft-ietf-bess-ir@ietf.org > Cc: bess@ietf.org > Subject: RE: [bess] comment on draft-ietf-bess-ir > > Lucy, > > The point is that we rely on BGP distribution mechanism, and we cannot > expect RRs to do more than basic route distribution. > > Jeffrey > > > -----Original Message----- > > From: Lucy yong [mailto:lucy.yong@huawei.com] > > Sent: Wednesday, September 23, 2015 10:26 AM > > To: Jeffrey (Zhaohui) Zhang <zzhang@juniper.net>; Eric Rosen > > <erosen@juniper.net>; draft-ietf-bess-ir@ietf.org > > Cc: bess@ietf.org > > Subject: RE: [bess] comment on draft-ietf-bess-ir > > > > Hi Jeff, > > > > We seem across each other. Two potential optimizations I proposed: > > 1) suppress unnecessary redistribution; 2) method for child to > > change its patent. I am not clear which one example illustrates. > > Both need to work with and without RR. > > > > -----Original Message----- > > From: Jeffrey (Zhaohui) Zhang [mailto:zzhang@juniper.net] > > Sent: Wednesday, September 23, 2015 9:17 AM > > To: Lucy yong; Eric Rosen; draft-ietf-bess-ir@ietf.org > > Cc: bess@ietf.org > > Subject: RE: [bess] comment on draft-ietf-bess-ir > > > > Lucy, > > > > Let's use this example to illustrate the points we tried to get through: > > > > N1 N2 > > \ / > > \ / > > RR > > | > > | > > N3 > > > > > > N3 originates a Leaf AD route. Originally the parent is N1 so the > > Leaf AD route has RT(N1). Then the parent changes to N2 so N3 sends > > an update with new RT(N2). There is no withdraw from N3 at all. > > > > The route and its update is sent by N3 to only the RR. > > > > If Constraint Route Distribution (RFC 4684) is used, only N1 will > > get the initial route, and when N3 sends the update, RR will > > withdraw it from N1 and send the route to N2. > > > > If that is not used, then both N1 and N2 will get the original route > > and the update. Because the RT(N2) in the update does not match N1, > > N1 will treat the update as an implicit withdraw. > > > > So, in the first case, N1 will get the withdraw that is controlled > > by the RR, which only follows BGP route distribution process and > > does not understand MVPN/IR rules at all. In the second case, there > > is no explicit withdraw at all. In both cases, N3 only sends an update. > > > > Jeffrey > > > > > > > -----Original Message----- > > > From: Lucy yong [mailto:lucy.yong@huawei.com] > > > Sent: Wednesday, September 23, 2015 9:58 AM > > > To: Eric Rosen <erosen@juniper.net>; Jeffrey (Zhaohui) Zhang > > > <zzhang@juniper.net>; draft-ietf-bess-ir@ietf.org > > > Cc: bess@ietf.org > > > Subject: RE: [bess] comment on draft-ietf-bess-ir > > > > > > Hi Eric, > > > > > > When non-segmented ingress replication is used, the ingress PE > > > needs to see the Leaf A-D routes from all the egress PEs. (The > > > ingress PE is the upstream parent in this case, even if the > > > ingress PE is not a BGP peer of the egress PEs.) This means that > > > the RT on the Leaf A-D routes needs to identify the ingress PE. > > > However, the Leaf A-D routes may need to travel over multiple BGP > > > sessions before they reach the > > ingress PE. > > > Some of these BGP sessions may be IBGP sessions, some may be EBGP > > sessions. > > > It's rather important that the route not get discarded before it > > > reaches the ingress PE, even though it passes through multiple BGP > > > speakers. If one wants to constrain the distribution of the > > > routes, one still has to guarantee that the routes will reach their targets. > > > > > > > > > [Lucy] If each BGP session keeps track of P-tunnel neighbor state: > > > 1) the downstream neighbor, 2) the upstream neighbor, or 3) N/A. A > > > simple policy can suppress a lot distribution: redistribute a Leaf > > > A-D route if and only if it is sent by a downstream neighbor. This > > > ensures that ingress PE receives all the Leaf A-D routes from all > > > the > egress PEs. > > > > > > Thanks, > > > Lucy > > > > > >
- [bess] comment on draft-ietf-bess-ir Lucy yong
- Re: [bess] comment on draft-ietf-bess-ir Jeffrey (Zhaohui) Zhang
- Re: [bess] comment on draft-ietf-bess-ir Jeffrey (Zhaohui) Zhang
- Re: [bess] comment on draft-ietf-bess-ir Lucy yong
- Re: [bess] comment on draft-ietf-bess-ir Lucy yong
- Re: [bess] comment on draft-ietf-bess-ir Jeffrey (Zhaohui) Zhang
- Re: [bess] comment on draft-ietf-bess-ir Lucy yong
- Re: [bess] comment on draft-ietf-bess-ir Eric C Rosen
- Re: [bess] comment on draft-ietf-bess-ir Jeffrey (Zhaohui) Zhang
- Re: [bess] comment on draft-ietf-bess-ir Lucy yong
- Re: [bess] comment on draft-ietf-bess-ir Lucy yong
- Re: [bess] comment on draft-ietf-bess-ir Jeffrey (Zhaohui) Zhang
- Re: [bess] comment on draft-ietf-bess-ir Eric C Rosen
- Re: [bess] comment on draft-ietf-bess-ir Eric C Rosen
- Re: [bess] comment on draft-ietf-bess-ir Lucy yong
- Re: [bess] comment on draft-ietf-bess-ir Lucy yong
- Re: [bess] comment on draft-ietf-bess-ir Lucy yong
- Re: [bess] comment on draft-ietf-bess-ir Lucy yong
- Re: [bess] comment on draft-ietf-bess-ir Eric C Rosen
- Re: [bess] comment on draft-ietf-bess-ir Lucy yong
- Re: [bess] comment on draft-ietf-bess-ir Jeffrey (Zhaohui) Zhang
- Re: [bess] comment on draft-ietf-bess-ir Lucy yong
- Re: [bess] comment on draft-ietf-bess-ir Eric C Rosen
- Re: [bess] comment on draft-ietf-bess-ir Lucy yong
- Re: [bess] comment on draft-ietf-bess-ir Lucy yong
- Re: [bess] comment on draft-ietf-bess-ir Jeffrey (Zhaohui) Zhang
- Re: [bess] comment on draft-ietf-bess-ir Lucy yong
- Re: [bess] comment on draft-ietf-bess-ir Jeffrey (Zhaohui) Zhang
- Re: [bess] comment on draft-ietf-bess-ir Lucy yong
- Re: [bess] comment on draft-ietf-bess-ir Jeffrey (Zhaohui) Zhang
- Re: [bess] comment on draft-ietf-bess-ir Lucy yong
- Re: [bess] comment on draft-ietf-bess-ir Jeffrey (Zhaohui) Zhang
- Re: [bess] comment on draft-ietf-bess-ir Lucy yong
- Re: [bess] comment on draft-ietf-bess-ir Jeffrey (Zhaohui) Zhang
- Re: [bess] comment on draft-ietf-bess-ir Lucy yong
- Re: [bess] comment on draft-ietf-bess-ir Jeffrey (Zhaohui) Zhang
- Re: [bess] comment on draft-ietf-bess-ir Lucy yong
- Re: [bess] comment on draft-ietf-bess-ir Eric C Rosen