[j-nsp] flow-route questions.

[Krasimir Avramski]

Hi, 


> While thinking about using RFC5575 (flow routes), i found at
> least some questions that i'm not able to answer.
> 
> a) RFC clearly states that 'flow routes must be validated'
> and describes validation procedure using destination-prefix
> attribute. But at the same time RFC does not enforce
> destination-prefix attribute to be present in flow specifications,
> and does not provide any detail on how to validate flow specifications
> missing destination-prefix - i.e., should validation procedure
> drop them all or should it accept all such flowspecs ?
> I suppose that as the latter case opens a too large security hole
> (imagine customer that blackholes all google.com by setting only
> source-address), JunOS implements former case at least on eBGP links,
> but that behaviour is not confirmed in documentation...
> 

If destination-prefix is missing implementation tend to default(0.0.0.0/0),
so you MUST have active default route pointing to "originator" in order to
validate.

> b) As far as flow specs are the part of the same BGP session
> as the usual inet-unicast routes - are they subject of the
> same import policy configured for peer/peer-group or the
> validation procedure is the only import policy for these NLRI ?
> If the former case is correct - are there any way to distinguish
> inet-unicast and inet-flow NLRI ? (Why it's important for us:
> we're using prefix-filters to filter our client announces,
> and, as far as we should not require explicit route-object
> configured for any destination client may wish to filter - inet-unicast
> routes should proceed filtered as usually, but for flowspec's
> there is prefix-limit and validation procedure, and that seems
> to be enough).

Flowspecs are subject of import policy

> c) Is there any way to filter some flow specifications from
> client announces ? F.e., i do not like idea that my customer
> may request mapping some traffic to network-control priority
> by the means of flowspecs...


AFAIK current junos implementation doesn't support traffic marking actions.
Since the actions are defined though extended communities it is possible to
filter by matching on them:

policy-statement flow {
    term 1 {
        from {
            rib inetflow.0;
            community rate;
        }
        then reject;
    }
    term 2 {
        then accept;
    }
}
community rate members traffic-rate:*:*;
community redir members redirect:*:*;
community traf-action members traffic-action:*:*;



> d) And, finally: unfortunately, not all our customers runs Juniper :(
> Is there any way to 'translate' some customer updates (classic
> blackhole by /32 route with specific community) into flow routes ?

Might be this requires PSDP RE SDK ;-) or external route server to
translate.

Keep in mind there is no compatibility of flowspecs, extended dhcp
subscriber and input FTF in the same route table.

HTH,
Krasimir
Avramski