Subject: [Idr] BGP autodiscovery draft

From: Jon Mitchell <[email-masked]>
Date: Thu, 14 Aug 2014 09:52:34 -0400

All -

Interested in feedback on the merge of a couple of previous ideas into
the below BGP auto(peer) discovery draft.  The idea is applicable in a
number of scenarios where there is a "bootstrap" peer from which
further peering session information could be learned.

Thanks in advance,

Jon and the other authors

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Monday, August 11, 2014 8:58 AM
To: Jon Mitchell (GNS); Robert Raszuk; Warren Kumari; John Scudder;
Warren Kumari; Keyur Patel; Keyur Patel; Robert Raszuk; Jon Mitchell
(GNS); John Scudder
Subject: New Version Notification for
draft-raszuk-idr-bgp-auto-discovery-01.txt

A new version of I-D, draft-raszuk-idr-bgp-auto-discovery-01.txt
has been successfully submitted by Warren Kumari and posted to the
IETF repository.

Name:		draft-raszuk-idr-bgp-auto-discovery
Revision:	01
Title:		BGP Auto Discovery
Document date:	2014-08-11
Group:		Individual Submission
Pages:		13
URL:
http://www.ietf.org/internet-drafts/draft-raszuk-idr-bgp-auto-discovery-01.txt
Status:
https://datatracker.ietf.org/doc/draft-raszuk-idr-bgp-auto-discovery/
Htmlized:
http://tools.ietf.org/html/draft-raszuk-idr-bgp-auto-discovery-01
Diff:
http://www.ietf.org/rfcdiff?url2=draft-raszuk-idr-bgp-auto-discovery-01

Abstract:
   This document describes a method for automating portions of a
   router's BGP configuration via discovery of BGP peers with which to
   establish further sessions from an initial "bootstrap" router.
This
   method can apply for establishment of either Internal or External
BGP
   peering sessions.

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: "UTTARO, JAMES" <[email-masked]>
Date: Thu, 14 Aug 2014 19:52:36 +0000

Jon,

	What do you envision as the field of use of this work? Is it primarily directed to DC using BGP or do you believe that it has a wider application? It would be helpful to add this reqs/FOU info to the doc..

Jim Uttaro

-----Original Message-----
From: Idr [mailto:[email-masked]] On Behalf Of Jon Mitchell
Sent: Thursday, August 14, 2014 9:53 AM
To: [email-masked]
Subject: [Idr] BGP autodiscovery draft

All -

Thanks in advance,

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: Monday, August 11, 2014 8:58 AM
To: Jon Mitchell (GNS); Robert Raszuk; Warren Kumari; John Scudder;

Abstract:

The IETF Secretariat

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

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 14 Aug 2014 22:04:27 +0200

Jim,

This work is hardly applicable to DC environment.

In DC IP Fabric you either peer with direct eBGP between network nodes
or peer with IBGP to RR. It does not make much sense to provide full
IBGP mesh between all P.

Full IBGP Mesh is useful between PE/ASBR nodes as well as between
ASBRs in the IX env.

Both use cases are already described in the draft see "Section 1 History"

Thx,
r.

---

From: Jon Mitchell <[email-masked]>
Date: Fri, 15 Aug 2014 17:27:01 -0400

Hesitant to say not DC applicable, generally I agree with Robert on
the main use cases and this does not seem the easiest solution for p2p
CloS sessions.  However, in various enterprise, DC, and SP networks
more and more monitoring and route injection peerings are prevalent
and advertising these endpoints is an interesting possibility as well
for this draft.

Cheers,

Jon

---

From: Jared Mauch <[email-masked]>
Date: Sat, 16 Aug 2014 09:42:19 -0400

Cisco has supported (for years) an ACL method of allowing new BGP peers without explicitly configuring them in advance. 

I can dig out pointers if that helps

Jared Mauch

> On Aug 14, 2014, at 3:52 PM, "UTTARO, JAMES" <[email-masked]> wrote:
> 
> Jon,
>

---

From: Łukasz Bromirski <[email-masked]>
Date: Sat, 16 Aug 2014 16:53:01 +0300

Not necessarily ACL (as far as I remember), but simply defined prefix, but yes it does and the feature is called BGP Dynamic Neighbors.

-- 
./

> On 16 Aug 2014, at 16:42, Jared Mauch <[email-masked]> wrote:
>

---

