From nobody Thu Jun 6 08:08:50 2019 Return-Path: X-Original-To: lsvr@ietf.org Delivered-To: lsvr@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 4BC031200B3; Thu, 6 Jun 2019 08:08:48 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: IETF Meeting Session Request Tool To: Cc: lsvr-chairs@ietf.org, lsvr@ietf.org, gunter@vandevelde.cc, aretana.ietf@gmail.com X-Test-IDTracker: no X-IETF-IDTracker: 6.97.0 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <155983372826.11582.9669320863966286014.idtracker@ietfa.amsl.com> Date: Thu, 06 Jun 2019 08:08:48 -0700 Archived-At: Subject: [Lsvr] lsvr - New Meeting Session Request for IETF 105 X-BeenThere: lsvr@ietf.org X-Mailman-Version: 2.1.29 List-Id: Link State Vector Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Jun 2019 15:08:48 -0000 A new meeting session request has just been submitted by Gunter Van de Velde, a Chair of the lsvr working group. --------------------------------------------------------- Working Group Name: Link State Vector Routing Area Name: Routing Area Session Requester: Gunter Van de Velde Number of Sessions: 1 Length of Session(s): 1.5 Hours Number of Attendees: 100 Conflicts to Avoid: First Priority: idr lsr rtgwg rtgarea sidrops bess grow rift Second Priority: nvo3 spring Third Priority: bier People who must be present: Gunter Van de Velde Alvaro Retana Victor Kuarsingh Resources Requested: Special Requests: --------------------------------------------------------- From nobody Mon Jun 10 12:26:13 2019 Return-Path: X-Original-To: lsvr@ietfa.amsl.com Delivered-To: lsvr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0FECD12007A; Mon, 10 Jun 2019 12:26:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.948 X-Spam-Level: X-Spam-Status: No, score=0.948 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fCQLvza7Pqkr; Mon, 10 Jun 2019 12:26:11 -0700 (PDT) Received: from hickoryhill-consulting.com (50-245-122-100-static.hfc.comcastbusiness.net [50.245.122.100]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id CE059120048; Mon, 10 Jun 2019 12:26:10 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=174.25.175.69; From: "Susan Hares" To: Cc: Date: Mon, 10 Jun 2019 15:26:06 -0400 Message-ID: <01bf01d51fc2$5a07ba30$0e172e90$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_01C0_01D51FA0.D2F86420" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdUfvttyWNVe1hpdSw2yNxAQTaOuog== Content-Language: en-us X-Antivirus: AVG (VPS 190610-6, 06/10/2019), Outbound message X-Antivirus-Status: Not-Tested X-Authenticated-User: skh@ndzh.com Archived-At: Subject: [Lsvr] Issue 2: Auto-configuration Requirements X-BeenThere: lsvr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Link State Vector Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jun 2019 19:26:12 -0000 This is a multipart message in MIME format. ------=_NextPart_000_01C0_01D51FA0.D2F86420 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit 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 ------=_NextPart_000_01C0_01D51FA0.D2F86420 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

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://d= atatracker.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-autodiscover= y/

 

Sue Hares =

 

------=_NextPart_000_01C0_01D51FA0.D2F86420-- From nobody Mon Jun 10 12:29:27 2019 Return-Path: X-Original-To: lsvr@ietfa.amsl.com Delivered-To: lsvr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BD9861201E5; Mon, 10 Jun 2019 12:29:21 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.948 X-Spam-Level: X-Spam-Status: No, score=0.948 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id snjrTuBGpGb5; Mon, 10 Jun 2019 12:29:20 -0700 (PDT) Received: from hickoryhill-consulting.com (50-245-122-100-static.hfc.comcastbusiness.net [50.245.122.100]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0835C12015E; Mon, 10 Jun 2019 12:29:19 -0700 (PDT) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=174.25.175.69; From: "Susan Hares" To: Cc: Date: Mon, 10 Jun 2019 15:29:15 -0400 Message-ID: <01e901d51fc2$cad8a5d0$6089f170$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_01EA_01D51FA1.43C94FC0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdUfwspQ4Ro1opOBT+K1Xn6u2xHiYg== Content-Language: en-us X-Antivirus: AVG (VPS 190610-6, 06/10/2019), Outbound message X-Antivirus-Status: Not-Tested X-Authenticated-User: skh@ndzh.com Archived-At: Subject: Re: [Lsvr] [Idr] Issue 2: Auto-configuration Requirements - LSVR layer 3 discovery and liveness requirements X-BeenThere: lsvr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Link State Vector Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jun 2019 19:29:25 -0000 This is a multipart message in MIME format. ------=_NextPart_000_01EA_01D51FA1.43C94FC0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Requirements list from draft-ietf-lsvr-l3dl-00 Layer 3 Discovery and Liveness (L3DL) provides brutally simple mechanisms for devices to o Discover unique identities of devices/ports/... on a logical link, o Run Layer 2 keep-alive messages for session continuity, o Discover each other's unique endpoint identification, o Discover mutually supported encapsulations, e.g. IP/MPLS, o Discover Layer 3 IP and/or MPLS addressing of interfaces of the encapsulations, o Enable layer 3 link liveness such as BFD, and finally o Present these data, using a very restricted profile of a BGP-LS [RFC7752 ] API, to BGP-SPF which computes the topology and builds routing and forwarding tables. If the a authors of this draft would suggest a different list of requirements, please just respond to this email. Cheerily, Sue Hares From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Susan Hares Sent: Monday, June 10, 2019 3:26 PM To: idr@ietf.org Cc: lsvr@ietf.org 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 ------=_NextPart_000_01EA_01D51FA1.43C94FC0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

Requirements list from = draft-ietf-lsvr-l3dl-00

Layer 3 Discovery and Liveness =
(L3DL) provides brutally simple
   mechanisms for =
devices to
 
=
   o  =
Discover unique identities of devices/ports/... on a logical =
link,
 
=
   o  Run =
Layer 2 keep-alive messages for session =
continuity,
 
=
   o  =
Discover each other's unique endpoint =
identification,
 
=
   o  =
Discover mutually supported encapsulations, e.g.  =
IP/MPLS,
 
=
   o  =
Discover Layer 3 IP and/or MPLS addressing of interfaces of =
the
      =
encapsulations,
 
=
   o  Enable =
layer 3 link liveness such as BFD, and =
finally
 
=
   o  Present =
these data, using a very restricted profile of a =
BGP-LS
      [RFC7752] API, to BGP-SPF which computes the =
topology and builds
      =
routing and forwarding tables.

 

If the a authors of = this draft would suggest a different list of requirements, =

please just respond = to this email.

 

Cheerily, Sue Hares =

 

 

 

From:= = Idr [mailto:idr-bounces@ietf.org] On Behalf Of Susan = Hares
Sent: Monday, June 10, 2019 3:26 PM
To: = idr@ietf.org
Cc: lsvr@ietf.org
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://d= atatracker.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-autodiscover= y/

 

Sue Hares =

 

------=_NextPart_000_01EA_01D51FA1.43C94FC0-- From nobody Mon Jun 10 12:30:14 2019 Return-Path: X-Original-To: lsvr@ietfa.amsl.com Delivered-To: lsvr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D5B561200B3; Mon, 10 Jun 2019 12:30:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.948 X-Spam-Level: X-Spam-Status: No, score=0.948 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dMSs3361NhxC; Mon, 10 Jun 2019 12:30:10 -0700 (PDT) Received: from hickoryhill-consulting.com (50-245-122-100-static.hfc.comcastbusiness.net [50.245.122.100]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3879812008B; Mon, 10 Jun 2019 12:30:10 -0700 (PDT) X-Default-Received-SPF: pass (skip=forwardok (res=PASS)) x-ip-name=174.25.175.69; From: "Susan Hares" To: Cc: Date: Mon, 10 Jun 2019 15:30:05 -0400 Message-ID: <020201d51fc2$e8b748e0$ba25daa0$@ndzh.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0203_01D51FA1.61A90440" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AdUfwtnkXvyVBwtNTGCKb+kjo9I/HA== Content-Language: en-us X-Antivirus: AVG (VPS 190610-6, 06/10/2019), Outbound message X-Antivirus-Status: Not-Tested X-Authenticated-User: skh@ndzh.com Archived-At: Subject: Re: [Lsvr] [Idr] Issue 2: Auto-configuration Requirements - draft-xu-idr-neighbor-autodiscovery-requirements X-BeenThere: lsvr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Link State Vector Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jun 2019 19:30:12 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0203_01D51FA1.61A90440 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit 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:idr-bounces@ietf.org] On Behalf Of Susan Hares Sent: Monday, June 10, 2019 3:26 PM To: idr@ietf.org Cc: lsvr@ietf.org 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 ------=_NextPart_000_0203_01D51FA1.61A90440 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

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:idr-bounces@ietf.org] On Behalf Of Susan = Hares
Sent: Monday, June 10, 2019 3:26 PM
To: = idr@ietf.org
Cc: lsvr@ietf.org
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://d= atatracker.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-autodiscover= y/

 

Sue Hares =

 

------=_NextPart_000_0203_01D51FA1.61A90440-- From nobody Mon Jun 10 12:45:06 2019 Return-Path: X-Original-To: lsvr@ietfa.amsl.com Delivered-To: lsvr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DD6AC12006B; Mon, 10 Jun 2019 12:44:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GUXfJlOgBLiY; Mon, 10 Jun 2019 12:44:52 -0700 (PDT) Received: from mail-pg1-x531.google.com (mail-pg1-x531.google.com [IPv6:2607:f8b0:4864:20::531]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id AAC8F1200CD; Mon, 10 Jun 2019 12:44:52 -0700 (PDT) Received: by mail-pg1-x531.google.com with SMTP id v9so3857216pgr.13; Mon, 10 Jun 2019 12:44:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=2nRYsX5U1GYW56gkmdjGaYcwthf90egSrxX0dq4gQsg=; b=ESrqyzuxTIkwBXn0aadRImEQQCja84lXUX0YVKWQg2By6ab8weNwhp/51BZxMTdk7Q ntrZcmTkH24VMqLOJt9+gQLjcWaUTZiL5BsZ6r8swkvJQc9hY7fRyy92e5DkoqX2+jwC ygFgHjo+5ySXTrsDvdPcIq4BH0Mqu25DP3dnHukAf/b7I4TRwpBY/6BhPrJDmQ3L7ZWF ZW17d6dgTo+wRKjvtVj4X9PkgzyGUTxCXMgKM2AYkDuuBpoYe3Fulm8zDKosu2GLB1MP yeWL3LHuy/pqd9FVZjRyBGV2lB1Bt7P+hji1cnBevPqvp525oVXP6Gi+SlP+vq2Jrovm 0R8w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=2nRYsX5U1GYW56gkmdjGaYcwthf90egSrxX0dq4gQsg=; b=NB8iz+EajDop5TB+4yehLEsYAXr22xBnqASdUdc1s2aHl8lgORX6hec9dQfzZ+s107 81oL7TAwQuFM+RTI1wvmeH/D7JaqXu6XlJ7aIwazdshA6c4qpY+AiBmoIEg7e5Mem+hO R5o/91J2uywoGEo6caAqXV795VhXOjoUooM74LEUnzdbRrCs7Wbe/2tc0G7Opy5ZK2Iu KwC9Mn0WsR9I6SHfyMvh7utpmcQn5Z+hT0M8BGL0lQJo1IPZ1TqUgZmY7RSMmkA2/r6p 5nEvWJoWiE88KXMKQ6FCdZfHKfUup/t4NYN0GO6GEL0UbyjIKV9wzZM3R2HKhzXq+zkb BCfA== X-Gm-Message-State: APjAAAXGCr0Cy9j8ORZ1HmI5y67oEwOVdrTx9qMrPwwUPhF4IO+chbCW J6Tcvq0RS55xwDNSE8FhnNP+yV4UzPYpypkjGRx/CoqxnLisKQ== X-Google-Smtp-Source: APXvYqxJ7gkIfV+NK0PVype9zYCFFjinObK8KBE36MzsOSOmhBwoicu6TynICO1mCgZRQ6fkYWwp4gF2pNQR47IlXno= X-Received: by 2002:a63:5009:: with SMTP id e9mr16739099pgb.396.1560195891478; Mon, 10 Jun 2019 12:44:51 -0700 (PDT) MIME-Version: 1.0 References: <020201d51fc2$e8b748e0$ba25daa0$@ndzh.com> In-Reply-To: <020201d51fc2$e8b748e0$ba25daa0$@ndzh.com> From: Robert Raszuk Date: Mon, 10 Jun 2019 21:44:41 +0200 Message-ID: To: Susan Hares Cc: idr wg , lsvr@ietf.org Content-Type: multipart/alternative; boundary="000000000000e4476b058afd696b" Archived-At: Subject: Re: [Lsvr] [Idr] Issue 2: Auto-configuration Requirements - draft-xu-idr-neighbor-autodiscovery-requirements X-BeenThere: lsvr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Link State Vector Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jun 2019 19:44:55 -0000 --000000000000e4476b058afd696b Content-Type: text/plain; charset="UTF-8" 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:idr-bounces@ietf.org] *On Behalf Of *Susan Hares > *Sent:* Monday, June 10, 2019 3:26 PM > *To:* idr@ietf.org > *Cc:* lsvr@ietf.org > *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 > > > _______________________________________________ > Lsvr mailing list > Lsvr@ietf.org > https://www.ietf.org/mailman/listinfo/lsvr > --000000000000e4476b058afd696b Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Sue,

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


Yes. At least for WAN.=C2=A0


> If so, sho= uld 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 the= n extended also to EBGP).=C2=A0


If LSVR = likes to address directly connected peer discovery that to me is quite sepa= rate problem space and they are welcome to proceed.=C2=A0

It would be best if different name is= chosen to avoid confusion and that such peer discovery is not just made ex= clusive for BGP. BGP while some do configure it in DC or IP RAN networks to= morrow could be replaced by different protocol yet peer discovery requireme= nt could stay the same.=C2=A0

Thx,
R.

=

From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Susan Hares
Sent: Monday, June 10, 2019 3:26 PM
To: idr@ietf.org
Cc:<= /b> lsvr@ietf.orgSubject: [Idr] Issue 2: Auto-configuration Requirements

=C2=A0

IDR WG:

=C2=A0

Does IDR think th= at we should include a generalized auto-discovery protocol in the IDR WG ch= arter?

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

=C2=A0

LSVR is progress= ing with Layer 3 liveness in =C2=A0draft-ietf-lsvr-l3dl-00

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

=C2=A0

LSVR is progressing because IDR did not have a c= onsensus on requirements for a general Layer 3 liveness protocol in 2018. <= u>

=C2=A0

This thread is to discuss the requirements for a generalized or <= u>

a specific auto-discovery protocol a= ssociated with BGP.

=C2=A0

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

draft= -xu-idr-neighbor-autodiscovery requirements

=C2=A0

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

=C2=A0

=

Sue Hares

=C2= =A0

__________________________________________= _____
Lsvr mailing list
Lsvr@ietf.org
https://www.ietf.org/mailman/listinfo/lsvr
--000000000000e4476b058afd696b-- From nobody Mon Jun 10 13:01:25 2019 Return-Path: X-Original-To: lsvr@ietfa.amsl.com Delivered-To: lsvr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CF5A51200F1; Mon, 10 Jun 2019 13:01:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 0h2gsuMA45-P; Mon, 10 Jun 2019 13:01:22 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 1E31812006B; Mon, 10 Jun 2019 13:01:22 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.rg.net) by ran.psg.com with esmtp (Exim 4.90_1) (envelope-from ) id 1haQTn-0003Ii-UT; Mon, 10 Jun 2019 20:01:20 +0000 Date: Mon, 10 Jun 2019 13:01:19 -0700 Message-ID: From: Randy Bush To: "Susan Hares" Cc: , lsvr@ietf.org In-Reply-To: <01bf01d51fc2$5a07ba30$0e172e90$@ndzh.com> References: <01bf01d51fc2$5a07ba30$0e172e90$@ndzh.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/26.2 Mule/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Subject: Re: [Lsvr] Issue 2: Auto-configuration Requirements X-BeenThere: lsvr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Link State Vector Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jun 2019 20:01:24 -0000 > 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)? somewhere is the saying that what is designed for the LAN ends up on the WAN. and if not designed well, does not work well on the WAN. > LSVR is progressing with Layer 3 liveness in draft-ietf-lsvr-l3dl-00 > https://datatracker.ietf.org/doc/draft-ietf-lsvr-l3dl/ l3dl is discovery and liveness. no fun discovering dead things :) you may also be amused by draft-ymbk-lsvr-l3dl-ulpc-00.txt there are updates to these drafts in emacs edit buffers. if you get serious, i can push them out earlier then planned. randy From nobody Mon Jun 10 13:03:30 2019 Return-Path: X-Original-To: lsvr@ietfa.amsl.com Delivered-To: lsvr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A52431200F1; Mon, 10 Jun 2019 13:03:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5QSZ80Ivr-fZ; Mon, 10 Jun 2019 13:03:16 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 162F512008B; Mon, 10 Jun 2019 13:03:16 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.rg.net) by ran.psg.com with esmtp (Exim 4.90_1) (envelope-from ) id 1haQVf-0003JZ-4k; Mon, 10 Jun 2019 20:03:15 +0000 Date: Mon, 10 Jun 2019 13:03:14 -0700 Message-ID: From: Randy Bush To: "Susan Hares" Cc: , lsvr@ietf.org In-Reply-To: <01e901d51fc2$cad8a5d0$6089f170$@ndzh.com> References: <01e901d51fc2$cad8a5d0$6089f170$@ndzh.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/26.2 Mule/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Subject: Re: [Lsvr] [Idr] Issue 2: Auto-configuration Requirements - LSVR layer 3 discovery and liveness requirements X-BeenThere: lsvr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Link State Vector Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jun 2019 20:03:18 -0000 > Requirements list from draft-ietf-lsvr-l3dl-00 > > Layer 3 Discovery and Liveness (L3DL) provides brutally simple > mechanisms for devices to > o Discover unique identities of devices/ports/... on a logical link, > o Run Layer 2 keep-alive messages for session continuity, > o Discover each other's unique endpoint identification, > o Discover mutually supported encapsulations, e.g. IP/MPLS, > o Discover Layer 3 IP and/or MPLS addressing of interfaces of the > encapsulations, > o Enable layer 3 link liveness such as BFD, and finally > o Present these data, using a very restricted profile of a BGP-LS > [RFC7752 ] API, to BGP-SPF which > computes the topology and builds routing and forwarding tables. > > If the a authors of this draft would suggest a different list of > requirements, > > please just respond to this email. draft-ymbk-lsvr-discovery-req-02.txt randy From nobody Mon Jun 10 13:46:22 2019 Return-Path: X-Original-To: lsvr@ietfa.amsl.com Delivered-To: lsvr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F387712004F; Mon, 10 Jun 2019 13:46:11 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id spWkiYLfoy6s; Mon, 10 Jun 2019 13:46:10 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 812BE120018; Mon, 10 Jun 2019 13:46:10 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.rg.net) by ran.psg.com with esmtp (Exim 4.90_1) (envelope-from ) id 1haRBA-0003PF-P8; Mon, 10 Jun 2019 20:46:08 +0000 Date: Mon, 10 Jun 2019 13:46:08 -0700 Message-ID: From: Randy Bush To: "Susan Hares" Cc: , lsvr@ietf.org In-Reply-To: <020201d51fc2$e8b748e0$ba25daa0$@ndzh.com> References: <020201d51fc2$e8b748e0$ba25daa0$@ndzh.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/26.2 Mule/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Subject: Re: [Lsvr] [Idr] Issue 2: Auto-configuration Requirements - draft-xu-idr-neighbor-autodiscovery-requirements X-BeenThere: lsvr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Link State Vector Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jun 2019 20:46:12 -0000 > 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 nobody Mon Jun 10 15:25:44 2019 Return-Path: X-Original-To: lsvr@ietfa.amsl.com Delivered-To: lsvr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AD8B312006E; Mon, 10 Jun 2019 15:25:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.998 X-Spam-Level: X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id bwfWBwnLAD2F; Mon, 10 Jun 2019 15:25:33 -0700 (PDT) Received: from mail-pl1-x62a.google.com (mail-pl1-x62a.google.com [IPv6:2607:f8b0:4864:20::62a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 9B0FB120025; Mon, 10 Jun 2019 15:25:33 -0700 (PDT) Received: by mail-pl1-x62a.google.com with SMTP id go2so4186849plb.9; Mon, 10 Jun 2019 15:25:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=lpaZThYJzBRCMLJyqHoXBK4aJVPzfMKYM/LM9ABiZjI=; b=WpzdQvIy9Um9tDpMRckrKRmzgTwXMAITdEZF3kcX1oLUtJfcuunmHqTQ+4VxdiERwU 3ffaVWpQihDW+uDk2785euRw2xYm1uo00MAslHHIVEZCK+7JTc+v8afJL9s5SCHKzGHW 5gVtZ2wkM9XLKtBjz/RFXy7jToX93t3QCVZfGYYTDtF/VALxlIT2NB1UAd1enLEeI++G C9rjylnnsWEpL3eISo/z4QQBxnMrnSVQMIAcI1RtNyx4FeSo5NrowMqqrcsOQJLT8G9x 1V+0N1flt5TBMQw566eFXp92ZoBqnrizwtpSU+0zCrXS77HoeayeqT0EQHl2Ktpq9DsD Fj1A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=lpaZThYJzBRCMLJyqHoXBK4aJVPzfMKYM/LM9ABiZjI=; b=WJIqdiafZJ+c+Mcqr1x+UEndkbzfjGUAg2kjUX/atWR5FS2AZ51CglLJshYTWSetcJ 7msmKhpRK/tbkwI1caqwaFkeiMrGK9SWDFSGseuL3PTtp4X6FAe4vcOPnsE0yj5wdmO2 hON4C0Eyf9bc5CZJ2XYkSVfRS4flIV/CENzzC2LVwXZ3OeqbNaIIXVQS12Yy9mwvO73v 1doxERAtk+0xqV+Dhqgl8QBFmRzbEhw0Z5imvQUpE0EN5JVbMzUeOcCG0dMJudIzrfyg csoNqcqnIvX8XQPVLLBkRqHw5ChDeWZgOpcUKzYCYUC8Xb8JJeike9JT/fbYaRmLyXyv xUKw== X-Gm-Message-State: APjAAAWGrIfo+5ZyQBIePBBJb0MVaNWTqDw3/vvac6F68DKuk587aqSa 1i0Lk9zvr4Ov/mOx0Nk1vOrfJybw0OK7KgqWabg= X-Google-Smtp-Source: APXvYqzQPA4cZHAQ595kPd6PMxFvD1hyfimlU28dnS4ZqtnC1HoHTiZUcd/nFwTFFS0lWzYWUzH7v/HiOeldh1IALCc= X-Received: by 2002:a17:902:7897:: with SMTP id q23mr71920070pll.21.1560205532622; Mon, 10 Jun 2019 15:25:32 -0700 (PDT) MIME-Version: 1.0 References: <020201d51fc2$e8b748e0$ba25daa0$@ndzh.com> In-Reply-To: From: Robert Raszuk Date: Tue, 11 Jun 2019 00:25:22 +0200 Message-ID: To: Randy Bush Cc: Susan Hares , idr wg , lsvr@ietf.org Content-Type: multipart/alternative; boundary="0000000000008c7732058affa816" Archived-At: Subject: Re: [Lsvr] [Idr] Issue 2: Auto-configuration Requirements - draft-xu-idr-neighbor-autodiscovery-requirements X-BeenThere: lsvr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Link State Vector Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jun 2019 22:25:36 -0000 --0000000000008c7732058affa816 Content-Type: text/plain; charset="UTF-8" > 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. On Mon, Jun 10, 2019 at 10:46 PM Randy Bush wrote: > > 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 > > _______________________________________________ > Lsvr mailing list > Lsvr@ietf.org > https://www.ietf.org/mailman/listinfo/lsvr > --0000000000008c7732058affa816 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable

