Hi Jeff, Please see inline below. > > 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. [Lucy] No, it is not. This is only half of the current behavior. Current solution also requires a node to update mcast state even the RT does not point to the BGP node (as long as the sender node is the child of the node). > > 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? [Lucy] In my proposed solution, N3 will send two updates, the first one with new parent address in RT, the second one is withdraw and have old patent address in RT. RR distributes both two N1 and N2. N2 acts on the first update and become the parent; N1 acts on the second update and remove this child from mcast state. Thanks, Lucy 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
