Re: RFC 4360 clarification (BGP Extended Communities Attribute)

Hi Bruno,

| We have a clarification question regarding RFC 4360. Section "6.
| Operations" states that "If a route has a non-transitivity extended
| community, then before advertising the route across the Autonomous
| System boundary the community SHOULD be removed from the route."
| 
| Is it compliant with the specification to:
| -a- set / add, on the outbound policy of an eBGP session, a non
| transitive extended community?
| -b- expect that the eBGP peer will not remove it to enforce the
| non-transitivity?
| 
| It seems to us that this is compliant:
| -a- seems to be inlined with the operation of well know communities
| defined in RFC 1997 where the advertisement restrictions applies when
| BGP receive a route with this community, not when it advertise it.
| -b- RFC 4360 does not ask the eBGP to enforce the non-transitivity
(and
| besides, non-transivity is a SHOULD, not a MUST)
| 
| - Could you please correct or confirm this?
| - If your BGP implementation removes a non-transitive community
| received
| over an eBGP session, could you please tell us? (either privately or
on
| the mailing list).

The implementations I know of will strip out the non-transitive extcomms
even if they get attached through the outbound policy before advertising

Re: RFC 4360 clarification (BGP Extended CommunitiesAttribute)

>-----Original Message-----
>From: idr-bounces <at> ietf.org [mailto:idr-bounces <at> ietf.org] On 
>Behalf Of Pradosh Mohapatra (pmohapat)
>Sent: Monday, August 03, 2009 1:53 PM
>To: bruno.decraene <at> orange-ftgroup.com; idr <at> ietf.org
>Subject: Re: [Idr] RFC 4360 clarification (BGP Extended 
>CommunitiesAttribute)
>
>Hi Bruno,
>
>
>| We have a clarification question regarding RFC 4360. Section "6.
>| Operations" states that "If a route has a non-transitivity extended
>| community, then before advertising the route across the Autonomous
>| System boundary the community SHOULD be removed from the route."
>| 
>| Is it compliant with the specification to:
>| -a- set / add, on the outbound policy of an eBGP session, a non
>| transitive extended community?
>| -b- expect that the eBGP peer will not remove it to enforce the
>| non-transitivity?
>| 
>| It seems to us that this is compliant:
>| -a- seems to be inlined with the operation of well know communities
>| defined in RFC 1997 where the advertisement restrictions applies when
>| BGP receive a route with this community, not when it advertise it.
>| -b- RFC 4360 does not ask the eBGP to enforce the non-transitivity
>(and
>| besides, non-transivity is a SHOULD, not a MUST)

I-D Action:draft-ietf-idr-add-paths-02.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Inter-Domain Routing Working Group of the IETF.

	Title           : Advertisement of Multiple Paths in BGP
	Author(s)       : D. Walton, et al.
	Filename        : draft-ietf-idr-add-paths-02.txt
	Pages           : 8
	Date            : 2009-08-03

In this document we propose a BGP extension that allows the
advertisement of multiple paths for the same address prefix without
the new paths implicitly replacing any previous ones.  The essence of
the extension is that each path is identified by a path identifier in
addition to the address prefix.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-idr-add-paths-02.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

_______________________________________________
Idr mailing list
Idr <at> ietf.org

I-D Action:draft-ietf-idr-bgp-identifier-10.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Inter-Domain Routing Working Group of the IETF.

	Title           : AS-wide Unique BGP Identifier for BGP-4
	Author(s)       : E. Chen, J. Yuan
	Filename        : draft-ietf-idr-bgp-identifier-10.txt
	Pages           : 5
	Date            : 2009-08-03

To accommodate situations where the current requirements for the BGP
Identifier are not met, this document relaxes the definition of the
BGP Identifier to be a 4-octet unsigned, non-zero integer, and
relaxes the "uniqueness" requirement so that only AS-wide uniqueness
of the BGP Identifiers is required. These revisions to the base BGP
specification do not introduce any backward compatibility issue.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-idr-bgp-identifier-10.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

_______________________________________________
Idr mailing list

BGP Peer Groups

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
_______________________________________________
Idr mailing list
Idr <at> ietf.org
https://www.ietf.org/mailman/listinfo/idr

Re: BGP Peer Groups

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.

Aleksi Suhonen wrote:
> 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.

Re: BGP Peer Groups

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.

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.

Re: BGP Peer Groups

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.

Re: BGP Peer Groups

_______________________________________________
Idr mailing list
Idr <at> ietf.org
https://www.ietf.org/mailman/listinfo/idr

Re: BGP Peer Groups

On Wed, 12 Aug 2009, Christopher Morrow wrote:

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

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: swmike <at> swm.pp.se
_______________________________________________
Idr mailing list
Idr <at> ietf.org
https://www.ietf.org/mailman/listinfo/idr