> are discovery of addresses available o= n links, not bgp specific at all=C2=A0=C2=A0

And this is *the approach* that should be= endorsed !=C2=A0

BGP = is opaque to all of this. It just by mistake happens to be overused today a= lso here, but this will be fixed with time.=C2=A0
<= br>
r.





On Mon, Jun 10, 2019 at 10:46 PM Randy Bush <randy@psg.com> wrote:
> draft-xu-idr-neighbor-autodiscovery requirements:=

note that this is bgp discovery

the lsvr work in

=C2=A0 draft-ymbk-lsvr-discovery-req
=C2=A0 draft-ietf-lsvr-l3dl-00

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

and

=C2=A0 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

_______________________________________________
Lsvr mailing list
Lsvr@ietf.org
https://www.ietf.org/mailman/listinfo/lsvr
--0000000000008c7732058affa816-- From nobody Mon Jun 10 15:36:10 2019 Return-Path: X-Original-To: lsvr@ietfa.amsl.com Delivered-To: lsvr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A9EE912004A; Mon, 10 Jun 2019 15:36:04 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -6.9 X-Spam-Level: X-Spam-Status: No, score=-6.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uVhNmcdAGF7J; Mon, 10 Jun 2019 15:36:02 -0700 (PDT) Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 07025120025; Mon, 10 Jun 2019 15:36:02 -0700 (PDT) Received: from localhost ([127.0.0.1] helo=ryuu.rg.net) by ran.psg.com with esmtp (Exim 4.90_1) (envelope-from ) id 1haStU-0003cZ-0z; Mon, 10 Jun 2019 22:36:00 +0000 Date: Mon, 10 Jun 2019 15:35:59 -0700 Message-ID: From: Randy Bush To: Robert Raszuk Cc: Interminable Discussion Room , lsvr@ietf.org In-Reply-To: References: <020201d51fc2$e8b748e0$ba25daa0$@ndzh.com> User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/26.2 Mule/6.0 (HANACHIRUSATO) MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII Archived-At: Subject: Re: [Lsvr] [Idr] Issue 2: Auto-configuration Requirements - draft-xu-idr-neighbor-autodiscovery-requirements X-BeenThere: lsvr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Link State Vector Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 10 Jun 2019 22:36:05 -0000 > 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 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 nobody Wed Jun 12 11:24:41 2019 Return-Path: X-Original-To: lsvr@ietfa.amsl.com Delivered-To: lsvr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60D4B120253; Wed, 12 Jun 2019 11:24:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.947 X-Spam-Level: X-Spam-Status: No, score=0.947 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DOS_OUTLOOK_TO_MX=2.845, SPF_HELO_NONE=0.001, SPF_NONE=0.001] autolearn=no autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id eVNuUn4wLtiW; Wed, 12 Jun 2019 11:24:33 -0700 (PDT) Received: from hickoryhill-consulting.com (50-245-122-100-static.hfc.comcastbusiness.net [50.245.122.100]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 88223120236; Wed, 12 Jun 2019 11:24:33 -0700 (PDT) X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=174.25.175.69; From: "Susan Hares" To: "'Randy Bush'" , "'Robert Raszuk'" Cc: "'Interminable Discussion Room'" , References: <020201d51fc2$e8b748e0$ba25daa0$@ndzh.com> In-Reply-To: Date: Wed, 12 Jun 2019 14:24:24 -0400 Message-ID: <004101d5214c$107f0a90$317d1fb0$@ndzh.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQMGR0lBxtcqOQSIiNstuFLkU2JC0gGsG14JAlroTbAC17NhK6P/EkjQ Content-Language: en-us X-Antivirus: AVG (VPS 190612-4, 06/12/2019), Outbound message X-Antivirus-Status: Not-Tested X-Authenticated-User: skh@ndzh.com Archived-At: Subject: Re: [Lsvr] [Idr] Issue 2: Auto-configuration Requirements - draft-xu-idr-neighbor-autodiscovery-requirements X-BeenThere: lsvr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Link State Vector Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jun 2019 18:24:41 -0000 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:idr-bounces@ietf.org] On Behalf Of Randy Bush Sent: Monday, June 10, 2019 6:36 PM To: Robert Raszuk Cc: Interminable Discussion Room; lsvr@ietf.org 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 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 _______________________________________________ Idr mailing list Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr From nobody Wed Jun 12 23:08:01 2019 Return-Path: X-Original-To: lsvr@ietf.org Delivered-To: lsvr@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0CA7E120033; Wed, 12 Jun 2019 23:08:00 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: internet-drafts@ietf.org To: Cc: lsvr@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 6.97.0 Auto-Submitted: auto-generated Precedence: bulk Reply-To: lsvr@ietf.org Message-ID: <156040607994.27094.9268238714166343913@ietfa.amsl.com> Date: Wed, 12 Jun 2019 23:08:00 -0700 Archived-At: Subject: [Lsvr] I-D Action: draft-ietf-lsvr-l3dl-01.txt X-BeenThere: lsvr@ietf.org X-Mailman-Version: 2.1.29 List-Id: Link State Vector Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 13 Jun 2019 06:08:00 -0000 A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Link State Vector Routing WG of the IETF. Title : Layer 3 Discovery and Liveness Authors : Randy Bush Rob Austein Keyur Patel Filename : draft-ietf-lsvr-l3dl-01.txt Pages : 33 Date : 2019-06-12 Abstract: In Massive Data Centers (MDCs), BGP-SPF and similar routing protocols are used to build topology and reachability databases. These protocols need to discover IP Layer 3 attributes of links, such as logical link IP encapsulation abilities, IP neighbor address discovery, and link liveness. The Layer 3 Discovery and Liveness protocol specified in this document collects these data, which are then disseminated using BGP-SPF and similar protocols. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-lsvr-l3dl/ There are also htmlized versions available at: https://tools.ietf.org/html/draft-ietf-lsvr-l3dl-01 https://datatracker.ietf.org/doc/html/draft-ietf-lsvr-l3dl-01 A diff from the previous version is available at: https://www.ietf.org/rfcdiff?url2=draft-ietf-lsvr-l3dl-01 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. Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From nobody Mon Jun 24 06:51:05 2019 Return-Path: X-Original-To: lsvr@ietfa.amsl.com Delivered-To: lsvr@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C465A120289 for ; Mon, 24 Jun 2019 06:51:03 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.901 X-Spam-Level: X-Spam-Status: No, score=-1.901 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=nokia.onmicrosoft.com Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LG-JolCrTLhQ for ; Mon, 24 Jun 2019 06:51:01 -0700 (PDT) Received: from EUR03-DB5-obe.outbound.protection.outlook.com (mail-eopbgr40112.outbound.protection.outlook.com [40.107.4.112]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D0E5012012B for ; Mon, 24 Jun 2019 06:51:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nokia.onmicrosoft.com; s=selector1-nokia-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=YkH/g/QJDFI6zwZyLXFlTQaZYiJcpggL7tNT1oprQWI=; b=jSz/jA9Xbkzq3hs68I/5yMWaNJS1HNgNlR9LpT1yukD9ZcIegjLfdxJ9YZ2ABnGaYgkrsQf2c1j9XqL8vlnC9nlZTAW0xy67wBc7Nf8UwNfziqJw6j2QzQp2zmlPr7ZBeYNSLKgLdrkDmQ5ngneUXFukzWzo2AcOpeR0hKlsbyY= Received: from AM0PR07MB5137.eurprd07.prod.outlook.com (20.178.16.154) by AM0PR07MB3860.eurprd07.prod.outlook.com (52.134.85.146) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2008.7; Mon, 24 Jun 2019 13:50:58 +0000 Received: from AM0PR07MB5137.eurprd07.prod.outlook.com ([fe80::c1fd:5646:fa8b:f726]) by AM0PR07MB5137.eurprd07.prod.outlook.com ([fe80::c1fd:5646:fa8b:f726%6]) with mapi id 15.20.2008.014; Mon, 24 Jun 2019 13:50:58 +0000 From: "Van De Velde, Gunter (Nokia - BE/Antwerp)" To: "lsvr@ietf.org" Thread-Topic: IETF 105 LSVR Meeting Call for Agenda Items Thread-Index: AdUqk2m3ieOomNLIRPCCEN2kndXhGg== Date: Mon, 24 Jun 2019 13:50:58 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: spf=none (sender IP is ) smtp.mailfrom=gunter.van_de_velde@nokia.com; x-originating-ip: [131.228.32.163] x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 8f3c42ba-8175-46bc-1afb-08d6f8aafcc3 x-ms-office365-filtering-ht: Tenant x-microsoft-antispam: BCL:0; PCL:0; RULEID:(2390118)(7020095)(4652040)(8989299)(4534185)(4627221)(201703031133081)(201702281549075)(8990200)(5600148)(711020)(4605104)(1401327)(4618075)(2017052603328)(7193020); SRVR:AM0PR07MB3860; x-ms-traffictypediagnostic: AM0PR07MB3860: x-ms-exchange-purlcount: 2 x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:4941; x-forefront-prvs: 007814487B x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(396003)(39860400002)(376002)(346002)(366004)(136003)(199004)(189003)(33656002)(71200400001)(7696005)(9686003)(21615005)(6506007)(236005)(55016002)(99286004)(25786009)(26005)(6306002)(6916009)(316002)(478600001)(86362001)(3846002)(6116002)(486006)(102836004)(476003)(8936002)(54896002)(66946007)(64756008)(14454004)(2906002)(66556008)(8676002)(5640700003)(2351001)(1730700003)(2501003)(5660300002)(256004)(790700001)(6436002)(71190400001)(66446008)(68736007)(81166006)(73956011)(74316002)(81156014)(66066001)(966005)(4744005)(186003)(7736002)(52536014)(66476007)(606006)(76116006)(53936002); DIR:OUT; SFP:1102; SCL:1; SRVR:AM0PR07MB3860; H:AM0PR07MB5137.eurprd07.prod.outlook.com; FPR:; SPF:None; LANG:en; PTR:InfoNoRecords; A:1; MX:1; received-spf: None (protection.outlook.com: nokia.com does not designate permitted sender hosts) x-ms-exchange-senderadcheck: 1 x-microsoft-antispam-message-info: CLG87P2/D9r1selP0sJrjlkpMFMxKvjt0VpRuZh7wnH+5eWuCGYhwvT9v+s2oOpGrmFcK95P5R7zybH4i/Rp2QSMBk1gbjyJsAAxHC+7YmarKz85OfUq4epM7vtpgvEGmi4ldyrtrU5u/osTynO96nNMjwrOWLj4FlXN/KzTX4liLRIdY3CJJfp3J2VT/0aqyRThDjvjieFI3gApN25k77K+B6UO1kOisVvmb/HPfAIVW7Q5PRupHZeuVjMCNqeLjo+4xscWg5Jy+HWpYpn2JpHCdgXRLhi+JIQTeP6jpExKmDKXU+LfdDHVZEPKTAF/YqktDQNdLFhssi4lQVTJstCncTLR2MGuRO8VQHjThiLBHVX3TqnDxBxD9O2WZcV+aH48kBwpzCA0B1iMmyP4VAb9RZpeImCZkvU6/kVBMAQ= Content-Type: multipart/alternative; boundary="_000_AM0PR07MB5137B5BDE30BCF8C681D82A8E0E00AM0PR07MB5137eurp_" MIME-Version: 1.0 X-OriginatorOrg: nokia.com X-MS-Exchange-CrossTenant-Network-Message-Id: 8f3c42ba-8175-46bc-1afb-08d6f8aafcc3 X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Jun 2019 13:50:58.7447 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 5d471751-9675-428d-917b-70f44f9630b0 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: gunter.van_de_velde@nokia.com X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM0PR07MB3860 Archived-At: Subject: [Lsvr] IETF 105 LSVR Meeting Call for Agenda Items X-BeenThere: lsvr@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Link State Vector Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 24 Jun 2019 13:51:04 -0000 --_000_AM0PR07MB5137B5BDE30BCF8C681D82A8E0E00AM0PR07MB5137eurp_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable The LSVR (link-state-vector-routing) WG will be meeting on Tuesday, July 23= th, 2019 from 13:30 to 15:00 AM. Please send us (lsrv-chairs@ietf.org) any requ= ests for presentation slots. Thanks, Gunter & Victor PS: The IETF 105 Preliminary Agenda has been posted. The final agenda will = be published on Friday, June 28, 2019. https://datatracker.ietf.org/meeting/105/agenda.html https://datatracker.ietf.org/meeting/105/agenda.txt --_000_AM0PR07MB5137B5BDE30BCF8C681D82A8E0E00AM0PR07MB5137eurp_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

 

 

