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
_______________________________________________
sidr mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/sidr
