Re: [bess] comment on draft-ietf-bess-ir

[Lucy yong <[e-mail]>]

> [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:[e-mail]]

> Sent: Wednesday, September 23, 2015 2:25 PM

> To: Jeffrey (Zhaohui) Zhang <[e-mail]<mailto:[e-mail]>>; Eric Rosen

> <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>

> Cc: [e-mail]<mailto:[e-mail]>

> 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:[e-mail]]

> > Sent: Wednesday, September 23, 2015 9:52 AM

> > To: Lucy yong; Eric Rosen; [e-mail]<mailto:[e-mail]>

> > Cc: [e-mail]<mailto:[e-mail]>

> > 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:[e-mail]]

> > > Sent: Wednesday, September 23, 2015 10:48 AM

> > > To: Jeffrey (Zhaohui) Zhang <[e-mail]<mailto:[e-mail]>>; Eric Rosen

> > > <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>

> > > Cc: [e-mail]<mailto:[e-mail]>

> > > 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:[e-mail]]

> > > Sent: Wednesday, September 23, 2015 9:36 AM

> > > To: Lucy yong; Eric Rosen; [e-mail]<mailto:[e-mail]>

> > > Cc: [e-mail]<mailto:[e-mail]>

> > > 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:[e-mail]]

> > > > Sent: Wednesday, September 23, 2015 10:31 AM

> > > > To: Jeffrey (Zhaohui) Zhang <[e-mail]<mailto:[e-mail]>>; Eric Rosen

> > > > <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>

> > > > Cc: [e-mail]<mailto:[e-mail]>

> > > > 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:[e-mail]]

> > > > Sent: Wednesday, September 23, 2015 9:28 AM

> > > > To: Lucy yong; Eric Rosen; [e-mail]<mailto:[e-mail]>

> > > > Cc: [e-mail]<mailto:[e-mail]>

> > > > 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:[e-mail]]

> > > > > Sent: Wednesday, September 23, 2015 10:26 AM

> > > > > To: Jeffrey (Zhaohui) Zhang <[e-mail]<mailto:[e-mail]>>; Eric Rosen

> > > > > <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>

> > > > > Cc: [e-mail]<mailto:[e-mail]>

> > > > > 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:[e-mail]]

> > > > > Sent: Wednesday, September 23, 2015 9:17 AM

> > > > > To: Lucy yong; Eric Rosen; [e-mail]<mailto:[e-mail]>

> > > > > Cc: [e-mail]<mailto:[e-mail]>

> > > > > 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:[e-mail]]

> > > > > > Sent: Wednesday, September 23, 2015 9:58 AM

> > > > > > To: Eric Rosen <[e-mail]<mailto:[e-mail]>>; Jeffrey (Zhaohui) Zhang

> > > > > > <[e-mail]<mailto:[e-mail]>>; [e-mail]<mailto:[e-mail]>

> > > > > > Cc: [e-mail]<mailto:[e-mail]>

> > > > > > 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

> > > > > >

> > > > > >