Re: Question on peering strategies

2016-05-23 Thread Reza Motamedi
I'm glad we are having this discussion.

I want to clarify something, since I'm not sure I'm following the
terminology. What Max referred to as  "VLAN exchange" is what Equinix
markets as "*private VLAN"*, right?
I just copy-pasted a portion of Equinix's IX brochure that covers the
services that they offer [
http://www.equinix.com/resources/data-sheets/equinix-internet-exchange/]
Standard Equinix Internet Exchange Features
• Public VLAN — offers access to all peering participants
• Supports industry standard IEEE 802.1Q trunking encapsulation
• Redundant MLPE route servers at each IX Point enabling efficient open
peering
• *Private VLAN* (Required: Unicast Peering VLAN enabled) — create a
private broadcast domain over the public switched infrastructure that can
be used for direct bi-lateral peering or to create a community of interest

My question is what is the point of having such an option for peering? I
understand the argument that Owen and Leo have, which is to move the bigger
portion of traffic away from the IX fabric and keep the IX for smaller
flows. but why would a pair of networks want a private point-to-point
connection on a shared switching fabric. Is this just because that shared
fabric has geographical reach, as in the case of IXReach?

I also see that links provided in this discussion show Europe based
networks that are using this peering type more often. Is this widely
accepted that US market is totally different from Europe?


Best Regards
Reza Motamedi (R.M)
Graduate Research Fellow
Oregon Network Research Group
Computer and Information Science
University of Oregon

On Mon, May 23, 2016 at 9:50 AM, Owen DeLong <o...@delong.com> wrote:

> As mentioned by others, they do exist, but usually not for exactly the
> reason you state.
>
> In most cases, peers go to PNI instead of peering via the exchange when it
> does not make
> sense to grow laterally at the exchange for significant bilateral traffic.
> It’s much
> less expensive to get a cross-connect from my router to your router than
> for both of
> us to add a cross-connect to the exchange and each pay for an additional
> exchange port.
>
> Example: If I have 12.5 gigs of traffic to the exchange and 8 gigs of that
> is to
> autonomous system X while the remaining 4.5 G goes to random other peers,
> then it
> makes much more sense for both X and I to connect directly (PNI) than for
> each of
> us to order an additional exchange port to support that traffic.
>
> Owen
>
> > On May 21, 2016, at 23:33 , Max Tulyev <max...@netassist.ua> wrote:
> >
> > Hi All,
> >
> > I wonder why a "VLAN exchange" does not exists. Or I do not know any?
> >
> > In my understanding it should be a switch, and people connected can
> > easily order a private VLAN between each other (or to private group)
> > through some kind of web interface.
> >
> > That should be a more easy and much less expensive way for private
> > interconnects than direct wires.
> >
> > On 16.05.16 20:46, Reza Motamedi wrote:
> >> Dear Nanogers,
> >>
> >> I have a question about common/best network interconnection practices.
> >> Assume that two networks (let's refer to them as AS-a and AS-b) are
> present
> >> in a colocation facility say Equinix LA. As many of you know, Equininx
> runs
> >> an IXP in LA as well. So AS-as and AS-b can interconnct
> >> 1) using private cross-connect
> >> 2) through the public IXP's switching fabric.
> >> Is it a common/good practice for the two networks to establish
> connections
> >> both through the IXP and also using a private cross-connect?
> >>
> >> I was thinking considering the cost of cross-connects (my understanding
> is
> >> that the colocation provider charges the customers for each
> cross-connect
> >> in addition to the rent of the rack or cage or whatever), it would not
> be
> >> economically reasonable to have both. Although, if the cross-connect is
> the
> >> primary method of interconnection, and the IXP provides a router-server
> the
> >> public-peering over IXP would essentially be free. So it might makes
> sense
> >> to assume that for the private cross-connect, there exists a back-up
> >> connection though the IXP. Anyway, I guess some discussion may give more
> >> insight about which one is more reasonable to assume and do.
> >>
> >> Now my last question is that if the two connections exist (one private
> >> cross-connect and another back-up through the IXP), what are the chances
> >> that periodically launched traceroutes that pass the inter-AS
> connection in
> >> that colo see both types of connection in a week. I guess what I'm
> asking
> >> is how often back-up routes are taken? Can the networks do load
> balancing
> >> on the two connection and essentially use them as primary routes?
> >>
> >> Best Regards
> >> Reza Motamedi (R.M)
> >> Graduate Research Fellow
> >> Oregon Network Research Group
> >> Computer and Information Science
> >> University of Oregon
> >>
>
>


Re: Question on peering strategies

2016-05-16 Thread Reza Motamedi
Hi Nick,

Thanks for the reply.

Let me clarify another issue first, since I thought the colo's business
model is different at least in the US. So if AS-a puts its router in
Equinix, it should pay the same amount in the following two scenario (only
considering the interconnection cost and not the rent for racks and remote
hands and )?
1) AS-a only connects to the IX and establishes all inter-AS connections
through the IX.
2) AS-a connects to the IX, in addition to privately connecting to bunch of
other colo customers (these private connections can be either transit or
settlement-free peerings).
My understanding was that colos in the US charge per cross connect, so the
more you connect privately, the more you pay. This article may be old, but
I don't think much has changed:
https://www.telegeography.com/press/press-releases/2015/02/26/colocation-cross-connect-price-disparities-remain-between-u-s-europe/index.html

