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

From: David Freedman <[email-masked]>
Date: Wed, 11 Feb 2015 23:55:31 +0000

>it would be more sensible to define a new bgp attribute to allow RS
>clients
>to announce BFD candidacy to the RSN

+1

Actually, I was speaking recently to another author who planned to
resurrect it in another as yet unpublished draft
involving a new BGP attribute to signal next-hop liveliness detection
(hopefully this post will prompt them into action to mention it).

In this discussion, we determined that these duties could probably be
devolved directly to BFD itself, which could (if configured suitably) be
left to discover potential peers and set up sessions based on seeing them
as next hops in the incoming BGP RIBs learned from the IXP route server.
This seemed like a much better approach than leaving it to BGP and the RS
(which relieves some of the potential burden on it IMHO)

Dave.

---

From: Randy Bush <[email-masked]>
Date: Thu, 12 Feb 2015 10:32:15 +0700

we considered a more 'liberal' approach similar to one recommended
privately by job, where the peer discovers who to set up bfd with by
what next hops they get.  this has problems in that it assumes NH is
set, prefixes exist (A may announce nothing to B), etc.

we also considered full rigid signaling approaches such as you and
nick suggest.  this path is much firmer theoretical ground.  the problem
is that it will wait years or forever for vendors to implement.

so this draft represents a middle ground (yes, a sofa-bed is neither a
good sofa nor a good bed:-) which we hope can be easily hacked so we can
actually deploy and use it, but which provides some assurance that you
know your potential bfd peer set.

ymmv, of course.

randy

---

From: David Freedman <[email-masked]>
Date: Thu, 12 Feb 2015 06:23:17 +0000

>set, prefixes exist (A may announce nothing to B), etc.

Making this a function of BFD (and not BGP) makes sense here IMHO,
if there is no NH set, or no prefixes exist on day one then
I'm not going to need a BFD session in the first place.

>> which provides some assurance that you

Is't this the point of the RS, to facilitate in the face of the unknown?
with the above approach, assuming I filter against the RS, if I wanted to,
would I not still reach the same outcome?

Dave.

---

From: Randy Bush <[email-masked]>
Date: Thu, 12 Feb 2015 13:35:03 +0700

> I'm not going to need a BFD session in the first place.

while A may not announce anything to B, B may have gifts for A

>>> which provides some assurance that you know your potential bfd peer
>>> set.
> Is't this the point of the RS, to facilitate in the face of the
> unknown?  with the above approach, assuming I filter against the RS,
> if I wanted to, would I not still reach the same outcome?

i can not parse.

randy

---

From: David Freedman <[email-masked]>
Date: Thu, 12 Feb 2015 06:38:50 +0000

>while A may not announce anything to B, B may have gifts for A

That's fine, there is still a valid forwarding path here,
why would we not set up a (BFD) session?

>> if I wanted to, would I not still reach the same outcome?

I was just commenting on how I feel that this doesn't violate the RS model.

