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

["Sriram, Kotikalapudi" <[e-mail]>]

>Let me understand the semantics of the RLP field better. I am assuming
>that it indicates that a leak happened somewhere in the path, 

RLP field does not indicate (or encode) that a *leak happened*.
It merely facilitates a receiving router to detect if an update
from a sending router (an adjacent AS) is a route leak. 

Example 1: Route for prefix P propagates as follows: 

P---AS A  ---{ RLP(AB) = 01 }---> AS B (cust. of A)  ---{ RLP(BC) = 01, RLP(AB) = 01 }--->  AS C (cust. of B) 

Sequentially, B is a customer of A, and C is a customer of B.    
The expression in wiggly brackets {} shows the RLP values in the prefix update.
A transitive RLP field is added in the update for each hop in the path. 
Each AS sets an RLP value for its hop to the next AS for the route it forwards for prefix P.
RLP = 01 indicates that the update SHOULD NOT be sent 'up' to a provider (or 
'laterally' to a peer), but it is allowed to forward the update to a customer.
So no one in this Example 1 detects a route leak. There is no route leak. 

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). 

As in the examples above, the receiver is only detecting if the update from 
its adjacent router is a route leak. It does so by looking 
at NOT the RLP field value set by the adjacent router 
but the RLP field values set by the ASes that preceded it.

>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.

May be this question goes away in light of the proper understanding 
of RLP field values provided above.
It is true that an upstream provider cannot leak any prefix route to its
customer by definition. Any prefix routes that the upstream has accepted 
(after applying route leak detection/mitigation etc.), the upstream usually send all
those routes to its customer (except those learned from that customer). 
So in general, a customer need not try to detect route leak from its upstream provider
(keep in mind that we are talking about the relationships on per prefix basis).
(Please ignore what I said in my previous reply to you about detecting route
leaks from a provider; the last paragraph.)

We have not used the term "RLP-marked" anywhere in the draft.
So I don't know what exactly you mean by it.
But hopefully the above explanations clarify things for you.
When we say an update is 'marked', it simply means that it was detected 
to be a route leak (as it was received from a neighbor AS). 

>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.

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).

>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?

In this discussion and the draft, we have not called anything a
"legitimate" route leak. But some customer ASes could make mistakes.
For example, if X is single-homed stub customer of Y and Y is a customer of Z,
and if X sets RLP = 01 by mistake in its prefix update to Y, then Z detects and marks
the prefix route from Y as a route leak. 
Z will not have any alternate path for that prefix because X is single-homed stub.
In this case, Z may accept the update for reachability even though it was
detected to be route leak. Again, we don't specify this. 
We only specify the detection method, not the mitigation policy.
 
Thank you.

Sriram