> [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. [Lucy1] If a node takes an action for a withdraw Leaf A-D route without checking the RT for parenting; the withdraw mechanism does not work. Different PEs may have different parents, one PE sends out a withdraw, MUST NOT result all PEs withdrawing. Lucy Jeffrey > -----Original Message----- > From: Lucy yong [mailto:[email protected]] > Sent: Wednesday, September 23, 2015 2:25 PM > To: Jeffrey (Zhaohui) Zhang <[email protected]<mailto:[email protected]>>; > Eric Rosen > <[email protected]<mailto:[email protected]>>; > [email protected]<mailto:[email protected]> > Cc: [email protected]<mailto:[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]<mailto:[email protected]> > > Cc: [email protected]<mailto:[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]<mailto:[email protected]>>; Eric Rosen > > > <[email protected]<mailto:[email protected]>>; > > > [email protected]<mailto:[email protected]> > > > Cc: [email protected]<mailto:[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]<mailto:[email protected]> > > > Cc: [email protected]<mailto:[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]<mailto:[email protected]>>; Eric Rosen > > > > <[email protected]<mailto:[email protected]>>; > > > > [email protected]<mailto:[email protected]> > > > > Cc: [email protected]<mailto:[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]<mailto:[email protected]> > > > > Cc: [email protected]<mailto:[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]<mailto:[email protected]>>; Eric Rosen > > > > > <[email protected]<mailto:[email protected]>>; > > > > > [email protected]<mailto:[email protected]> > > > > > Cc: [email protected]<mailto:[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]<mailto:[email protected]> > > > > > Cc: [email protected]<mailto:[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]<mailto:[email protected]>>; > > > > > > Jeffrey (Zhaohui) Zhang > > > > > > <[email protected]<mailto:[email protected]>>; > > > > > > [email protected]<mailto:[email protected]> > > > > > > Cc: [email protected]<mailto:[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