Assuming you filter properly (including asking the RS not to spread your
prefixes
to those you don't want it to), you shouldn't get any unsolicited BFD
setup requests. 

Dave.

---

From: Randy Bush <[email-masked]>
Date: Thu, 12 Feb 2015 13:49:20 +0700

> That's fine, there is still a valid forwarding path here, why would we
> not set up a (BFD) session?

you would.  the point is that B can not count on receiving a route to A
to tell B to set up bfd to A

> I was just commenting on how I feel that this doesn't violate the RS

cool.  the exercise started with arnold asking what would make me more
comfortable with RSs given that i like my data plane to be congruent
with my control plane.

> Assuming you filter properly (including asking the RS not to spread
> your prefixes to those you don't want it to), you shouldn't get any
> unsolicited BFD setup requests.

makes sense to me.  at bknix with the gang who are figuring out how to
tell members to use ixp-mangler to only configure a bird peering if both
parties agree.

randy

---

From: heasley <[email-masked]>
Date: Thu, 12 Feb 2015 07:55:05 +0000

> would I not still reach the same outcome?

great idea, but why use a RS at all?  are folks still on AGS or just
incapable of managing peering relationships?

---

From: Randy Bush <[email-masked]>
Date: Thu, 12 Feb 2015 15:10:23 +0700

> incapable of managing peering relationships?

think of it this way, some people use a gui to drive a large expensive
blob of code which configures their routers in a [semi-]automated way.

others do not wish to develop and/or maintain that lorge blob of code.
perhaps they don't have a large enough network to amortize the effort.
so they use a web site (ixp-manager) to configure an ixp-provided route
server.

my problem with the second case is that the control plane and data plane
are not congruent (think datakit, atm, ...).  the draft is suggesting a
hack to ameliorate my objection.

randy

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 12 Feb 2015 09:37:57 +0100

> incapable of managing peering relationships?

​If you have 500 peerings and 1 joins or leaves it is a bit of a hassle ​to
go around and adjust peering relationship.

That's why we have a draft which solves this problem by automating
auto-discovery allowing for full control and data plane congruence.

RS in this case is just a peering database and is not used for any real
reachability routes exchange.

https://tools.ietf.org/html/draft-raszuk-idr-bgp-auto-discovery-02

Perhaps it is time to continue that draft ...

Thx,
R.

---

From: heasley <[email-masked]>
Date: Thu, 12 Feb 2015 19:31:13 +0000

> hack to ameliorate my objection.

i understand your objection and solution, and agree that its more palatable
than a broken forwarding plane.  But, i still think this is all a bunch of
kinky stuff to solve a problem that isnt all that difficult to handle if
the RS doesnt exist.  ie: its just configuration, which is not difficult.
the automation of configuration can be handled separately and w/o the RS
or protocol changes; eg: the IXP could instead provide a webservice to
disseminate peer presence and supply a tool that participants run on their
management host to retrieve and netconf that to the devices.  the unix
approach - simple tools used together.

---

From: Nick Hilliard <[email-masked]>
Date: Thu, 12 Feb 2015 20:41:34 +0000

On 12/02/2015 19:31, heasley wrote:
> the RS doesnt exist.

Route servers are not to everyone's taste and no-one will force you to use
them if you don't want to.

Could we get back to the main point of the draft, which is to formalise the
change in BGP behaviour which people have been using since the 1990s to
implement RSs?

Nick

---

From: Randy Bush <[email-masked]>
Date: Fri, 13 Feb 2015 06:18:30 +0700

[ remember, i support publication ]

>> i understand your objection and solution, and agree that its more
>> palatable than a broken forwarding plane.  But, i still think this is
>> all a bunch of kinky stuff to solve a problem that isnt all that
>> difficult to handle if the RS doesnt exist.
> 
> Route servers are not to everyone's taste and no-one will force you to
> use them if you don't want to.
> 
> Could we get back to the main point of the draft, which is to
> formalise the change in BGP behaviour which people have been using
> since the 1990s to implement RSs?

heas has a lerge network with hundreds of routers.  he can amortize the
tool maintenance to automate peering configuration at the per-router
level.  for many folk, that is out of the question.  route servers
address the latter.  they're a valid use case.

what i don't get is, once you've thrown in add-path and diverse path,
why it left out flowspec, neighbor discovery, and dhcp options.  this
could have been simpler; multi-rib is the direct solution.

randy

---

From: Robert Raszuk <[email-masked]>
Date: Fri, 13 Feb 2015 00:29:08 +0100

Randy,

Flowspec is supported as any other AFI/SAFI by configuration. It is not
left out.

Note that flowspec is a data plane thingy and RS is there not to filter
data plane, but just pass control plane across transparently so it does not
need to be spelled out in this spec.

With path hiding it is different as RS needs to do something to mitigate it
hence add-paths or divers-paths are mentioned explicitely.

Thx,
r.

On Fri, Feb 13, 2015 at 12:18 AM, Randy Bush <[email-masked]> wrote:

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

---

From: Randy Bush <[email-masked]>
Date: Fri, 13 Feb 2015 06:32:03 +0700

> Flowspec is supported as any other AFI/SAFI by configuration. It is not

that was sarcasm

google carpenter gothic

randy

---

From: Robert Raszuk <[email-masked]>
Date: Fri, 13 Feb 2015 00:38:57 +0100

Ahhh apparently I did not get it at first look .. I was sufficiently
shocked that you care about flowspec that I could not resist to respond :))

Anyhow many thx for your support for this draft !

When you came to the mic in Berlin after I presented it I was not sure if I
should run ...

Best,
Robert.

---

From: Randy Bush <[email-masked]>
Date: Fri, 13 Feb 2015 07:12:05 +0700

i come from heas's world.  in fact, he is riding on the descendant of my
20 year old code.

but, with another hat, i am helping to engineer the new (inagurated this
week) bangkok neutral ix.  and it has an rs pair and ixp-manager.  this
is what folk want and expect, especially smaller folk.  it's not as simple
as i would like.  it is not easy to explain.  but it is useful.  and no,
we're not translating flowspec into thai. :)

randy

---

From: Nick Hilliard <[email-masked]>
Date: Fri, 13 Feb 2015 17:13:50 +0000

