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.y...@huawei.com] > Sent: Wednesday, September 23, 2015 10:26 AM > To: Jeffrey (Zhaohui) Zhang <zzh...@juniper.net>; Eric Rosen > <ero...@juniper.net>; draft-ietf-bess...@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:zzh...@juniper.net] > Sent: Wednesday, September 23, 2015 9:17 AM > To: Lucy yong; Eric Rosen; draft-ietf-bess...@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.y...@huawei.com] > > Sent: Wednesday, September 23, 2015 9:58 AM > > To: Eric Rosen <ero...@juniper.net>; Jeffrey (Zhaohui) Zhang > > <zzh...@juniper.net>; draft-ietf-bess...@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 mailing list BESS@ietf.org https://www.ietf.org/mailman/listinfo/bess
