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

[Lucy yong <[e-mail]>]

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]
Cc: [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]>; Eric Rosen 
> <[e-mail]>; [e-mail]
> Cc: [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]
> Cc: [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]>; Jeffrey (Zhaohui) Zhang 
> > <[e-mail]>; [e-mail]
> > Cc: [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
> >
> >