Re: [sidr] draft-sriram-idr-route-leak-detection-mitigation: difference between a peer and a customer

[Andrei Robachevsky <[e-mail]>]

Thank you for your response, Sriram.

Let me understand the semantics of the RLP field better. I am assuming
that it indicates that a leak happened somewhere in the path, not
necessarily at the adjacent AS (your customer or your peer). If this is
indeed so, the only case I can think of when an RLP-marked update is not
a leak, is when it came from the upstream.

And if we follow the same logic an RLP-marked update from the upstream
can still be a leak (and not just downstream announcements), but I think
it would be difficult to distinguish between the two.

If my considerations are correct, there are only two cases -
upstreams/transit providers, for which RLP doesn't matter, and others
(customers and peers) where an RLP indicates a leak and has to be dealt
accordingly.

Related to the latter - what would be in your opinion a reason to accept
a leaked route? Is it just for reachability (i.e. only one route to the
destination), or are there "legitimate" cases for route leaks?

Thanks,

Andrei

Sriram, Kotikalapudi wrote on 15/07/15 15:03:
> Andrei,
> 
> Thank you for reading the draft and offering comments -- certainly very helpful
> towards refining the proposal as well adding greater clarity in the document.
> 
>> It seems to me that sections 3.2.1. and 3.2.2. propose the same
>> algorithm (modulo the BGP neighbor is a customer or a peer). 
> 
> Your observation is correct. It has to do with the semantics of RLP bits.
> For now, we have RLP = 00 (default; nothing said) and RLP = 01 ('do not propagate up').
> 'Do not propagate up' certainly means that the update should not subsequently 
> propagate from a customer to its provider.
> However, a receiver can (at its own discretion) interpret RLP = 01 more strictly 
> to mean 'do not propagate to provider or peer'. 
> That is because if an ISP is not supposed to forward an update with RLP = 01 
> 'up' to a provider, then normally it should not forward it 'laterally' to a peer either.
> So we have separated the receiver detection procedures for 
> (a) when the update comes from a *customer* (section 3.2.1), and 
> vs. (b) when it comes from a *peer* (section 3.2.2).
> The difference is the stricter interpretation (in Section 3.2.2) of RLP = 01.
> Initially the attempt is to see if we can keep the RLP semantics simple,
> and still accomplish the detection objectives w.r.t. customer/peer. 
> These two section can be merged into one if, for example, 
> RLP = 01 is specified to denote 'do not propagate to provider or peer'.  
> 
>> The difference in the "possible actions" (3.3.) is not clear to me either.
> 
> When an update is detected and 'marked' as 'route leak' (based on section 3.2.1 or 3.2.2 detection),
> then the same/similar method(s) of mitigation can be applied (in the two cases). 
> The draft should not specify a mitigation method because that is left to operator policy.
> So we describe only an *example* policy: Suspend the "prefer customer" policy;
> i.e. instead of a 'marked' update from a customer, prefer an 'unmarked'
> update from a provider or peer. Some similar policy can be applied for a peer. 
> Let the operator decide the actual policy to be used in each case.
> 
>> Finally, what is the proposed action when an RLP-marked update is
>> received from an upstream?
> 
> Good point. The draft currently does not discuss this. If the customer
> is single-homed and does not have any alternate path for the prefix,
> then it would install the route learned from its sole provider even if it is 'marked'.
> If the customer is multi-homed, it should prefer an 'unmarked' update from 
> one provider over a 'marked' update from another provider. Etc.
> Again these actions/methods are left to operator policy.
> However, in the next revision, we will include a subsection to outline this.  
> 
> Sriram
>