| 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: On Wed, Aug 12, 2009 at 12:07 AM, Aleksi Suhonen<Aleksi.Suhonen at tut.fi> 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 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.
I would side with this commentor, that peer-groups alone are just an
implementation optimization (and now a useful operations configuration
widget).
> David Freedman wrote:
>>
>> 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.
>
> Right.
>
>> 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.
>
> 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?
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
_______________________________________________
Idr mailing list
Idr at ietf.org
https://www.ietf.org/mailman/listinfo/idr
|