With respect to my second question, I was asking if is practical/reasonable
to keep both the connection types to same network (say AS-b) at the same
time, i.e., connect privately over a cross-connect and keep the public
connection over the IX.



Best Regards
Reza Motamedi (R.M)
Graduate Research Fellow
Oregon Network Research Group
Computer and Information Science
University of Oregon

On Mon, May 16, 2016 at 11:10 AM, Nick Ellermann <nellerm...@broadaspect.com
> wrote:

> Reza,
> You maybe overthinking this one a bit. The economics are something to
> consider, however all public exchanges have different economics. With
> Equinix you pay pretty much a flat rate for a single 1Gbps/10Gbps link that
> includes the cost of facility cross-connect and public exchange access.  It
> is a nice one to many connection for all those various network and content
> networks your end users would appreciate direct connectivity. Depending on
> the public exchange you either have a single BGP session or a BGP session
> per network you are peering. Really after that, it's just BGP routing and
> route management. You do need to be careful about not being too overly
> dependent on a single public switch link, in some cases like at Equinix you
> may want multiple connections to redundant public exchange switches at that
> site. There is a balance you want to seek of number of paid upstream
> network transit providers you are connected to versus how many direct
> peering arrangements you have setup. It's not usually practical for a
> smaller network to have loads of BGP peers.  There are lots of good
> articles online about this fine balance and some good advice from
> experienced network operators.
>
> To your later questions. For your simple example, if AS-a and AS-b were
> both already on the public IX, and the link wasn't too overly critical then
> using the public IX switch maybe a good first step. However as that
> relationship matures, they most likely in a real world example may look to
> split the cost of the private cross-connect. If it was mutually beneficial.
> There is much more to public peering and transit than the technical
> conversation. Most of the larger networks on the public switches won't peer
> privately with anyone or only with extremely larger networks. To get a
> provider such as this to peer both privately and on the public exchange is
> not a technical issue, it's more of a business overhead and management
> issue.
> If you have a couple of quality upstream transit providers, they will be
> excellent failovers to a public switch outage.  Plan for the public switch
> to have as many problems as any upstream provider.
>
>
> Sincerely,
> Nick Ellermann – CTO & VP Cloud Services
> BroadAspect
>
> E: nellerm...@broadaspect.com
> P: 703-297-4639
> F: 703-996-4443
>
> THIS COMMUNICATION MAY CONTAIN CONFIDENTIAL AND/OR OTHERWISE PROPRIETARY
> MATERIAL and is thus for use only by the intended recipient. If you
> received this in error, please contact the sender and delete the e-mail and
> its attachments from all computers.
>
> -Original Message-
> From: NANOG [mailto:nanog-bounces+nellermann=broadaspect@nanog.org]
> On Behalf Of Reza Motamedi
> Sent: Monday, May 16, 2016 1:46 PM
> To: nanog@nanog.org
> Subject: Question on peering strategies
>
> Dear Nanogers,
>
> I have a question about common/best network interconnection practices.
> Assume that two networks (let's refer to them as AS-a and AS-b) are
> present in a colocation facility say Equinix LA. As many of you know,
> Equininx runs an IXP in LA as well. So AS-as and AS-b can interconnct
> 1) using private cross-connect
> 2) through the public IXP's switching fabric.
> Is it a common/good practice for the two networks to establish connections
> both through the IXP and also using a private cross-connect?
>
> I was th

Question on peering strategies

2016-05-16 Thread Reza Motamedi
Dear Nanogers,

I have a question about common/best network interconnection practices.
Assume that two networks (let's refer to them as AS-a and AS-b) are present
in a colocation facility say Equinix LA. As many of you know, Equininx runs
an IXP in LA as well. So AS-as and AS-b can interconnct
1) using private cross-connect
2) through the public IXP's switching fabric.
Is it a common/good practice for the two networks to establish connections
both through the IXP and also using a private cross-connect?

I was thinking considering the cost of cross-connects (my understanding is
that the colocation provider charges the customers for each cross-connect
in addition to the rent of the rack or cage or whatever), it would not be
economically reasonable to have both. Although, if the cross-connect is the
primary method of interconnection, and the IXP provides a router-server the
public-peering over IXP would essentially be free. So it might makes sense
to assume that for the private cross-connect, there exists a back-up
connection though the IXP. Anyway, I guess some discussion may give more
insight about which one is more reasonable to assume and do.

Now my last question is that if the two connections exist (one private
cross-connect and another back-up through the IXP), what are the chances
that periodically launched traceroutes that pass the inter-AS connection in
that colo see both types of connection in a week. I guess what I'm asking
is how often back-up routes are taken? Can the networks do load balancing
on the two connection and essentially use them as primary routes?

