Subject: Re: [Lsvr] [Idr] Issue 2: Auto-configuration Requirements - draft-xu-idr-neighbor-autodiscovery-requirements

From: "Susan Hares" <[email-masked]>
Date: Mon, 10 Jun 2019 15:30:05 -0400

This is a list of requirements for autodiscovery from: 

draft-xu-idr-neighbor-autodiscovery requirements: 

---------------------------

4.  Requirements

   This section describe the requirements for the BGP hop-by-hop routing

   deployments that were considered for the definition of the BGP

   Neighbor Discovery extensions proposed in this document..

   Following are the key requirements related for the BGP neighbor

   discovery process:

   1.  It should perform discovery of directly connected BGP routers.

       Mechanism should support either IPv4 or IPv6 or a dual stack

       design and it should be generic for any link-layer.

   2.  It should include exchange of BGP peering addresses (IPv4 or IPv6

       or both) that routers can use to automatically setup BGP TCP

       peering between themselves.  The mechanism should leverage the

       existing capability negotiation process performed as part of the

       BGP TCP session establishment.

   3.  When BGP peering is desired to be performed over loopback

       addresses of the routers, then the mechanism should automatically

       setup reachability to the loopback over one or more underlying

       directly connected links between them.  In this scenario, the

       mechanism should also provide resolution for the BGP next-hop

       address (i.e. the loopback address) for the BGP routes exchanged

       over these sessions between the loopback addresses.

   4.  Mechanism should enable exchange of link-level information such

       as IP addresses and link attributes between the directly

       connected BGP routers.  It should be extensible to include other

       information in the future.

   5.  Mechanism should be limited to link scope for security and use

       link-local addressing only.  Cryptographic mechanisms should be

       also provided for additional security.

   6.  Mechanism should support capabilities for performing optional

       validation of parameters to detect misconfiguration (e.g. link

       address subnet mismatch, peering between incorrect AS, etc.) in

       an extensible manner before going on to use the link and the

       setup of the BGP TCP peering session over it.

   7.  The mechanism should not affect or change the BGP TCP session

       establishment procedures and the BGP routing exchange over the

       TCP session other than the interactions for triggering the setup/

       removal of peer session that is based on discovery mechanism.

   8.  The mechanism should leverage existing fast-detection techniques

       for failures that are used currently for EBGP sessions over

       directly connected links like fast-external-failover and BFD.

   9.  The mechanism should focus on the discovery process and exchange

       of status as a control plane procedure and be sufficiently

       loosely coupled with the base BGP operations to enable

       implementations to ensure scalability of BGP operations when

       using the discovery procedures.

From: Idr [mailto:[email-masked]] On Behalf Of Susan Hares
Sent: Monday, June 10, 2019 3:26 PM
To: [email-masked]
Cc: [email-masked]
Subject: [Idr] Issue 2: Auto-configuration Requirements

IDR WG: 

Does IDR think that we should include a generalized auto-discovery protocol
in the IDR WG charter? 

If so, should it be for WAN or Data Center or IPRAN topologies (grid/ring)? 

LSVR is progressing with Layer 3 liveness in  draft-ietf-lsvr-l3dl-00

https://datatracker.ietf.org/doc/draft-ietf-lsvr-l3dl/

LSVR is progressing because IDR did not have a consensus on requirements for
a general Layer 3 liveness protocol in 2018. 

This thread is to discuss the requirements for a generalized or 

a specific auto-discovery protocol associated with BGP. 

My next posts will contain the requirements for LSVR Layer 3 liveness and 

draft-xu-idr-neighbor-autodiscovery requirements 

https://datatracker.ietf.org/doc/draft-xu-idr-neighbor-autodiscovery/

Sue Hares

---

From: Robert Raszuk <[email-masked]>
Date: Mon, 10 Jun 2019 21:44:41 +0200

Hi Sue,

