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

Robert Raszuk <> Tue, 04 June 2019 13:46 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 328C012004E for <>; Tue, 4 Jun 2019 06:46:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id IiQOfr502ijm for <>; Tue, 4 Jun 2019 06:45:59 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4864:20::72c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id B31E7120004 for <>; Tue, 4 Jun 2019 06:45:59 -0700 (PDT)
Received: by with SMTP id w187so2813275qkb.11 for <>; Tue, 04 Jun 2019 06:45:59 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=LQyYYsGmFM68yIM+Kq/WPJ5Aq1yP1Hru+tXCy8zS2Cc=; b=NJKMM81XTj0uHZEgooAGLzVnR+6QKHyx+RxdGnShQGE/BmzgKwUSuprmMnbUZWK8zz XfHUr1Ov0Xeg3VKFp0yxcBYVDIQQLYXwK0LHLSl3HNV/AdH+ovGDzd/KqCNfk+6MAK2+ kiuoNo1NZM1bDEFfu0v9UTe/pOmqJxkvx8hgmQ3jXXuiD+1PbrzOIqpAUqGt6lvkUrM8 4KSLMMr1yVGq86hyUqfLNlvYsZ8VmxZwwOz+gh6OW3OzIUhOGdQwY2n95Sl9M0+kbHUk HJzUfnLtlFh5LqlH1Zjr7YNuh0nClWJgrcBgPORIUBc7cfG2jBGPjoxYJ4w4SxDhnPDE toRw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=LQyYYsGmFM68yIM+Kq/WPJ5Aq1yP1Hru+tXCy8zS2Cc=; b=HlrP1sSFGoqroVTlVmqbrXwEei9kF4jzzWrcMF2YEkMv8YtytaQG0FYI5rQZwIf2UG 1CN5bUgkhkVqZzr2UfsUwl/s0GCKqUjSq795z20Y6E7fi7ibmXhE1uG+KL1LFl3aW9Ck VbmevvfkJ+14KKWos48QdgjSeEV4GoCTVOTKdqgpB2JmGoItYyM6KlmR9DC19J2sm6sA Wwtp/Tbp1KfjZBSHf6qMRV2IbkknULrb3bgwF9T3R4hBgvvjT9XK/WcqGMxObH6CPq0l Wm7hViW7dg44Eoz+vIJR+CeaHqO7hNWskmhym+NjVjdL8/7JFh1x7/V4iSm6t9c2RR8t RW3w==
X-Gm-Message-State: APjAAAXGrSHvtkJ0X8ZOwcA/1Ds39esS0T9FVpb7vfvxehPe+NMkhnFk wD6i+CZvHE+hDTM0kd+qwOr23MZEukzF7cJe1MDXWw==
X-Google-Smtp-Source: APXvYqypKotVKm1M53JHdR5SepvTPmNd2SUfSy3ymNjJSk9FA2rOPu3RU2+AOIXx7JZmnEU+M4fhtEM9/Lmt5dhpCdY=
X-Received: by 2002:a05:620a:1206:: with SMTP id u6mr26671425qkj.88.1559655958602; Tue, 04 Jun 2019 06:45:58 -0700 (PDT)
MIME-Version: 1.0
References: <01ce01d5167f$d263a120$772ae360$> <> <02cf01d51ab1$052bfc80$> <004201d51abd$498a5000$dc9ef000$> <> <005301d51ac3$4b6e6a90$e24b3fb0$>
In-Reply-To: <005301d51ac3$4b6e6a90$e24b3fb0$>
From: Robert Raszuk <>
Date: Tue, 04 Jun 2019 15:45:46 +0200
Message-ID: <>
To: Susan Hares <>
Cc: "idr@ietf. org" <>
Content-Type: multipart/alternative; boundary="000000000000627fcd058a7fb3f1"
Archived-At: <>
Subject: Re: [Idr] Adoption call for draft-dawra-idr-bgpls-srv6-ext [5/2 - 5/16/2018]
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Inter-Domain Routing <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 04 Jun 2019 13:46:03 -0000

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 ,,,

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

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

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 ....