Re: [GROW] draft-raszuk-diverse-bgp-path-dist-01 working group document

[Robert Raszuk <[e-mail]>]

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 [e-mail] https://www.ietf.org/mailman/listinfo/grow
>