Subject: [Idr] FW: New Version Notification for draft-francois-idr-rs-addpaths-00.txt

From: "Juan Camilo Cardona" <[email-masked]>
Date: Fri, 7 Feb 2014 17:31:30 +0100

Hello all,

We just submitted a draft describing the application of ADD-PATH in eBGP route server scenarios. The document describes the use of ADD-PATH in order to increase the path diversity received by route server clients. The draft also discusses some operational practices and errors that might appear under those environments. Any feedback is appreciated.

Best regards,

Camilo Cardona

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: viernes, 07 de febrero de 2014 16:11
To: Jeffrey Haas; Jeffrey Haas; Pierre Francois; Adam Simpson; Camilo Cardona; Adam Simpson; Camilo Cardona; Pierre Francois
Subject: New Version Notification for draft-francois-idr-rs-addpaths-00.txt

A new version of I-D, draft-francois-idr-rs-addpaths-00.txt
has been successfully submitted by Camilo Cardona and posted to the IETF repository.

Name:		draft-francois-idr-rs-addpaths
Revision:	00
Title:		ADD-PATH for Route Servers
Document date:	2014-02-07
Group:		Individual Submission
Pages:		6
URL:            http://www.ietf.org/internet-drafts/draft-francois-idr-rs-addpaths-00.txt
Status:         https://datatracker.ietf.org/doc/draft-francois-idr-rs-addpaths/
Htmlized:       http://tools.ietf.org/html/draft-francois-idr-rs-addpaths-00

Abstract:
   BGP speakers in Internet Exchange Points exchange routes with a large
   number of peers.  To reduce the burden of maintaining many sessions,
   IXPs implement and administrate BGP route servers.  Route servers
   announce to their clients the paths of multiple peers by using a
   single eBGP session.  Route servers, however, are restricted to
   propagating a single path per NLRI per eBGP session.  This constraint
   affects the path diversity received by clients, which could use paths
   that they would not have chosen, had they known all possible paths.
   To overcome this limitation, we propose in this draft the extension
   of ADD-PATH to eBGP peers in the context of route servers.

Please note that it may take a couple of minutes from the time of submission until the htmlized version and diff are available at tools.ietf.org.

The IETF Secretariat

---

From: Robert Raszuk <[email-masked]>
Date: Fri, 7 Feb 2014 18:35:17 +0100

Hi Juan
 
& Pierre,

Few points on this (as this topic has already been discussed in the past).

* It is reasonable to expect that operator would like to adjust such limit
on a per AFI/SAFI basis. Since you are using capability for the messaging
it and since dynamic capabilities are not practically deployed anywhere
this will mean session reset .. including those AFI/SAFI which are not
affected.

If you ask me how to encode this I would suggest new ORF type and new minor
extension to RTC. At least you will be able to adjust the value without
breaking things.

* For IBGP we always strive to make the number of paths consistent in the
AS. That's why there is normally no drop of some paths policy on IBGP
keeping IBGP mesh consistent.

This is true especially for cases where no encapsulation is used in the
domain
 
and  excludes SAFI 128 PE where it does drop on IBGP unneeded VPN prefixes.

* For EBGP cases one could argue that the below is too strong:

" the other party must configure  an ADD-PATH mode that does not overload
the memory of other device."

Clearly there is no MUST ... as such EBGP peer may
 
simply
 
drop over N paths by inbound policy. Therefor sender may still use "send
all" mode.

Thx,
R.

On Fri, Feb 7, 2014 at 5:31 PM, Juan Camilo Cardona <
[email-masked]> wrote:

> Hello all,
>
> We just submitted a draft describing the application of ADD-PATH in eBGP
> route server scenarios. The document describes the use of ADD-PATH in order
> to increase the path diversity received by route server clients. The draft
> also discusses some operational practices and errors that might appear
> under those environments. Any feedback is appreciated.
>
> Best regards,