The LSVR (link-state-vector-routing) WG will be mee=
ting on Tuesday, July 23th, 2019 from 13:30 to 15:00 AM.<=
/pre>

 


Please send us (lsrv-chairs@ietf.org) any requests for presentation slots.


 


Thanks,


Gunter & Victor


 


PS: The IETF 105 Preliminary Agenda has been posted=
. The final agenda will be published on Friday, June 28, 2019.


https://datatracker.ietf.org/meeting/105/agenda.html=



https://datatracker.ietf.org/meeting/105/agenda.txt


 
--_000_AM0PR07MB5137B5BDE30BCF8C681D82A8E0E00AM0PR07MB5137eurp_-- From nobody Fri Jun 28 16:01:23 2019 Return-Path: X-Original-To: lsvr@ietf.org Delivered-To: lsvr@ietfa.amsl.com Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0E9F8120971; Fri, 28 Jun 2019 15:57:57 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit From: "\"IETF Secretariat\"" To: , Cc: lsvr@ietf.org, aretana.ietf@gmail.com X-Test-IDTracker: no X-IETF-IDTracker: 6.98.1 Auto-Submitted: auto-generated Precedence: bulk Message-ID: <156176267705.11015.12308106324512947429.idtracker@ietfa.amsl.com> Date: Fri, 28 Jun 2019 15:57:57 -0700 Archived-At: Subject: [Lsvr] lsvr - Requested session has been scheduled for IETF 105 X-BeenThere: lsvr@ietf.org X-Mailman-Version: 2.1.29 List-Id: Link State Vector Routing List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 28 Jun 2019 22:58:07 -0000 Dear Gunter Van de Velde, The session(s) that you have requested have been scheduled. Below is the scheduled session information followed by the original request. lsvr Session 1 (1:30 requested) Thursday, 25 July 2019, Morning Session I 1000-1200 Room Name: Viger size: 200 --------------------------------------------- iCalendar: https://datatracker.ietf.org/meeting/105/sessions/lsvr.ics Request Information: --------------------------------------------------------- Working Group Name: Link State Vector Routing Area Name: Routing Area Session Requester: Gunter Van de Velde Number of Sessions: 1 Length of Session(s): 1.5 Hours Number of Attendees: 100 Conflicts to Avoid: First Priority: idr lsr rtgwg rtgarea sidrops bess grow rift Second Priority: nvo3 spring Third Priority: bier People who must be present: Gunter Van de Velde Alvaro Retana Victor Kuarsingh Resources Requested: Special Requests: ---------------------------------------------------------