From: Robert Raszuk <[email-masked]>
Date: Sat, 16 Aug 2014 15:59:39 +0200

Jared,

What typu are describing has not much in common with the draft.

Likewise it will hardly help Jon in his use case too since he may have 10s
of controllers/reflectors each serving different application so he wants to
avoid touching by script each edge or compute node in order to keep adding
or deleting bgp sessions.

Best,
R.
On Aug 16, 2014 3:42 PM, "Jared Mauch" <[email-masked]> wrote:

> Cisco has supported (for years) an ACL method of allowing new BGP peers
> without explicitly configuring them in advance.
>
> >    What do you envision as the field of use of this work? Is it
> primarily directed to DC using BGP or do you believe that it has a wider
> application? It would be helpful to add this reqs/FOU info to the doc..
> >
> > Jim Uttaro
> >

---

From: Jeffrey Haas <[email-masked]>
Date: Mon, 18 Aug 2014 13:53:55 -0400

> further peering session information could be learned.

The route server (or router-introducer in this context) cases are definitely
the easiest to see, especially in the IXP environment.  I think the bigger
challenge outside of that environment is envisioning the use case.  

If I've gone to the hassle of configuring enough of a peering session with a
reflector just to learn what routers are in my network, what's the goal?  Is
it to have a dynamically generated peering mesh configured?  How will that
vary from the reflector I'm talking to?  Etc.

Also, what are the considerations around authentication of the routers?  If
you require pair-wise session keys, is the auto discovery mechanism meant to
bootstrap that as well?

-- Jeff

---

From: Robert Raszuk <[email-masked]>
Date: Mon, 18 Aug 2014 20:47:10 +0200

Hi Jeff,

To your first point RR will not carry any other AFI/SAFI other then
discovery so if you ink about the gain it is immediately in $$$ to avoid
building say BGP-LS RR clusters.

To your second point reg authenitcation the story is this ..

In my+Pedro's original idea we limited it to IBGP for a purpose .. To
locally distribute the keys like you configure any other bgp paramters or
to just use prefix acl (like Lukasz mentioned) for dynamic mesh.

For IX or EBGP at this stage we did not roll any new authentication
distribution in this draft as problem is either trivial you distribute it
by email or much more complex in general and requires a separate work.
Which is btw very welcome ;)

Best,
R.

On Monday, August 18, 2014, Jeffrey Haas <[email-masked]> wrote:

> [email-masked] <javascript:;>

---

From: "UTTARO, JAMES" <[email-masked]>
Date: Mon, 18 Aug 2014 20:54:00 +0000

Jon,

	I thought the use case would relate to the fact that a certain subset of nodes ( Leafs ) are intended as BGP speakers in the CLOS topo.. If these could be identified then they could establish sessions with each other or a designated RR. As the topo is small a case could be made that peering is not concerned with regions, exit points... In this manner you would not have to configure each individually. How would this draft be used to designate a certain subset of nodes should be automatically peered together and not others. As an ex.  It may be desirable to create regional peering design in a VPN network and then use that in conjunction with policy to identify certain inter-provider exit points ( VPN Network ). Has a network whereby 3107 is used to create the IGP underlay been considered?

Jim Uttaro

-----Original Message-----
From: Jon Mitchell [mailto:[email-masked]] 
Sent: Friday, August 15, 2014 5:27 PM
To: Robert Raszuk
Cc: UTTARO, JAMES; [email-masked]
Subject: Re: [Idr] BGP autodiscovery draft

Cheers,

Jon

---

From: Jeffrey Haas <[email-masked]>
Date: Mon, 18 Aug 2014 17:17:30 -0400

Robert,

> building say BGP-LS RR clusters.

The draft does call out explicitly that you *could* lay this on top.  But
yes, this could be a very inexpensive bit of BGP software to serve for
bootstrapping.

> to just use prefix acl (like Lukasz mentioned) for dynamic mesh.

Understood.  Traditional promiscuous peering configuration tends to simply
be "if you are part of this prefix list, peering is allowed".  However, I
think the days where networks are comfortable with even internal
unauthenticated (although ACLed) sessions may be coming to an end.  I'd
suggest if such a feature as this is being offered, it should think about
authentication.

> Which is btw very welcome ;)

For ebgp, I don't believe this has much of a use case.

For IX, I'm out of touch as to whether authentication is in use at the
exchanges.

-- Jeff