Best Regards
Reza Motamedi (R.M)
Graduate Research Fellow
Oregon Network Research Group
Computer and Information Science
University of Oregon


Figuring out traceroute

2016-03-10 Thread Reza Motamedi
Hi guys,

This might seem a bit of a trivial question, but I guess there is no harm
in asking. I am looking at a collection of traceroutes all go through the
following consecutive hops (* >> 213.248.98.238), as shown here (I kept the
DNSname just for completeness):

+ From >> To
+ (213.155.130.125:las-b3-link.telia.net) >> (213.248.98.238:b
harti-ic-140621-las-b3.c.telia.net)
+ (213.155.130.127:las-b3-link.telia.net) >> (213.248.98.238:b
harti-ic-140621-las-b3.c.telia.net)
+ (213.155.131.75:las-b3-link.telia.net) >> (213.248.98.238:b
harti-ic-140621-las-b3.c.telia.net)
+ (213.155.131.83:las-b3-link.telia.net) >> (213.248.98.238:b
harti-ic-140621-las-b3.c.telia.net)
+ (213.155.131.85:las-b3-link.telia.net) >> (213.248.98.238:b
harti-ic-140621-las-b3.c.telia.net)
+ (213.155.134.251:las-b3-link.telia.net) >> (213.248.98.238:b
harti-ic-140621-las-b3.c.telia.net)
+ (213.155.134.253:las-b3-link.telia.net) >> (213.248.98.238:b
harti-ic-140621-las-b3.c.telia.net)
+ (213.155.134.77:las-b3-link.telia.net) >> (213.248.98.238:b
harti-ic-140621-las-b3.c.telia.net)
+ (213.155.137.57:las-b3-link.telia.net) >> (213.248.98.238:b
harti-ic-140621-las-b3.c.telia.net)
+ (213.155.137.59:las-b3-link.telia.net) >> (213.248.98.238:b
harti-ic-140621-las-b3.c.telia.net)
+ (62.115.114.111:las-b3-link.telia.net) >> (213.248.98.238:b
harti-ic-140621-las-b3.c.telia.net)
+ (62.115.116.168:las-b3-link.telia.net) >> (213.248.98.238:b
harti-ic-140621-las-b3.c.telia.net)
+ (62.115.116.170:las-b3-link.telia.net) >> (213.248.98.238:b
harti-ic-140621-las-b3.c.telia.net)
+ (62.115.116.174:las-b3-link.telia.net) >> (213.248.98.238:b
harti-ic-140621-las-b3.c.telia.net)
+ (62.115.116.176:las-b3-link.telia.net) >> (213.248.98.238:b
harti-ic-140621-las-b3.c.telia.net)
+ (62.115.116.178:las-b3-link.telia.net) >> (213.248.98.238:b
harti-ic-140621-las-b3.c.telia.net)
+ (62.115.116.180:las-b3-link.telia.net) >> (213.248.98.238:b
harti-ic-140621-las-b3.c.telia.net)
+ (62.115.116.182:las-b3-link.telia.net) >> (213.248.98.238:b
harti-ic-140621-las-b3.c.telia.net)
+ (62.115.116.184:las-b3-link.telia.net) >> (213.248.98.238:b
harti-ic-140621-las-b3.c.telia.net)
+ (62.115.116.186:las-b3-link.telia.net) >> (213.248.98.238:b
harti-ic-140621-las-b3.c.telia.net)
+ (62.115.116.188:las-b3-link.telia.net) >> (213.248.98.238:b
harti-ic-140621-las-b3.c.telia.net)
+ (62.115.116.190:las-b3-link.telia.net) >> (213.248.98.238:b
harti-ic-140621-las-b3.c.telia.net)
+ (62.115.140.253:las-b3-link.telia.net) >> (213.248.98.238:b
harti-ic-140621-las-b3.c.telia.net)
+ (62.115.140.255:las-b3-link.telia.net) >> (213.248.98.238:b
harti-ic-140621-las-b3.c.telia.net)

Given the way traceroute works (most of the times), which reports back the
ingress port of the router it hits, do you think it fair to assume that all
the hops that I see on the `From` hop are all different ports of one
router? I think the other explanation is that there is switch (or something
that does not have IP footprint) between `From` side and `To` side. How
probable do you think this second explanation is?

Best Regards
Reza Motamedi (R.M)


Re: Inferring the location points of traffic exchange between two networks

2016-01-13 Thread Reza Motamedi
Thanks Joel. I like examples. :)

So say I issue the command on a router that is not the gateway. Would I get
the following?

   Network Next Hop Metric  LocPref Weight  Path
 * >   8.8.8.0/24   96  56  0   
15169 i

