IETF Logo Mail Archive

Re: [Idr] Adoption call for draft-dawra-idr-bgpls-srv6-ext [5/2 - 5/16/2018]

"Susan Hares" <shares@ndzh.com> Tue, 04 June 2019 14:35 UTC

Return-Path: <shares@ndzh.com>
X-Original-To: idr@ietfa.amsl.com
Delivered-To: idr@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9792A1200B4 for <idr@ietfa.amsl.com>; Tue, 4 Jun 2019 07:35:38 -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 6LNVn5XoC1UF for <idr@ietfa.amsl.com>; Tue, 4 Jun 2019 07:35:36 -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 C492B1200A1 for <idr@ietf.org>; Tue, 4 Jun 2019 07:35:35 -0700 (PDT)
X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=174.25.215.70;
From: Susan Hares <shares@ndzh.com>
To: 'Robert Raszuk' <robert@raszuk.net>
Cc: "'idr@ietf. org'" <idr@ietf.org>
References: <01ce01d5167f$d263a120$772ae360$@ndzh.com> <DM5PR11MB202720F61953C224DB081498C1140@DM5PR11MB2027.namprd11.prod.outlook.com> <02cf01d51ab1$052bfc80$4001a8c0@gateway.2wire.net> <004201d51abd$498a5000$dc9ef000$@ndzh.com> <CAOj+MMEnyT1sOX9fWbDR4PV4goBZerdF6ykKUbZ2t3YDRyAHfg@mail.gmail.com> <005301d51ac3$4b6e6a90$e24b3fb0$@ndzh.com> <CAOj+MMHV0G_O9p7F0UPHXUtzz6HWSiVa5EsLosZu3Q7U_Gr32A@mail.gmail.com>
In-Reply-To: <CAOj+MMHV0G_O9p7F0UPHXUtzz6HWSiVa5EsLosZu3Q7U_Gr32A@mail.gmail.com>
Date: Tue, 04 Jun 2019 10:35:32 -0400
Message-ID: <011601d51ae2$c3f6a530$4be3ef90$@ndzh.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0117_01D51AC1.3CE50530"
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AQGY39g/S8sCt+WuAGK2LIFpJMMw4wIpWAlKAqyDdnsDWhrmLAJBikNdAsYOOOABfs+7F6aOUqcw
Content-Language: en-us
X-Antivirus: AVG (VPS 190604-2, 06/04/2019), Outbound message
X-Antivirus-Status: Not-Tested
X-Authenticated-User: skh@ndzh.com
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/Uz6DoiDE3ci42_RNUYAjksru3Wo>
Subject: Re: [Idr] Adoption call for draft-dawra-idr-bgpls-srv6-ext [5/2 - 5/16/2018]
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/idr/>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 04 Jun 2019 14:35:39 -0000

Robert:

 

You are welcome to send these comments to Alvaro and to the IESG regarding IDR’s charter and the impact on SPRING. 

 

Sue 

 

From: Idr [mailto:idr-bounces@ietf.org] On Behalf Of Robert Raszuk
Sent: Tuesday, June 4, 2019 9:46 AM
To: Susan Hares
Cc: idr@ietf. org
Subject: Re: [Idr] Adoption call for draft-dawra-idr-bgpls-srv6-ext [5/2 - 5/16/2018]

 

Hi Sue,

 

As to the 99% of BGP-LS,  that’s a question the chairs and ADs tried to ask the WG in 2018.   The WG did not engage on that discussion. 

 

I reread the IDR charter ,,, https://datatracker.ietf.org/wg/idr/about/

 

I did not find anything there which would justify any of the work related to BGP-LS needs in this WG for example - topology or link state information transport. 

 

IMO AD should recognize the need for various non routing information transport and steer this towards BOF and new WG creation to define new protocol for it.. Even if rather from scratch such effort would reuse some of the BGP features. And while it was not done up front it is not too late now. 

 

In order to protect the BGP stream,  the ADs/Chairs pushed for draft-ketana-rfc7752bis.txt (for improved error handling) and larger BGP messages (see raft-ietf-idr-bgp-extended-messages-30.txt).  

 

Improving error handling is always good. 

 

But how making the message larger helps to protect the BGP stream ? Its like opening the window wider when cloud of wild insects approaches .... 

 

Best,

R.

v2.23.0 | Report a Bug | By Email