Subject: Re: [Idr] IDR WG LC on draft-ietf-idr-ix-bgp-route-server (2/2/2015 - 2/16/2015)

From: "Susan Hares" <[email-masked]>
Date: Mon, 2 Feb 2015 12:36:21 -0500

WG LC  is from 2/2/2015 to 2/16/2015 

From: Idr [mailto:[email-masked]] On Behalf Of Susan Hares
Sent: Monday, February 02, 2015 11:42 AM
To: idr wg
Subject: [Idr] IDR WG LC on draft-ietf-idr-ix-bgp-route-server

This begins a 2 week WG LC for draft-ietf-ix-bgp-route-server-06, and a 2
week WG adoption/LC for the associated WG report. 

You can find these drafts at:   

http://datatracker.ietf.org/doc/draft-ietf-idr-ix-bgp-route-server/

http://datatracker.ietf.org/doc/draft-jasinska-ix-bgp-route-server-implement
ation/

The draft-ietf-ix-bgp-route-server has demonstrated interoperability between
Cisco, Quagga, and BIRD. 

Please comment on if you feel this is useful for operating exchange points,
and include in your comments support or no support. 

Sue Hares and John Scudder

---

From: Eduardo Ascenço Reis <[email-masked]>
Date: Wed, 4 Feb 2015 13:24:48 -0200

Dear Chairs and WG,

As an introduction, I am the technical manager and engineer leader of
PTT.br - the Brazilian Internet Exchange (IX) Point project.

PTT.br was started in 2004 and today it has 25 IX in production.

Information about aggregated traffic (agregado), network topology
(PIX) and participants AS (participantes) can be found for each
location on the URL bellow:

http://ptt.br/particip/sp

By the way, on the participants pages, ATM means in Portuguese Acordo
de Troca de Tráfego Multilateral or Multi-Lateral Peering Agreements
(MLPA).

For those interest on more information about PTT.br, please take a
look at [1] and [2] references in English.

PTT.br always used route servers as the control plane controller for
the MLPA on all and each IX location.

MLPA respond for more than 70% of traffic (the remaining if associated
with Bilateral Peering Agreements) and it has a fundamental importance
on PTT.br growth experience.

On most PTT.br IX locations two route servers are used for redundancy.
The biggest and most important (number of participants and traffic)
location is Sao Paulo, followed not close by Rio de Janeiro. On these
both locations PTT.br is using since last year four route servers for
network topology and implementation redundancy.

PTT.br provides looking glass (LG) access to route collector for real
time check. Sao Paulo IX lg is also running quagga and can be accessed
by:

telnet lg.sp.ptt.br

PTT.br has intensive use of all 3 route servers implementations (bird,
cisco and quagga) and confirm they accordance to the Implementation
Report.

Finally I strongly support both documents.

Regards,

Eduardo Ascenço Reis
eascenco [ @nic.br | @ptt.br | @gmail.com ]

[1] Peering in Brazil
PTT.br
IETF 88th – ISOC Panel
Regional Interconnection Overview
Vancouver, BC, Canada
November 6, 2013
http://ptt.br/doc/nic.br.ptt.br.ietf88.isoc.peering-brazil.2013110503.pdf

[2] PTT.br Report of the
FIFA World Cup Brazil 2014
Euro-ix
Bucharest, Romania
October 29th 2014
http://ptt.br/doc/nic.br.ptt.br.worldcup.report.euro-ix.20141024.pdf

2015-02-02 15:36 GMT-02:00 Susan Hares <[email-masked]>:
> http://datatracker.ietf.org/doc/draft-jasinska-ix-bgp-route-server-implementation/
>
>
>
> _______________________________________________
> Idr mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/idr
>

---

From: "Susan Hares" <[email-masked]>
Date: Wed, 4 Feb 2015 10:26:33 -0500

Eduardo:

Thank you for your excellent feedback.  This really  helps us understand the quality of this work. 

Sue 

-----Original Message-----
From: Idr [mailto:[email-masked]] On Behalf Of Eduardo Ascenço Reis
Sent: Wednesday, February 04, 2015 10:25 AM
To: Susan Hares
Cc: idr wg
Subject: Re: [Idr] IDR WG LC on draft-ietf-idr-ix-bgp-route-server (2/2/2015 - 2/16/2015)

