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

[Lucy yong <[e-mail]>]

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