[c-nsp] redistribute routes leaked from another VRF?

[Phil Mayers]

On 06/01/11 13:15, Jeff Bacon wrote:
>> More or less. You can also define an "mdt data" group range. When
>> traffic for a particular (s,g) pair exceeds a configurable threshold,
> a
>> group is picked from this range and that (s,g) transitions to the new
>> group in the default VRF, and PEs with receivers join this group. This
>> means you don't flood high-bandwidth groups to every PE - just to PEs
>> which are interested.
>
> I just noticed this in SXI (only just getting there - I'm trying to read
> through the release notes during morning exercise... could take weeks :(
> ).
>
> This however frightens me, because during that transition it seems as
> though you're bound to drop a packet somewhere. It's ok if you're IPTV
> or some other multimedia streaming, but for financial market data that's
> a no-no of highest order.

Very probably. However this ought to only be an issue for streams where 
listeners are leaving and joining, or the bit-rate is changing to go 
above & below the threshold.

(It's worth noting the threshold detection is a bit sluggish as well - 
on the order of tens of seconds)

Obviously it's not optimal in all conditions.

>> As for MTU - if you're running MPLS you presumably have jumbos enabled
>> anyway?
>
> Doesn't mean your WAN provider gave you enough MTU to fit both headers,
> though. (One provider I work with has all long-haul capped at 1546,
> presumably a holdover from fast-enet days)

True. There are other non-MPLS multicast MTU issues though; we've had 
problems with PIM registered between JunOS and IOS, where IOS fragments 
the inner packet, JunOS the final outer PIM register.

My rule of thumb based on experience here is that multicast with >1400 
byte packets is a grey area.

Is MVR any use to you? We're investigating a hybrid approach where 
certain multicast groups are distributed in the a multicast VLAN using 
MVR and access-lists. This multicast VLAN can then be in the default 
VRF. There are implications for bidirectional traffic of course, due to 
the RPF check...