> could have been simpler; multi-rib is the direct solution.

tempting through it was to throw in everything including the kitchen sink,
we drew the limit at protocols which would actually make a difference to
dealing with the path hiding problem.  But if you want to suggest some text
to include flowspec, dhcpv6 prefix selection over bgp, ND via avian carrier
or anything else, the authors will promise to treat it appropriately and
not think the less of you for it :-)

Nick

---

From: "Neil J. McRae" <[email-masked]>
Date: Sat, 14 Feb 2015 17:00:14 +0000

randy
I'm in trouble! I am taking the maximum dosage after your flowspec comment earlier only to now read you are working on a neutral and community ran internet exchange point! I dare not read any more incase I see that you've deployed MPLS as I'll have to be carried out on a stretcher! ;)

Back on topic I think the changes have been proposed before and frankly are well overdue - use case for route servers is clear - even if you can get some orchestration/config vending solution getting the same solution rolled out to 40 plus IX points, sadly, is very unlikely. I am no fan of route servers but they are a needed evil.

Neil

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

---

From: Randy Bush <[email-masked]>
Date: Sun, 15 Feb 2015 02:26:37 +0900

tl;dr: read last para

> I'm in trouble! I am taking the maximum dosage after your flowspec
> comment earlier only to now read you are working on a neutral and
> community ran internet exchange point!

my first such was in the early '90s.  i just don't kiss and tell.

> I dare not read any more incase I see that you've deployed MPLS as
> I'll have to be carried out on a stretcher! ;)

we prostitutes have our limits

> Back on topic I think the changes have been proposed before and
> frankly are well overdue - use case for route servers is clear - even
> if you can get some orchestration/config vending solution getting the
> same solution rolled out to 40 plus IX points, sadly, is very
> unlikely. I am no fan of route servers but they are a needed evil.

the other decade, i spent some time and energy trying to get peers at an
exchange i helped build to do bgp autoconfig from shared data.  it was
too complex for the smaller ones.  i have been the poster child for irr
based configs for over 20 years.  it has not gone well.

route servers with front ends such as ixp-mangler seem to have enough
web gooey that folk can use them.  the problem is that non-congruence of
the data and control planes has consequences which have repeatedly
bitten us, from datakit, atm, ...  so i have ranted aginst them for some
time.  arnold asked what might make me able less uncomfortable with
them.  draft-ymbk-idr-rs-bfd-00.txt attempts to answer that.

but this is probably the wrong venue for an ops discussion.  this is
where we see how many bgp tricks we can add to a simple idea to make it
comfortably complex and fill out the contributors' list.

so again, i think draft-ietf-idr-ix-bgp-route-server is good to go,
unless the authors have the guts to cut 2.3.2.2, Advertising Multiple
Paths.  and i think draft-ymbk-idr-rs-bfd-00.txt might even make it
palatable to me.

randy

---

From: "Neil J. McRae" <[email-masked]>
Date: Sat, 14 Feb 2015 17:56:34 +0000

> based configs for over 20 years.  it has not gone well.

unfortunately.

> Paths.  and i think draft-ymbk-idr-rs-bfd-00.txt might even make it

I agree.  I think it's good to go also and bfd makes a lot of sense as a solution given its already there. 

I note now though my concerns on implementation of section 2; it's the necessary evil recurrence loop - it feels like a huge effort for limited return, but as a solution for those practising the route server necessary evil - it's acceptable and Nick is right in that we in ops live this life now.
I can't help feeling with more and more depth and diversity in exchange of traffic we will be back to redo this in the future.

---

From: Nick Hilliard <[email-masked]>
Date: Sat, 14 Feb 2015 18:41:08 +0000

On 14/02/2015 17:56, Neil J. McRae wrote:
> I can't help feeling with more and more depth and diversity in exchange
> of traffic we will be back to redo this in the future.

The ix-bgp-route-server ID is primarily about legitimising the BGP
behaviour necessary for route servers to be able to operate.

Regarding interconnection at IXPs, we're already doing groundwork on this:

https://github.com/euro-ix/json-schemas

We have running code to match.

Nick

---

From: [email-masked] (Niels Bakker)
Date: Sat, 14 Feb 2015 20:04:26 +0100

Randy,

>we're not translating flowspec into thai. :)

As somebody who connects to a rather large number of IXPs, thank you 
for choosing to implement IXP Manager and route servers, and as 
author, for supporting this draft.

Regards,

	-- Niels.

---

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

Sounds like it is time to find a big basher and get this author to 
finish his draft (under duress if it helps to get it out quickly :p).

Thomas