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
>
signature.asc
Description: OpenPGP digital signature
_______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr
