Hi Danny,
3) client processing of updates results in placement of ALL
updates in [serialized?] BGP input processing queue with ALL
other updates {m, 1..n}
*Input processing queue typically scheduled in round robin model
4) if n is sufficiently large, many of these updates may
very well still be in the process of being learned from
the external peer(s) (r) and initial convergence function,
and processed behind extraneous reflected routes
5) Serialized processing means all Address Families likely
effected.
I think it is beneficial to as you recommend clarify the real network or
system wide perspective. It sounds terrible to say in general that you
are sending me something which I need to drop. But that would happen
essentially only in 3 cases today (comment if I missed something):
Let's consider the PE1 point of view:
ISP1-
PE1 ---- RR ---- PE2..N
ISP2-
*A* After original BGP session up provided that new paths are considered
as best (as compared to other paths already on RR)
*B* After sending route refresh from PE1 to RR
*C* when PE1 switches his best path from ISP1 to ISP2
I think in both *A* & *C* there is no practical issue as the best paths
RR would send you back are your own best paths which are already
installed. If in the same time you would get some other paths from the
same RR the processing of new paths may be behind a bit.
It will even further be of no issue when folks would start using more
and more add-path feature where path to path switchover would be
triggered by fast IGP flooded event and not by BGP message withdraw.
In the *B* case there could be some unnecessary processing delay
introduced by receiving and dropping your own paths if you ask for all
from RR. And how often for 1/1 you send route refresh may very much
depend on how your implementation deals with paths received. If you
store all of them always you may not need to worry about this case either.
For all other cases those would be just incremental updates - not
something I would suppose we need to worry about at all.
6) Reflected route MAY be legitimate withdraw if alternative
best previously advertised from RR - therefore it must be
processed normally IF received - this is likely one of the
more interesting bits for the RR implementer.
If this is a withdraw of your own path coming back to you from RR it
most likely was originally withdrawn by yourself to the RR isn't it ?
So I think suggestion made by Pradosh to just like we filter at the TCP
replication for rt-constrain in 1/128 do the same based on the
Originator still holds.
It is just a question to quantify how much this filtering would be of
real practical significance.
Cheers,
R.
I believe this is AN issue that implementers should
look at. I understand that there may be efficiencies
in some implementations to copy and it's more complex
to not reflect to client IF Originator == client RID.
-danny
_______________________________________________
GROW mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/grow
