Lucy, > -----Original Message----- > From: Lucy yong [mailto:[email protected]] > Sent: Wednesday, September 23, 2015 11:16 AM > To: Jeffrey (Zhaohui) Zhang <[email protected]>; Eric Rosen > <[email protected]>; [email protected] > Cc: [email protected] > Subject: RE: [bess] comment on draft-ietf-bess-ir > > Hi Jeff, > > To suppress unnecessary redistribution, a P-tunnel BGP node tracks P- > tunnel neighbor state. A BGP next hop is one of P-tunnel downstream > neighbor, upstream neighbor, and N/A. The policy is, if the BGP next hop > of the UPDATE of Leaf A-D route is the downstream neighbor, redistribution > the route; if not, no redistribution. (there may be other polices)
Let me skip this for now. Maybe it'll become a moot point, but we can come back. > > To change the parent, a child sends out the UPDATE of Leaf A-D route with > new patent address in RT, a BGP node receives the update, check the RT on > the UPDATE, > if RT points to the BGP node, > updates mcast state; > end if This is the current behavior. > > after child timer expires, the child sends out the UPDATE of withdraw Leaf > A-D route with old patent address in RT, the old patent will update the > mcast state once receiving the UPDATE. My example explains that, N3 can only send one update, with the new RT. How does the above proposal work in my example setup? Thanks. Jeffrey > > > Lucy > > > > > > -----Original Message----- > From: Jeffrey (Zhaohui) Zhang [mailto:[email protected]] > Sent: Wednesday, September 23, 2015 9:52 AM > To: Lucy yong; Eric Rosen; [email protected] > Cc: [email protected] > Subject: RE: [bess] comment on draft-ietf-bess-ir > > So it's not "BGP session keeps track"; and what's your policy like? > > Back to your proposals: > > >Two potential optimizations I proposed: > > 1) suppress unnecessary redistribution; 2) method for child to change > its patent. > > Using the simple example, what's exactly the proposal for 1) and 2)? > > Jeffrey > > > -----Original Message----- > > From: Lucy yong [mailto:[email protected]] > > Sent: Wednesday, September 23, 2015 10:48 AM > > To: Jeffrey (Zhaohui) Zhang <[email protected]>; Eric Rosen > > <[email protected]>; [email protected] > > Cc: [email protected] > > Subject: RE: [bess] comment on draft-ietf-bess-ir > > > > 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:[email protected]] > > Sent: Wednesday, September 23, 2015 9:36 AM > > To: Lucy yong; Eric Rosen; [email protected] > > Cc: [email protected] > > 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:[email protected]] > > > Sent: Wednesday, September 23, 2015 10:31 AM > > > To: Jeffrey (Zhaohui) Zhang <[email protected]>; Eric Rosen > > > <[email protected]>; [email protected] > > > Cc: [email protected] > > > 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:[email protected]] > > > Sent: Wednesday, September 23, 2015 9:28 AM > > > To: Lucy yong; Eric Rosen; [email protected] > > > Cc: [email protected] > > > 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:[email protected]] > > > > Sent: Wednesday, September 23, 2015 10:26 AM > > > > To: Jeffrey (Zhaohui) Zhang <[email protected]>; Eric Rosen > > > > <[email protected]>; [email protected] > > > > Cc: [email protected] > > > > 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:[email protected]] > > > > Sent: Wednesday, September 23, 2015 9:17 AM > > > > To: Lucy yong; Eric Rosen; [email protected] > > > > Cc: [email protected] > > > > 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:[email protected]] > > > > > Sent: Wednesday, September 23, 2015 9:58 AM > > > > > To: Eric Rosen <[email protected]>; Jeffrey (Zhaohui) Zhang > > > > > <[email protected]>; [email protected] > > > > > Cc: [email protected] > > > > > 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 [email protected] https://www.ietf.org/mailman/listinfo/bess
