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

[Eric C Rosen <[e-mail]>]

Lucy,

1. Constraining the distribution of Leaf A-D routes.

If you look at sections 9.2.3.2.1 and 9.2.3.4.1 of RFC 6514, you'll see 
that there are some rules that enable you to avoid sending a Leaf A-D 
route on an EBGP session unless a corresponding I/S-PMSI A-D route was 
received over that session.  There are similar rules in RFC 6514 
governing the distribution of C-multicast routes.  These rules are 
intended to prevent the Leaf A-D routes and C-multicast routes from 
being distributed more widely than necessary.  Whether these rules 
always work is questionable; they tend to have hidden assumptions about 
the deployment.

But if you want to investigate ways to optimize the distribution of the 
Leaf A-D routes, that's a good place to start.

One might try the following rule.  If R1 receives a Leaf A-D route, and 
if R1 is not identified in the route's RT, and if the Leaf A-D route has 
a route key that is the NLRI of an S-PMSI A-D route that R1 has 
installed, then only distribute the Leaf A-D route on a BGP session that 
leads to the BGP speaker that is the next hop of the S-PMSI A-D route. 
Whether this rule actually works in various deployment scenarios would 
require further investigation.

[Lucy] 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.

I don't understand this proposal; I don't see how you can tell by 
examining the next hop of the Leaf A-D route whether you need to 
redistribute the route.  A rule based on the next hop of the 
corresponding I/S-PMSI A-D route sounds more promising.

Another approach would be to use Constrained Route Distribution.  This 
would ensure that the Leaf A-D route reaches its target, and would 
prevent the route from traveling over "unnecessary" alternate paths.  In 
certain deployment scenarios, ORF is also available as a way to prevent 
routes from being distributed unnecessarily.  Both these methods are 
forms of RT-based filtering, and both are independent of MVPN.

Of course, one also has to worry about creating a robustness problem if 
route distribution is constrained so that routes follow only one path.

Since the topic of this thread is "comment on draft-ietf-bess-ir", and 
since that draft is in WGLC, I'll just point out again that this issue 
is not specific to ingress replication.

[Lucy] IMO: this mechanism for membership announcement raises a BIG 
concern on the scalability and performance. Why is it not a concern for you?

I wouldn't say it's not a concern, but it's important not to focus 
exclusively on the worst case.  Typical deployment scenarios don't come 
close to the worst case, and there are various tools and filtering 
policies that can be used to constrain the distribution of updates based 
on the RTs.

2. Changing your parent on an IR tree

I think we have a disconnect here, having to do with the layering 
between the MVPN application and BGP.

MVPN can create a route and give it to BGP.  MVPN can set and modify 
attributes of the route.  MVPN can withdraw the route.  But the 
distribution of the route is controlled by BGP.

MVPN cannot tell BGP "send an update for NLRI X with attribute A1 on BGP 
session S1, but send an update for NLRI X with attribute A2 on BGP 
session S2".  MVPN cannot tell BGP "send an update for NLRI X on session 
S1 but send a withdraw for NLRI X on session S2."  And MVPN cannot 
control the timing of BGP's route distribution procedures.

In short, MVPN does not create and send the update messages.

[Lucy] To change the parent, a child sends out the UPDATE of Leaf A-D 
route with new parent address in RT.

MVPN can tell BGP to change the RT and the PMSI Tunnel attribute on a 
given Leaf A-D route.  Suppose MVPN replaces the RT so that the RT now 
identifies the new parent rather than the old one.

If Constrained Route Distribution is being used, this will cause an 
explicit withdraw to be sent to the old parent.  There is no way for the 
MVPN process in the child node to control the timing of this BGP message.

If Constrained Route Distribution is not being used, changing the RT 
will cause BGP to send a new update to the old parent as well as to the 
new parent.  The old parent will treat this as a replacement route, and 
will consider the old route to have been (implicitly) withdrawn.  This 
behavior is mandated by section 3.1 of RFC4271.  Since the old parent is 
not identified in the RT, the action it must take is the action 
specified for the withdrawal of a Leaf A-D route.

Now suppose MVPN doesn't simply replace the RT on the Leaf A-D route, 
but adds a second RT, identifying the new parent.  MVPN would also have 
to replace the PMSI Tunnel attribute, to specify a new label for the new 
parent to use.  The old parent would see this route as a replacement 
route.  The route still identifies the old parent, but has a new label 
in its PMSI Tunnel attribute.  So the old parent will continue sending 
traffic to the child, but will use the new label.  Now both old and new 
parents are using the same label, and the result will be data duplication.

I don't think there is any feasible way to switch parents in a "make 
before break" fashion without requiring the old parent to have some 
explicit knowledge that the switch is taking place.  The procedure we 
chose is to have the old parent time out the data plane entry for the 
child.  While this is not the only possible procedure, I don't think 
there is anything both (a) simpler and (b) compatible with BGP's route 
distribution procedures and with the layering between MVPN and BGP.

Of course, one could modify the MVPN/BGP layering by building more 
MVPN-specific knowledge into BGP, one one could even decide that section 
3.1 of RFC4271 shouldn't apply to Leaf A-D routes .  Certainly there are 
some cases where BGP knows that certain MCAST-VPN routes have to be 
handled in a special way.  But that's a lot more complicated than having 
the parent node simply run a timer to time out the data plane states 
when a route is withdrawn.

Eric