Subject: [Idr] BGP Peer Groups

From: Aleksi Suhonen <[email-masked]>
Date: Tue, 11 Aug 2009 12:39:26 +0300

Hi,

I was writing an Internet-Draft on another BGP issue and I needed a 
normative reference for BGP Peer Groups, but couldn't find one. So I 
wrote one myself, because it felt like a good idea at this time:
http://www.axu.tm/2009/draft-axu-bgp-peer-groups.html

I'm looking for:

* Support for the draft or reasons why it's a silly draft.
* Information on any Intellectual Property Rights issues regarding it.
* Co-Authors.
* White papers I could add as informative references.
* Insights from BGP implementors on things I've overlooked.

After a bit of input, I'll actually submit the draft at tools.ietf.org, 
if it still feels like a good idea.

-- 
	Aleksi Suhonen

---

From: David Freedman <[email-masked]>
Date: Tue, 11 Aug 2009 15:19:33 +0100

If you look at the IOS implementation, peer-groups have been decoupled
from "update groups" which are used to group peers to which common
updates are sent.

As an end user of the implementation you can configure the members of
the peer-group but the update-group membership remains internal to the
implementation.

Since there are many different type of groups one can have (same updates
to members, same transport, same timers etc..) would be interested as to
which you refer in these notes, if you really do mean "all" then you
want to revert the behaviour described above which puts control back to
the end user again.

David.

---

From: Aleksi Suhonen <[email-masked]>
Date: Wed, 12 Aug 2009 07:07:29 +0300

Hello again,

I'm generally pleased with the response I've already received to the 
rough draft on BGP peer groups. Here's a short summary:

* Someone from Cisco was interested in extending the draft to cover some 
important challenges in the implementation of peer groups.
* Someone from SixXS.net suggested that maybe it should be a draft on 
"BGP Dos and Don'ts".
* Someone from Sweden pointed out update groups, as did David Freedman 
below.
* Someone from a Central-European ISP said that it's an implementation 
issue and shouldn't be an Internet-Draft at all.

> the peer-group but the update-group membership remains internal to the

Right.

> want to revert the behaviour described above which puts control back to

I wrote the thing quite quickly. I was rather naive and thought only of 
my needs for the other draft, which needs configuration level peer 
groups rather than the more generic update groups.

I think at least update groups definitely fall within the scope of the 
draft. Otherwise it's all still open.

One question I forgot to ask yesterday was:

Should this be experimental, informational, bcp or proposed standard?
 From the responses I've received so far, I gather that it should be bcp.

A new question for today: can this be adopted as a working group 
document, ever?

-- 
	Aleksi Suhonen

---

From: Christopher Morrow <[email-masked]>
Date: Wed, 12 Aug 2009 10:23:09 -0400

On Wed, Aug 12, 2009 at 12:07 AM, Aleksi Suhonen<[email-masked]> wrote:
> Hello again,
>
> I'm generally pleased with the response I've already received to the rough
> draft on BGP peer groups. Here's a short summary:
>
> * Someone from SixXS.net suggested that maybe it should be a draft on "BGP
> Dos and Don'ts".
> * Someone from a Central-European ISP said that it's an implementation issue
> and shouldn't be an Internet-Draft at all.

I would side with this commentor, that peer-groups alone are just an
implementation optimization (and now a useful operations configuration
widget).

> I wrote the thing quite quickly. I was rather naive and thought only of my
> needs for the other draft, which needs configuration level peer groups
> rather than the more generic update groups.
>
> A new question for today: can this be adopted as a working group document,
> ever?

My above comment aside, the GROW chairs (and one of our AD's) was
interested in some more operations focused bgp 'best practices for
configuration' document... Something that at least covered:

1) prefix filtering
2) neighbor safe-guards
3) policy configurations

The peer-group business fits into the best practices doc mold... If
you wanted to expand some I think we would like to chat about it on
the grow mailing list.

-chris

---

From: Andrew Lange <[email-masked]>
Date: Wed, 12 Aug 2009 11:21:06 -0700

I agree with Chris on this.   Peer groups are an implementation  
optimization.  There isn't anything in terms of interoperability that  
needs to be standardized.

However, as part of a BGP configuration best practices in GROW it may  
be a good addition.

Andrew

On Aug 12, 2009, at 7:23 AM, Christopher Morrow wrote:

> document,
> _______________________________________________
> Idr mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/idr
>

---

From: Mikael Abrahamsson <[email-masked]>
Date: Thu, 13 Aug 2009 05:53:32 +0200 (CEST)

> implementation optimization (and now a useful operations configuration 

If the intention is to give router OS manufacturers a hint as what to do 
(and also greenfield rollouts) then advising them to not implementing 
peer-groups but instead peer-templates is definitely very good advice.

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: Christopher Morrow <[email-masked]>
Date: Thu, 13 Aug 2009 00:11:32 -0400

> peer-groups but instead peer-templates is definitely very good advice.

for IDR or for somewhere else? (and explain the difference if possible
between template/group, please.)

---

From: "Ilya Varlashkin" <[email-masked]>
Date: Thu, 13 Aug 2009 09:54:57 +0200

> -----Ursprüngliche Nachricht-----
> If the intention is to give router OS manufacturers a hint as 
> what to do (and also greenfield rollouts) then advising them 
> to not implementing peer-groups but instead peer-templates is 
> definitely very good advice.
> 

Despite all the flexibilities of the templates I find them more cluttering config rather than helping to make it more efficient. Peer-groups for me are good enough and I wouldn't like them to disappear as result of a draft proposing templates as BCP. In any case as previous posters mentioned, either of these is implementation details because it doesn't require cooperation of remote speaker. And therefore draft on peer-groups should be in some other WG but not in IDR.

/iLya

---

From: Mikael Abrahamsson <[email-masked]>
Date: Fri, 14 Aug 2009 04:41:48 +0200 (CEST)

> between template/group, please.)

Peer template is a more flexible way of doing the same thing peer-groups 
are used for, but things can be inherited in a much more flexible way.

http://www.cisco.com/en/US/docs/ios/12_0s/feature/guide/s_bgpct.html