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

[Andrei Robachevsky <[e-mail]>]

Sriram,

Your explanations make it very clear, thanks.

Sriram, Kotikalapudi wrote on 15/07/15 23:20:
> Example 2:
> 
> P---AS A  ---{ RLP(AB) =01 } ---> AS B (cust. of A)  --- { RLP(AB) =01, RLP(BC) =00) } --->  AS C (provider of B)
> 
> B (in the middle) has two providers A and C.
> B learned a route from A and is leaking the route to C, and C detects it.
> C looks at RLP(AB) = 01, and therefore it knows that B's update is a leak.
> So C marks B's update as a route leak.  
> 
>> not necessarily at the adjacent AS (your customer or your peer). 
> 

Yes. What I meant here is a case when you extend your example to AS D (a
peer or a provider of AS C). Assuming that AS C has no route-leak
mitigation policy and propagates the update further, AS D may detect the
leak, which happened somewhere in the path (where precisely - D does not
know and does not need to know).

The only thing that matters is that the update has the RLP field set to
'01' indication for one or more hops (excluding the most recent) in the
AS path (that is what I called the RLP-marked in my note) *and* it does
not come from the upstream/transit provider.


[...]
>>
>> 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.
> 
> Yes, I agree that detecting route leaks from customers/peers matters.
> Detecting route leaks from upstreams/transit providers does not really matter
> (as explained above).

I guess what I am arguing for is that the semantics of RLP 01 should be
"propagate only down" rather than "do not propagate up" and any updates
with the RLP field set from a peer or a customer should be treated as a
leak.

Thanks,

Andrei