Dear Chairs and WG,

As an introduction, I am the technical manager and engineer leader of PTT.br - the Brazilian Internet Exchange (IX) Point project.

Information about aggregated traffic (agregado), network topology
(PIX) and participants AS (participantes) can be found for each location on the URL bellow:

By the way, on the participants pages, ATM means in Portuguese Acordo de Troca de Tráfego Multilateral or Multi-Lateral Peering Agreements (MLPA).

For those interest on more information about PTT.br, please take a look at [1] and [2] references in English.

PTT.br always used route servers as the control plane controller for the MLPA on all and each IX location.

MLPA respond for more than 70% of traffic (the remaining if associated with Bilateral Peering Agreements) and it has a fundamental importance on PTT.br growth experience.

On most PTT.br IX locations two route servers are used for redundancy.
The biggest and most important (number of participants and traffic) location is Sao Paulo, followed not close by Rio de Janeiro. On these both locations PTT.br is using since last year four route servers for network topology and implementation redundancy.

PTT.br provides looking glass (LG) access to route collector for real time check. Sao Paulo IX lg is also running quagga and can be accessed
by:

telnet lg.sp.ptt.br

PTT.br has intensive use of all 3 route servers implementations (bird, cisco and quagga) and confirm they accordance to the Implementation Report.

Regards,

Eduardo Ascenço Reis

[1] Peering in Brazil
PTT.br
IETF 88th – ISOC Panel

[2] PTT.br Report of the

2015-02-02 15:36 GMT-02:00 Susan Hares <[email-masked]>:
> This begins a 2 week WG LC for draft-ietf-ix-bgp-route-server-06, and 
> a 2 week WG adoption/LC for the associated WG report.
>
>
>
> The draft-ietf-ix-bgp-route-server has demonstrated interoperability 
> between Cisco, Quagga, and BIRD.
>
>
>
> Please comment on if you feel this is useful for operating exchange 
> points, and include in your comments support or no support.
>
>
>
>
>

---

From: Randy Bush <[email-masked]>
Date: Tue, 10 Feb 2015 20:30:41 +0700

you might find

   draft-ymbk-idr-rs-bfd-00.txt

interesting.  or not.

randy

---

From: Nick Hilliard <[email-masked]>
Date: Wed, 11 Feb 2015 16:21:07 +0000

>    draft-ymbk-idr-rs-bfd-00.txt

definitely interesting.  This seems to be similar to an idea that Dave
Freedman put forward a couple of years ago in an unpublished draft which
was tentatively named draft-scholl-idr-advisory-01-df-input.  It would be
appropriate to mention him in the acknowledgements.

Overloading NHIB announcements with these semantics is a mistake, in part
because because not all announcements to an IXP RS will have next-hop-self
set.  This means that the set of NHs received from a client could include
routers outside the administrative control of the announcing router and
that could potentially cause a good deal of trouble.  In a RS scenario,
each client router should only be able to authoritatively announce what it
can handle.

It would be more sensible to define a new bgp attribute to allow RS clients
to announce BFD candidacy to the RSN and to allow the RS to announce a list
of potential BFD candidates to each client, along with a set of rules to
determine how bfd sessions would be set up, what protocols should be
included, etc.

Nick

---

From: Randy Bush <[email-masked]>
Date: Thu, 12 Feb 2015 22:21:00 +0700

i support publication of draft-ietf-idr-ix-bgp-route-server-06.txt

i am concerned by path hiding; though i realize it is hard to fix;
multi-rib being resource intensive.  diverse- and add-path are grotty
and not light-weight.  but MLPA is less and less common on IXen.  i
guess i can live with the SHOULD.

randy

---

From: Nick Hilliard <[email-masked]>
Date: Sat, 14 Feb 2015 14:54:25 +0000

On 12/02/2015 15:21, Randy Bush wrote:
> but MLPA is less and less common on IXen.

Reality - with its well known liberal bias - may disagree with you on this
point.

https://www.euro-ix.net/documents/1467-euro-ix-route-servers-stats-pdf

Nick

---

From: Randy Bush <[email-masked]>
Date: Sun, 15 Feb 2015 01:39:06 +0900

> Reality - with its well known liberal bias - may disagree with you on
> this point.

having trouble finding data for or against in that (nice) report (from
liberal europe:-)

