Subject: [Idr] Fwd: I-D Action:draft-jasinska-ix-bgp-route-server-01.txt

From: Elisa Jasinska <[email-masked]>
Date: Tue, 26 Oct 2010 03:17:29 +0200

Hello,

after presenting draft-jasinska-ix-bgp-route-server-00 in the GROW WG in
Maastricht, we have been advised to also point the IDR WG to the
document. Including the feedback we received at GROW, -01 of the
document has been submitted and we have been given the chance to discuss
this at the next IDR WG meeting in Beijing. In the meantime, comments
would be much appreciated.

Best regards
Elisa

-------- Original Message --------
Subject: I-D Action:draft-jasinska-ix-bgp-route-server-01.txt
Date: Mon, 25 Oct 2010 17:00:02 -0700 (PDT)
From: [email-masked]
Reply-To: [email-masked]
To: [email-masked]

A New Internet-Draft is available from the on-line Internet-Drafts
directories.

	Title           : Internet Exchange Route Server
	Author(s)       : E. Jasinska, et al.
	Filename        : draft-jasinska-ix-bgp-route-server-01.txt
	Pages           : 17
	Date            : 2010-10-25

The growing popularity of Internet exchange points (IXPs) brings a
new set of requirements to interconnect participating networks.
While bilateral exterior BGP sessions between exchange participants
were previously the most common means of exchanging reachability
information, the overhead associated with dense interconnection has
caused substantial operational scaling problems for Internet exchange
point participants.

This document outlines a specification for multilateral
interconnections at IXPs.  Multilateral interconnection is a method
of exchanging routing information between three or more BGP speakers
using a single intermediate broker system, referred to as a route
server.  Route servers are typically used on shared access media
networks such as Internet exchange points (IXPs), to facilitate
simplified interconnection between multiple Internet routers on such
a network.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-jasinska-ix-bgp-route-server-01.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.

---

From: John Leslie <[email-masked]>
Date: Tue, 26 Oct 2010 08:35:10 -0400

> would be much appreciated.

   I believe you will need to add text about 4-octet vs. 2-octet ASN
representations.

--
John Leslie <[email-masked]>

---

From: Elisa Jasinska <[email-masked]>
Date: Tue, 26 Oct 2010 15:27:59 +0200

Hi John,

>    I believe you will need to add text about 4-octet vs. 2-octet ASN

Do you have anything specific in mind? I believe nothing with regards to
AS4 will change the route servers behavior per se, except for the needed
changes in BGP itself, which would also apply in this case.

Regards
Elisa

---

From: Robert Raszuk <[email-masked]>
Date: Tue, 26 Oct 2010 16:32:53 +0200

Hi Elisa,

I think John brings actually a very valid point which we did not spelled 
out well in our draft yet.

By design we assumed that route server should be transparent for the 
AS_PATH. Well this is not really the case for the 4 octet AS peers 
interworking to 2 octet AS peers.

So at min we should add a paragraph stating that when RS is in the 
middle of clients which are capable and exchanging 4 octet ASs with 
those which are not supporting 4 octet ASes the set of procedures from 
sections  4.2.2 and 4.2.3 of RFC4893 does apply making the RS 
responsible for the correct injection of AS_TRANS.

Cheers,
R.

>> Elisa Jasinska<[email-masked]>  wrote:
>>>
> _______________________________________________
> Idr mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/idr
>

---

From: Elisa Jasinska <[email-masked]>
Date: Wed, 27 Oct 2010 12:55:24 +0200

Hey,

alright, point taken. Not that this would change the conventional BGP
behavior, yet pointing it out in the section on the AS_PATH attribute
might be worthwhile, since we state:

   ... the route server SHOULD NOT prepend its own AS number to the
AS_PATH segment nor modify the AS_PATH segment in any other way.

Regards
Elisa

---

From: Aleksi Suhonen <[email-masked]>
Date: Fri, 29 Oct 2010 11:27:09 +0000

> AS_PATH segment nor modify the AS_PATH segment in any other way.

We've reserved AS197032 for the route server at TREX. When we get the 
first 32bit ASN peer for that route server, it will have to start doing 
magic with the AS_PATH when reflecting routes learned from that peer to 
legacy peers.

-- 
	Aleksi Suhonen, Researcher
	Department of Communications Engineering
	Tampere University of Technology