With respect to "show bgp summary", if I know the location of the router
and the router shows the BGP neighbor in the output, can I just rely on
this info and say the point of exchange is where the router is located? For
example the following show output from a router in city say "X"

  BGP4 Summary
  Router ID: 192.65.184.1   Local AS Number: 513
  Confederation Identifier: not configured
  Confederation Peers:
  Cluster ID: 513
  Maximum Number of IP ECMP Paths Supported for Load Sharing: 4
  Number of Neighbors Configured: 18, UP: 18
  Number of Routes Installed: 997637, Uses 85796782 bytes
  Number of Routes Advertising to All Neighbors: 2196009 (569816
entries), Uses 27351168 bytes
  Number of Attribute Entries Installed: 305962, Uses 27536580 bytes
  Neighbor Address  AS# State   Time  Rt:Accepted
Filtered Sent ToSend
  62.40.124.157 20965   ESTAB   76d23h58m 140497  0
28   0
  83.97.88.33   21320   ESTAB   49d 5h11m 0   0
28   0
  192.65.184.2  513 ESTAB   365d12h24m243346  0
493626   0
  192.65.184.3  513 ESTAB   405d12h31m70100
562695   0
  192.65.184.4  513 ESTAB   317d 9h 1m0   0
569704   0
  192.65.184.24 513 ESTAB   54d16h26m 0   0
569704   0

  tells me that 513 is peering with 20965 that city, right?

Best Regards
Reza Motamedi (R.M)
Graduate Research Fellow
Oregon Network Research Group
Computer and Information Science
University of Oregon

On Wed, Jan 13, 2016 at 10:02 AM, joel jaeggli <joe...@bogus.com> wrote:

> On 1/13/16 9:36 AM, Reza Motamedi wrote:
> > Hi NANOG,
> >
> > I am researcher at the University of Oregon and my question is rather
> > primitive. My research background is in networked systems and Internet
> > measurement so I know how things work in theory.
> >
> > My question is about BGP and what can be inferred from the output of
> > different "show" commands, regarding the point of traffic exchange of two
> > networks with different ASNs. I tried going through the some samples on
> > Juniper and Cisco documentations but I did not get my answer.
> >
> > Consider the following scenario; Say the point of traffic exchange
> between
> > AS_a and AS_b is in San Francisco and we run "show bgp summary"
>
> show bgp summary just tells you about your bgp neighbors.
>
> > and "show
> > ip bgp "on a BGP router of AS_a in LA. Do we see the peering
> > between AS_a and AS_b in San Francisco using any of the two commands.
>
> You see AS path, and the nexthop the route was learned from (which is
> probably (nexthop self) the router on which the prefix is learned) in
> san francisco. that route is probably resolved by your igp.
>
> so in an extremely simple example
>
>Network Next Hop Metric  LocPref Weight Path
>  * >   8.8.8.0/24  72.14.202.50 96  56  0   15169
> i
>
> the nexthop happens to be an attached google peer
>
> the as path is
> 15169 i
>
> > If
> > yes is there a way to infer that in fact the traffic is not exchanged
> > locally in LA? I think there should be a flag to differentiate records
> > showing iBGP vs eBGP.
>
> If the router in LA sees the path as being through a router in san
> francisco that is the direction it will forward it in.
>
> > On the same note, if we issue the commands on a router other than the
> > border router in San Fran, is there any difference in the output of show
> > commands?
> >
> > Now how are things different if we actually run the commands on that
> > gateway router in SF?
> >
> > Best Regards
> > Reza Motamedi (R.M)
> > Graduate Research Fellow
> > Oregon Network Research Group
> > Computer and Information Science
> > University of Oregon
> >
>
>
>


Inferring the location points of traffic exchange between two networks

2016-01-13 Thread Reza Motamedi
Hi NANOG,

I am researcher at the University of Oregon and my question is rather
primitive. My research background is in networked systems and Internet
measurement so I know how things work in theory.

My question is about BGP and what can be inferred from the output of
different "show" commands, regarding the point of traffic exchange of two
networks with different ASNs. I tried going through the some samples on
Juniper and Cisco documentations but I did not get my answer.

Consider the following scenario; Say the point of traffic exchange between
AS_a and AS_b is in San Francisco and we run "show bgp summary" and "show
ip bgp "on a BGP router of AS_a in LA. Do we see the peering
between AS_a and AS_b in San Francisco using any of the two commands. If
yes is there a way to infer that in fact the traffic is not exchanged
locally in LA? I think there should be a flag to differentiate records
showing iBGP vs eBGP.

On the same note, if we issue the commands on a router other than the
border router in San Fran, is there any difference in the output of show
commands?

Now how are things different if we actually run the commands on that
gateway router in SF?

Best Regards
Reza Motamedi (R.M)
Graduate Research Fellow
Oregon Network Research Group
Computer and Information Science
University of Oregon


Re: interconnection costs

2015-12-23 Thread Reza Motamedi
Thanks James,

I totally missed that section. Sorry about that. I think the picture is
becoming more clear in my head now.

Let me first make sure my terminology is right.
- With respect to peering, there are "transit" in which you pay the other
AS in 95-5 fashion or whatever, and "settlement-free" in which two ASes
agree not to charge each other for traffic exchange. In the latter, the
exchanged traffic is limited to the customer cone of the two ASes.
- Peering can happen either "publicly" though an IXP or "privately" through
directly linking the ports of two routers and exchanging BGP traffic.

