Lucy, > [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.
That violates BGP rules. The withdraw will reach N2 as well and be treated as withdraw. Jeffrey > -----Original Message----- > From: Lucy yong [mailto:[email protected]] > Sent: Wednesday, September 23, 2015 2:25 PM > 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, > > 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