> Does IDR think that we should include a generalized auto-discovery
protocol in the IDR WG charter?

Yes. At least for WAN.

> If so, should it be for WAN or Data Center or IPRAN topologies
(grid/ring)?

There has been quite a bit of work history on WAN auto discovery for BGP
(started with IBGP then extended also to EBGP).

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

If LSVR likes to address directly connected peer discovery that to me is
quite separate problem space and they are welcome to proceed.

It would be best if different name is chosen to avoid confusion and that
such peer discovery is not just made exclusive for BGP. BGP while some do
configure it in DC or IP RAN networks tomorrow could be replaced by
different protocol yet peer discovery requirement could stay the same.

Thx,
R.

*From:* Idr [mailto:[email-masked]] *On Behalf Of *Susan Hares
> *Sent:* Monday, June 10, 2019 3:26 PM
> *To:* [email-masked]
> *Cc:* [email-masked]
> *Subject:* [Idr] Issue 2: Auto-configuration Requirements
>
>
>
> IDR WG:
>
>
>
> Does IDR think that we should include a generalized auto-discovery
> protocol in the IDR WG charter?
>
> LSVR is progressing because IDR did not have a consensus on requirements
> for a general Layer 3 liveness protocol in 2018.
>
>
>
> _______________________________________________
> Lsvr mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/lsvr
>

---

From: Randy Bush <[email-masked]>
Date: Mon, 10 Jun 2019 13:46:08 -0700

> draft-xu-idr-neighbor-autodiscovery requirements:

note that this is bgp discovery

the lsvr work in

  draft-ymbk-lsvr-discovery-req
  draft-ietf-lsvr-l3dl-00
  
are discovery of addresses available on links, not bgp specific at all

and

  draft-ymbk-lsvr-l3dl-ulpc

extends l3dl to send the *minimal* information on a link which can be
used to bring up a bgp[-spf] session, leaving the details for, and
trying not to conflict with, BGP OPEN

randy

---

From: Robert Raszuk <[email-masked]>
Date: Tue, 11 Jun 2019 00:25:22 +0200

> are discovery of addresses available on links, not bgp specific at all

And this is *the approach* that should be endorsed !

BGP is opaque to all of this. It just by mistake happens to be overused
today also here, but this will be fixed with time.

r.

---

From: Randy Bush <[email-masked]>
Date: Mon, 10 Jun 2019 15:35:59 -0700

> today also here, but this will be fixed with time.

build an extensible protocol and the resume builders will come.  one of
my favority postel quotes

    It's perfectly appropriate to be upset.  I thought of it in a
    slightly different way--like a space that we were exploring and, in
    the early days, we figured out this consistent path through the
    space: IP, TCP, and so on.  What's been happening over the last few
    years is that the IETF is filling the rest of the space with every
    alternative approach, not necessarily any better.  Every possible
    alternative is now being written down.  And it's not useful.

and, if we look at dns, it does not get fixed over time.  the best we
get is the rate of embellisment slows.

randy

---

From: "Susan Hares" <[email-masked]>
Date: Wed, 12 Jun 2019 14:24:24 -0400

Robert and Randy: 

Let me see if I can start a clear discussion on auto-configuration.   Give
me a few hours.

Sue 

-----Original Message-----
From: Idr [mailto:[email-masked]] On Behalf Of Randy Bush
Sent: Monday, June 10, 2019 6:36 PM
To: Robert Raszuk
Cc: Interminable Discussion Room; [email-masked]
Subject: Re: [Idr] [Lsvr] Issue 2: Auto-configuration Requirements -
draft-xu-idr-neighbor-autodiscovery-requirements

> BGP is opaque to all of this. It just by mistake happens to be 
> overused today also here, but this will be fixed with time.

build an extensible protocol and the resume builders will come.  one of my
favority postel quotes

and, if we look at dns, it does not get fixed over time.  the best we get is
the rate of embellisment slows.

randy

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