Now, if I understood correctly, the difference between the cost of public
and private peering is that in public, one AS pays to be connected to the
IXP fabric, perhaps to the IXP provider and the colo provider. I'm assuming
IXP and colo provider are not always the same organization as it is the
case in SIX (Seattle IXP) and colo providers in Westin Building including
Equinix, ZAYO, etc. So the AS is being charged for becoming an IXP member,
and also to be allowed to take a line from its rack to the IXP's "meet me
room". Additionally if one decides to buy transit over the IXP it has to
pay the transit providers.
In Private peering however the AS pays the colo provider for the xconnect
per ASes that it wants to peer with. The cost of transit would be
additional if the peering is in fact a transit and not settlement free.

All the costs of HW, SW, personnel, administration, and perhaps
transmission between colos (including remote peering, being waved to
another location, tethering) would be the same, right?

Best Regards
Reza Motamedi (R.M)
Graduate Research Fellow
Oregon Network Research Group
Computer and Information Science
University of Oregon

On Wed, Dec 23, 2015 at 9:07 AM, James Bensley <jwbens...@gmail.com> wrote:

> On 22 December 2015 at 19:11, Reza Motamedi <motam...@cs.uoregon.edu>
> wrote:
> > Thanks guys for the replies.
> >
> > I wanted to clarify two things in my questions. First by peering I did
> not
> > necessarily mean "settlement free" interconnection. I meant any inter-AS
> > connection. My understanding is that in addition to the cost of transit
> that
> > should be paid to the transit provider, there also exists the cost of the
> > xconnect that is charged by the colocation provider. Secondly, my
> question
> > was more about the expenses, as opposed to the technical costs/benefits.
> I
> > have browsed through the "Peering Playbook", but I think its more about
> > providing a case "settlement free" peering.
>
> Dude, how are you going to weigh up the costs and benefits of peering
> if you don't include the "costs". I refer you back to the same
> documented I referred you to yesterday...
>
> > On Tue, Dec 22, 2015 at 9:33 AM, James Bensley <jwbens...@gmail.com>
> wrote:
> >>
> https://docs.google.com/document/d/1i2bPZDt75hAwcR4iKMqaNSGIeM-nJSWLZ6SLTTnuXNs/edit?pref=2=1#
>
>
> This time look at section 4 of this huge and hard to navigate
> document, "4. Peering Costs":
>
>
> https://docs.google.com/document/d/1i2bPZDt75hAwcR4iKMqaNSGIeM-nJSWLZ6SLTTnuXNs/edit#heading=h.nqqauszv8vj
>
>
> Loosely extrapolating:
>
> Network transport: You need to be physically connected unless you
> blagged space in the same rack and can patch in for free.
>
> Hardware: You need tin to route packets.
>
> Software: You need software to monitor the packet routing.
>
> Colocation: You need space/power/cooler/security in which the tin can
> operate.
>
> Staffing costs: Someone has to configure that tin.
>
> Admin/engineering overhead: Someone has to manage the peering process
>
> Peering port: You probably have to pay to peer.
>
> Reseller ports: You might need remote connectivity to the LAN and
> "network transport" above would refer to a cross connect to the remote
> peering provider instead of directly into the IXP LAN.
>
>
>
> James.
>
>


Re: interconnection costs

2015-12-23 Thread Reza Motamedi
Aren't availability, guaranteed service and remote hands an incentive to do
peering inside a third party colocation?

