Hello Shane,
Many thx for the great comment. It is precisely why I asked this to
become a WG document to encourage and solicit more feedback like this.
Let me try to clarify ...
> I will add that it would be nice to briefly consider the operational
> implications of "accidentally" crossing route-reflector planes in a
> future version of this document.
Yes I agree and will be very happy to either add some text or
accommodate text from you.
But this is particularly applicable to the case where RR planes reside
on different RRs or on the same RRs with real clear plane separation
(for example virtual router/logical router plane separation cases).
While we are getting into implementation specifics the other case of the
same RR can be realized with the full sharing of single BGP data
structures allowing such RR to explicitly enable sending 2nd/3rd/nth
best path on a per neighbor/peer group/update group knob basis.
In this latter case which I really meant to be the case of single RR
serving all planes such confusion is unlikely to happen due to the
reasons described above.
Many thx,
R.
On Mar 25, 2010, at 15:32 MDT, Peter Schoenmaker wrote:
Hello,
At the Stockholm IETF Robert Raszuk presented the draft on
distribution of diverse BGP paths. The question was put at the
session on whether to adopt this document as working group
document.
I would like to get the feedback of the list on if we should adopt
this document.
Support/Yes.
I will add that it would be nice to briefly consider the operational
implications of "accidentally" crossing route-reflector planes in a
future version of this document. Specifically, in the case of
co-located route-reflector planes on /existing/ RR's, in my
understanding the only thing keeping the first/primary plane separate
from the secondary/backup plane is use of separate Loopback addresses
on the iBGP sessions. Thus, it is quite likely that an operator may
get those mixed up when establishing iBGP session's for the first&
second control planes. A potentially simple, but effective, existing
method to keep them separate is for operators to use different TCP
MD5 passwords on iBGP sessions for the first, second, third, etc.
sessions in order to ensure consistency of the control plane
sessions. This should still keep things in the realm of using
existing, widely deployed tools with no modifications to existing
code. FWIW, I would be happy to contribute text if the auth ors
and/or WG agree with the above approach.
-shane _______________________________________________ GROW mailing
list [email protected] https://www.ietf.org/mailman/listinfo/grow
_______________________________________________
GROW mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/grow