randy

---

From: Thomas Mangin <[email-masked]>
Date: Sun, 15 Feb 2015 10:28:14 +0000

Just in time for it : I am supporting this draft.

Thomas
> Susan Hares <mailto:[email-masked]>
> 2 February 2015 17:36
>
> *From:*Idr [mailto:[email-masked]] *On Behalf Of *Susan Hares
> *Sent:* Monday, February 02, 2015 11:42 AM
> *To:* idr wg
> *Subject:* [Idr] IDR WG LC on draft-ietf-idr-ix-bgp-route-server
>
>  
>
>  
>
> ------------------------------------------------------------------------

-- 
Thomas
--
http://exa.net.uk/about/contact-us

---

From: Andy Davidson <[email-masked]>
Date: Mon, 16 Feb 2015 12:26:08 +0000

> WG LC  is from 2/2/2015 to 2/16/2015
[…]
> This begins a 2 week WG LC for draft-ietf-ix-bgp-route-server-06, and a 2 week WG adoption/LC for the associated WG report.
> Please comment on if you feel this is useful for operating exchange points, and include in your comments support or no support.

Colleagues,

Route-servers are an operational reality and norm at modern Internet Exchange Points.  80% of exchange points belonging to the European Internet Exchange Association (Euro-IX) operate a route-server service for their exchange participants [0], and in my anecdotal experience as an operator of two other exchanges in the UK (LONAP - 100Gbit/traffic, 150 participants & IXLeeds - 4Gbit/traffic, 15 participants), they are requested, expected, and **USED** by over three quarters of exchange participants.

Route-servers are growing in popularity, in 2010 only half of the Euro-IX membership operated and offered route-servers.

This seems to be a worldwide phenomenon, I also work with the NapAfrica exchange which has a 94% adoption rate for the route-servers on the largest peering LAN and a 100% adoption rate on the smallest peering LAN.  They’re also a popular service on exchange points I help run in North America.  Several exchange point operators in Asia have previously asked for my route-server configuration generator scripts (I pray that are all migrated to IXP Manager now).

A great deal of work has been undertaken by the Euro-IX and wider peering community to make route-servers more reliable.  Back in the dinosaur days of the late 2000s, we didn’t have route-servers that could support multiple-RIBs, and had to put up with route-servers with poor convergence performance leading to blackholing of traffic whilst withdraws trickled through poorly performing route-server code. We started to write down what we wanted, no needed, the route servers to DO, and worked with the software vendors to get these features built in.  The result was better performing, tested software that was compliant against this stack.  [1]

The idea that our loosely defined, and these days only committed to memory, list of wishes could instead be a document … an IETF document! … with wider industry support, that can be used to describe our needs to the next generation of route-server software vendors is fantastic.  I fully and wholeheartedly support the publication of this document.

We’ve accidentally, in this thread, gone down the path of considering whether they are the best way forward for multilateral/mass peering.  No they’re not, and let’s do some work to find something better.  But MLPA route-servers are here for a long time to come, so let’s publish this excellent specification document right away.

[0] https://www.euro-ix.net/documents/1467-euro-ix-route-servers-stats-pdf?download=yes

[1] http://www.uknof.org.uk/uknof15/Davidson-Bakeoff.pdf

— 
Regards, Andy Davidson

Relavent hats to this conversation:
Board member, European Internet Exchange Association
Director & Chairman, LONAP Ltd., IXLeeds Ltd. (United Kingdom)
Council member, NapAfrica (South Africa)
Vice President European Ops, IIX Inc. (North America)

---

From: Randy Bush <[email-masked]>
Date: Mon, 16 Feb 2015 22:09:43 +0900

> We’ve accidentally, in this thread, gone down the path of considering
> whether they are the best way forward for multilateral/mass peering.

wow!  i missed that.  you must have been following the thread better
than i.  got a pointer?

randy

---

From: Andy Davidson <[email-masked]>
Date: Mon, 16 Feb 2015 13:17:40 +0000

On 16 Feb 2015, at 13:09, Randy Bush <[email-masked]> wrote:

> wow!  i missed that.  you must have been following the thread better than i.  got a pointer?

At the risk of opening that subthread up again, the messages around the 'great idea, but why use a RS at all?’ comment from heasley.  

Andy