I see very large numbers for xconnects for instance in Equnix [
https://blog.equinix.com/2013/08/equinix-cross-connects-hit-11/] and it
made me believe buying xconnect is still a normal practice.

Best Regards
Reza Motamedi (R.M)
Graduate Research Fellow
Oregon Network Research Group
Computer and Information Science
University of Oregon

On Wed, Dec 23, 2015 at 2:12 PM, Baldur Norddahl <baldur.nordd...@gmail.com>
wrote:

>
>
> On 23 December 2015 at 20:05, Reza Motamedi <motam...@cs.uoregon.edu>
> wrote:
>
>> In Private peering however the AS pays the colo provider for the xconnect
>> per ASes that it wants to peer with. The cost of transit would be
>> additional if the peering is in fact a transit and not settlement free.
>>
>
> You are still assuming there is a colo. But perhaps the most common case
> is a multihomed company buying transit from two independent service
> providers. The customer is at his office and the two service providers will
> have their end somewhere in the city, perhaps even terminating their end of
> the circuit in a street cabinet. The customer is multihomed and therefore
> has his own AS. This is a peering situation with three AS numbers that fits
> your description, it is private peering and there is no xconnect. Instead
> there is usually a leased line cost, but this cost is often hidden from the
> customer. Also the ISP might own the line (physical fiber) and the cost is
> not a simple $/month.
>
> But also two ISPs might peer in this way. Residual internet providers have
> a ton of points of presences, so why choose a place where there is a
> xconnect fee? We can peer anywhere in the city, including at a random
> street cabinet. Often the cost of renting a dark fiber somewhere is lower
> than a xconnect fee (a sign that datacenter owners are too greedy).
>
> If one party is a content provider I give you that the peering point is
> usually at a datacenter somewhere. But still, if the content provider is
> big enough to run their own datacenter, we are back at the leased line case
> again. Some content providers, even if small, prefer to just run their own
> datacenter in the basement of their offices.
>
> Regards,
>
> Baldur
>
>


Re: interconnection costs

2015-12-22 Thread Reza Motamedi
Thanks guys for the replies.

I wanted to clarify two things in my questions. First by peering I did not
necessarily mean "settlement free" interconnection. I meant any inter-AS
connection. My understanding is that in addition to the cost of transit
that should be paid to the transit provider, there also exists the cost of
the xconnect that is charged by the colocation provider. Secondly, my
question was more about the expenses, as opposed to the technical
costs/benefits. I have browsed through the "Peering Playbook", but I think
its more about providing a case "settlement free" peering.

Best Regards
Reza Motamedi (R.M)
Graduate Research Fellow
Oregon Network Research Group
Computer and Information Science
University of Oregon

On Tue, Dec 22, 2015 at 9:33 AM, James Bensley <jwbens...@gmail.com> wrote:

> On 22 December 2015 at 16:44, Reza Motamedi <motam...@cs.uoregon.edu>
> wrote:
> > I think there is no single answer as different businesses may have
> > different pricing models. I hope the discussion can help me understand
> the
> > whole ecosystem a little bit better.
>
>
> Hi Reza,
>
> I have a list of example items that need to be costed in below, it is
> by no means a definitive list though:
>
>
> https://docs.google.com/document/d/1i2bPZDt75hAwcR4iKMqaNSGIeM-nJSWLZ6SLTTnuXNs/edit?pref=2=1#
>
>
> Cheers,
> James.
>
>


interconnection costs

2015-12-22 Thread Reza Motamedi
Hi NANOG

We are a group of researchers and our focus is on the economy of
interconnection in the Internet. My question is mainly about the various
costs of an AS establishing a connection with another AS, including the
costs charged by the colocation providers. I am familiar with most of the
connection options such as public peering on IXP, and private peering
through xconnects. My understanding is that in addition to the cost of
transit that the smaller AS pays to the larger AS, in the former you pay a
monthly fee to establish a link to the switching fabric and then you can
connect to as many ASes that are member in the IXP, and in the later you
need to pay for as many xconnects that you need to connect to as many ASes
that you plan to peer with. Obviously in both cases there is the cost of
being in the colocation and renting a rack or whatever. What are the other
costs involved? How should the AS reach the colocation center in the first
place? I don't think every network can dig a hole an lay cables. Who should
they pay to get from one PoP to another? Do ASes have to pay for xconnect
to connect their PoP in a data center to the rest of their network?

I think there is no single answer as different businesses may have
different pricing models. I hope the discussion can help me understand the
whole ecosystem a little bit better.


Best Regards
Reza Motamedi (R.M)
Graduate Research Fellow
Oregon Network Research Group
Computer and Information Science
University of Oregon


Re: distinguishing eBGP from show ip BGP

2015-03-11 Thread Reza Motamedi
Thanks again, Mark.

So I guess the short answer is that I can't infer anything about the
location of physical connectivity having this level of information from the
control plane. Is that a fair statement? What if the Next Hop is inside
the neighbor AS. I know it is a rather odd and uncommon case, but can it
help?

Best Regards
Reza Motamedi (R.M)
Graduate Research Fellow
Oregon Network Research Group
Computer and Information Science
University of Oregon

On Wed, Mar 11, 2015 at 3:50 PM, Mark Tinka mark.ti...@seacom.mu wrote:



 On 11/Mar/15 21:42, Reza Motamedi wrote:

 What I ultimately want to determine, is the location of the AS connection.
 I know for example the router is in, say LA. If hot potato lets me to send
 the packet to the neighbor AS then they have an AS connection in LA, right?

  Going back to my example does the fact that the entry does not have 'i'
 mean that I can send it to AS2828 on the next hop.


 Yes - the route was not learned via iBGP; which means it was learned via
 eBGP.

 But that is just routing. It does not necessarily paint the forwarding
 topology (remember, routing and forwarding are two different operations).

 The next-hop may be local to this router, but it could also be a tunnel
 (which may be cold-potato forwarded before exiting the local AS), or the
 eBGP session could be eBGP Multi-Hop.

 Mark.



Re: distinguishing eBGP from show ip BGP

2015-03-11 Thread Reza Motamedi
What I ultimately want to determine, is the location of the AS connection.
I know for example the router is in, say LA. If hot potato lets me to send
the packet to the neighbor AS then they have an AS connection in LA, right?

Going back to my example does the fact that the entry does not have 'i'
mean that I can send it to AS2828 on the next hop.

Network  Next HopMetric LocPrf Weight Path
 *  207.108.0.0/15   216.156.2.1643 0 2828 209 i
 *   65.106.7.101 2 0 2828 209 i
 *   65.106.7.246 3 0 2828 209 i
 *   65.106.7.55  3 0 2828 209 i
 *  216.156.2.1622 0 2828 209 i

Best Regards
Reza Motamedi (R.M)
Graduate Research Fellow
Oregon Network Research Group
Computer and Information Science
University of Oregon

On Wed, Mar 11, 2015 at 3:30 PM, Mark Tinka mark.ti...@seacom.mu wrote:



 On 11/Mar/15 21:22, Reza Motamedi wrote:

 Thanks Mark for the reply. Let me try to check what I understood is
 correct. Does the 'i' on the left (status code) only shows whether the
 prefix belongs to this AS?


 Status-code i just means the entry was learned by this router via
 iBGP. It does not mean the entry belongs to this AS.

 A locally-generated route can be thought of as belonging to this AS,
 however, a router cannot assert that a locally-generated route belongs to
 this AS. It just asserts that the route was locally-generated within the
 AS. Ownership of the route is data that needs to be gleaned from other
 sources, e.g., RIR WHOIS data, speaking to the operator, e.t.c.

 Whatever the case, a locally-generated route would not have an AS_PATH.
 That is an easy way to tell for such a use-case.

  What I want to figure out is if this two ASes (the owner of the router
 and and the first one on the AS-PATH) connect at the location of the
 router, or if packets need to stay for some hops in the local AS.


 So you want to determine whether traffic is hot- or cold-potato forwarding
 from the point of view of your reference router?

 Mark.



Re: distinguishing eBGP from show ip BGP

2015-03-11 Thread Reza Motamedi
Thanks Mark for the reply. Let me try to check what I understood is
correct. Does the 'i' on the left (status code) only shows whether the
prefix belongs to this AS?

What I want to figure out is if this two ASes (the owner of the router and
and the first one on the AS-PATH) connect at the location of the router, or
if packets need to stay for some hops in the local AS.

On Wed, Mar 11, 2015, 2:51 PM Mark Tinka mark.ti...@seacom.mu wrote:



 On 11/Mar/15 20:32, Reza Motamedi wrote:
  Hi Nanog,
 
  For a research I want to distinguish the external AS peering from show
 ip
  BGP. In other words I want to see which entry show a path that
 immediately
  sends packets to another AS. My understanding is that *status code* shows
  if the route is internal, right? Does this mean if the *'i' *is not
  present, the route is goes out of the AS in the next hop. On the same
 note,
  can I use Next Hop to identify such entries?
 
  I just included a sample report from a public looking glass in XO.
 
 
show ip bgp  207.108.0.0/15 longer-prefixes
BGP table version is 529230540, local router ID is 65.106.7.145
* * *Status codes: s suppressed, d damped, h history, * valid,  best,
 i -
  internal,
  r RIB-failure, S Stale, m multipath, b backup-path, x
  best-external, f RT-Filter, a additional-path
Origin codes: i - IGP, e - EGP, ? - incomplete
 
   Network  Next HopMetric LocPrf Weight Path
*  207.108.0.0/15   216.156.2.1643 0 2828 209
 i
*   65.106.7.101 2 0 2828 209 i
*   65.106.7.246 3 0 2828 209 i
*   65.106.7.55  3 0 2828 209 i
*  216.156.2.1622 0 2828 209 i
*   65.106.7.54  3 0 2828 209 i
*   65.106.7.252 2 0 2828 209 i
*   216.156.2.1602 0 2828 209 i
*   65.106.7.56  3 0 2828 209 i
*   216.156.2.1652 0 2828 209 i
*   65.106.7.144 2 0 2828 209 i

 There are two uses of the i code in IOS:

  1. i for Status codes refers to the route being learned via iBGP.
  2. i for Origin codes refers to the route being learned via a
 locally-generated route at the origin (or more historically, the IGP).

 In IOS show ip bgp output, the i for Status code (iBGP) is to the
 left of the prefix. On the other hand, the i for Origin code
 (IGP-originated route) is to the right of the originating AS in the
 AS_PATH.

 So you need to be more interested in the i to the left of the prefix.
 In your output above, no such i exists; ergo, these are eBGP-learned
 routes from this router's point of view.

 Use of the NEXT_HOP attribute to identify whether a route is
 eBGP-learned is not reliable, especially if you do not own the network
 you're getting your data from.

 Mark.




distinguishing eBGP from show ip BGP

2015-03-11 Thread Reza Motamedi
Hi Nanog,

For a research I want to distinguish the external AS peering from show ip
BGP. In other words I want to see which entry show a path that immediately
sends packets to another AS. My understanding is that *status code* shows
if the route is internal, right? Does this mean if the *'i' *is not
present, the route is goes out of the AS in the next hop. On the same note,
can I use Next Hop to identify such entries?

I just included a sample report from a public looking glass in XO.


 show ip bgp  207.108.0.0/15 longer-prefixes
 BGP table version is 529230540, local router ID is 65.106.7.145
 * * *Status codes: s suppressed, d damped, h history, * valid,  best, i -
internal,
   r RIB-failure, S Stale, m multipath, b backup-path, x
best-external, f RT-Filter, a additional-path
 Origin codes: i - IGP, e - EGP, ? - incomplete

Network  Next HopMetric LocPrf Weight Path
 *  207.108.0.0/15   216.156.2.1643 0 2828 209 i
 *   65.106.7.101 2 0 2828 209 i
 *   65.106.7.246 3 0 2828 209 i
 *   65.106.7.55  3 0 2828 209 i
 *  216.156.2.1622 0 2828 209 i
 *   65.106.7.54  3 0 2828 209 i
 *   65.106.7.252 2 0 2828 209 i
 *   216.156.2.1602 0 2828 209 i
 *   65.106.7.56  3 0 2828 209 i
 *   216.156.2.1652 0 2828 209 i
 *   65.106.7.144 2 0 2828 209 i

Best Regards
Reza Motamedi (R.M)
Graduate Research Fellow
Oregon Network Research Group
Computer and Information Science
University of Oregon


What can I infer from show ip route and similar BGP commands?

2014-12-08 Thread Reza Motamedi
Hello NANOG,

I’m a researcher and I was trying to understand the data I collected from
some BGP Looking Glasses. Basically, I was hoping to see if BGP records can
tell me where my university’s provider (AS3701) is peering with its
providers. I issued two BGP queries to Level3’s LGs, one in Seattle and one
in Amsterdam for my school’s prefix. My strong guess was that our provider
(AS3701) peers with Level3 in Seattle. I was hoping to conclude something
like this: if the peering occurs in Seattle, the Seattle LG should reveal
it, but Amsterdam should not.

AS3701 is Nero (Network for Education and Research in Oregon) which I
assume is a small regional AS. I don't think Nero peers with Level3 in
Amsterdam, however, I get this AS for my next hop even when I issue the
command from Amsterdam. On the other hand “car1.Sacramento1” suggests that
the peering happens in Sacramento.

This result makes me think what I get is from a combination of iBGP and
eBGP, which is also apparent from “Internal/External” keywords in the data.
My main issue is that the keywords are not always available. In some other
LG I just get a next hop IP and an AS path. How can I make sure that the
peering information comes from an eBGP peering? I think the next hop IP
might be the answer, right?

I included the results of the command for both LGs here, hopefully somebody
could explain to me

-

Route results for 128.223.0.0/16 from Amsterdam, Netherlands

BGP routing table entry for 128.223.0.0/16

Paths: (2 available, best #1)

 3701 3582

 AS-path translation: { OREGONUNIV UONET }

car1.Sacramento1 (metric 58341)

  Origin IGP, metric 0, localpref 100, valid, internal, best

  Community: North_America  Lclprf_100 Level3_Customer United_States
Sacramento

  Originator: car1.Sacramento1

 3701 3582

 AS-path translation: { OREGONUNIV UONET }

car1.Sacramento1 (metric 58341)

  Origin IGP, metric 0, localpref 100, valid, internal

  Community: North_America  Lclprf_100 Level3_Customer United_States
Sacramento

 Originator: car1.Sacramento1

-

Route results for 128.223.6.81/16 from Seattle, WA

BGP routing table entry for 128.223.0.0/16

Paths: (4 available, best #3)

 3701 3582

 AS-path translation: { OREGONUNIV UONET }

4.53.150.46 from 4.53.150.46 (ptck-core1-gw.nero.net)

  Origin IGP, localpref 90, valid, external

  Community: North_America  Lclprf_90 Level3_Customer United_States Seattle
Level3:11847

 3701 3582, (received-only)

 AS-path translation: { OREGONUNIV UONET }

4.53.150.46 from 4.53.150.46 (ptck-core1-gw.nero.net)

  Origin IGP, localpref 100, valid, external

  Community: Level3:90

 3701 3582

 AS-path translation: { OREGONUNIV UONET }

car1.Sacramento1 (metric 34363)

  Origin IGP, metric 0, localpref 100, valid, internal, best

  Community: North_America  Lclprf_100 Level3_Customer United_States
Sacramento

  Originator: car1.Sacramento1

 3701 3582

 AS-path translation: { OREGONUNIV UONET }

car1.Sacramento1 (metric 34363)

  Origin IGP, metric 0, localpref 100, valid, internal

  Community: North_America  Lclprf_100 Level3_Customer United_States
Sacramento

  Originator: car1.Sacramento1


Best Regards
Reza Motamedi (R.M)
Graduate Research Fellow
Computer and Information Science
University of Oregon


Re: What can I infer from show ip route and similar BGP commands?

2014-12-08 Thread Reza Motamedi
Thanks Joel for your detailed explanation. It was very informative. I have
been using routeviews for sometime, but given that I could get this amount
of information from other sources, I decided to give this a try.

On another note, do you think there is any value in checking the next hop
IP? I have been checking and it looks as if when the IP is in the AS at the
head of the AS path, the entry is associated with an iBGP record, right? I
just used the ripe stat to map IPs to AS and it always holds when there is
an AS for the next hop IP.

Thanks again for your input.