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

Reply via email to