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

From: "Peter Schoenmaker" <[email-masked]>
Date: Thu, 25 Mar 2010 14:32:24 -0700

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.

Thanks

Peter -- Chris

---

From: Danny McPherson <[email-masked]>
Date: Sat, 27 Mar 2010 11:33:01 -0600

> I would like to get the feedback of the list on if we should adopt this

I support it, perhsps unsurprisingly..

-danny

---

From: Lixia Zhang <[email-masked]>
Date: Sat, 27 Mar 2010 11:14:51 -0700

> I support it, perhsps unsurprisingly..

me too

Lixia

---

From: [email-masked]
Date: Sat, 27 Mar 2010 21:46:31 +0200

>> 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

>> I would like to get the feedback of the list on if we should adopt

>> this

>> document.

I support it also

Roman

---

From: Shane Amante <[email-masked]>
Date: Sun, 28 Mar 2010 12:23:39 -0600

> I would like to get the feedback of the list on if we should adopt this

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 authors and/or WG agree with the above approach.

-shane

---

From: Robert Raszuk <[email-masked]>
Date: Sun, 28 Mar 2010 20:51:25 +0200

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.

>> distribution of diverse BGP paths.  The question was put at the
>> session on whether to adopt this document as working group
>> document.
>>
>> this document.
> 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-masked] https://www.ietf.org/mailman/listinfo/grow
>