Re: [Idr] draft-dong-idr-node-target-ext-comm-05.txt - WG Adoption and IPR call (9/27 to 10/11/2022)

Jeff Tantsura <jefftant.ietf@gmail.com> Sat, 08 October 2022 19:14 UTC

Return-Path: <jefftant.ietf@gmail.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 B45BDC14F728 for <idr@ietfa.amsl.com>; Sat, 8 Oct 2022 12:14:27 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.212
X-Spam-Level:
X-Spam-Status: No, score=-1.212 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, MIME_HTML_ONLY=0.1, MIME_HTML_ONLY_MULTI=0.001, MIME_QP_LONG_LINE=0.001, MPART_ALT_DIFF=0.79, RCVD_IN_DNSWL_BLOCKED=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=no autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
Received: from mail.ietf.org ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uW07i6kkV-Z5 for <idr@ietfa.amsl.com>; Sat, 8 Oct 2022 12:14:25 -0700 (PDT)
Received: from mail-pg1-x536.google.com (mail-pg1-x536.google.com [IPv6:2607:f8b0:4864:20::536]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 8FC26C14F724 for <idr@ietf.org>; Sat, 8 Oct 2022 12:14:25 -0700 (PDT)
Received: by mail-pg1-x536.google.com with SMTP id j71so7298283pge.2 for <idr@ietf.org>; Sat, 08 Oct 2022 12:14:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=to:in-reply-to:cc:references:message-id:date:subject:mime-version :from:content-transfer-encoding:from:to:cc:subject:date:message-id :reply-to; bh=RQkmOCGxVo7xcogT3vV8QnZ2VXcGnViLy9L/h0REjIQ=; b=lzXnNDyNwp6Edy9Ckj4uIl0gJcu5zHnjSF4hDZnEiwaBa+8Ko0aT51TRJlhtjc9CHF ECACvpIsKPDU49PE/y4+2RQFDofwydYwWN3XqxoB9oB5r77OuchikEXbuIUlkO0MFaFe 3Y5AEtTy9ayS1ivw95TiIUOlcEX62HhyfaM6v7usKUryWcyHIfHQQouMMobOCfdrc90y hmfpw07aroi6rnBt8AF2ep6D8eNSztTbhBkb5H4224L80ia4649K4FUqD0CWzaLedZHe Y0aBQE/H0RyUwudwcNmm8iX4hqOLLrWas00359iNe75Letnp78t3pSd/Uy03sNDK1OjA K9xg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=to:in-reply-to:cc:references:message-id:date:subject:mime-version :from:content-transfer-encoding:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=RQkmOCGxVo7xcogT3vV8QnZ2VXcGnViLy9L/h0REjIQ=; b=WAbW1t3SA7xEDrxasXNfpg+qiqUU55Cqe3SJjI/1HvQYDJZqbEZixn8wEvk+OmzPND QT9uL5or5LTSCtvmiieqwCqLaJ0W2esauPTe44xfd814azQzqNZBb6Hj4lfflR+314hd Rfgt92/WJ01/qDoRHFsSWd2v3Run2fG8qeiGXl5OieSspWEoMPQ/o8OOftyabf5lRGHB +KGbdTnYUIFBBudTHX6pq7ggNhMvELNaMBAGbQcYpr8mvsiiZEGKOBK3BZC1LEtMARy1 9IMhGUO/GViMqhfFVjOji+yqsYEj3EC8FhxDDEPVU7x34CUd5Zki2RY2yZX/tkTbINas 84xA==
X-Gm-Message-State: ACrzQf15G7xgiRwPKkZ0NdQm6GQEx8BAfuCvaMwNlry0WAOLRJmtbMUk 7s1Z7zIqq3IyMwlV2QG83SCwXDH+8VU=
X-Google-Smtp-Source: AMsMyM7av8iY+rkC/GMAGjD4nrTTCS/Nu7Rvj0E0XZLRN5/VR26OmgoBo+fSOrGrQdcwdliTuZOZbQ==
X-Received: by 2002:a63:cc4a:0:b0:439:1c48:2fed with SMTP id q10-20020a63cc4a000000b004391c482fedmr10046432pgi.618.1665256464764; Sat, 08 Oct 2022 12:14:24 -0700 (PDT)
Received: from smtpclient.apple (c-73-63-232-212.hsd1.ca.comcast.net. [73.63.232.212]) by smtp.gmail.com with ESMTPSA id b9-20020aa78ec9000000b00562a90f9875sm3817198pfr.167.2022.10.08.12.14.24 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 08 Oct 2022 12:14:24 -0700 (PDT)
Content-Type: multipart/alternative; boundary="Apple-Mail-E38F5FB0-60AA-4C08-943C-82AD76CFEF94"
Content-Transfer-Encoding: 7bit
From: Jeff Tantsura <jefftant.ietf@gmail.com>
Mime-Version: 1.0 (1.0)
Date: Sat, 08 Oct 2022 12:14:13 -0700
Message-Id: <2A2F4622-CFFD-4253-8DBA-488EBC47861B@gmail.com>
References: <CAOj+MMGmOvK-THYVc=+A27Fwfp-BHooeNrDJVYsj0owC=N68Xw@mail.gmail.com>
Cc: Susan Hares <shares@ndzh.com>, idr@ietf.org, "Van De Velde, Gunter (Nokia - BE/Antwerp)" <gunter.van_de_velde@nokia.com>
In-Reply-To: <CAOj+MMGmOvK-THYVc=+A27Fwfp-BHooeNrDJVYsj0owC=N68Xw@mail.gmail.com>
To: Robert Raszuk <robert@raszuk.net>
X-Mailer: iPhone Mail (20A380)
Archived-At: <https://mailarchive.ietf.org/arch/msg/idr/6mXBLMcqZ0kwJALZNvAHgUEnHYA>
Subject: Re: [Idr] draft-dong-idr-node-target-ext-comm-05.txt - WG Adoption and IPR call (9/27 to 10/11/2022)
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.39
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: Sat, 08 Oct 2022 19:14:27 -0000

I support the progress of the draft, there’s a potential to use the functionality proposed in DC (RFC7938 alike deployments), I mostly agree with the points Robert has made, including philosophical ones (which is the train that has left the station long time ago ;-)).
Robert - would you please elaborate on:

I am not 100% sure if all nodes will continue to operate fine if they will be receiving withdraws for NLRIs never previously received. 

I don’t really see anything broken here, but I’m also not an implementor (just a consumer at scale).

Thanks!

Cheers,
Jeff

On Sep 27, 2022, at 14:42, Robert Raszuk <robert@raszuk.net> wrote:


Hi Sue & Authors,

I have re-read the draft and have two concerns and suggestion. Concerns IMO need to be addressed before we adopt the draft. Suggestions can be added later. 

Major concern: 

The document talks about procedure during dissemination of update message(s). It is however completely silent about withdraws. As we know BGP UPDATE which contains withdraws can be build using only subject NLRIs. That means that those may/will not be subject to discussed filtering. 

I am not 100% sure if all nodes will continue to operate fine if they will be receiving withdraws for NLRIs never previously received. Yet propagating withdraws will happen everywhere. 

To address this well it seems that capability negotiation would be the safest bet. But isn't this too much to ask ? 

Minor concern: 

Which is more important RT or NT ? (RT when used with RTC of course). 

Suggestion: 

I would propose to make Target BGP Id to be a prefix not fixed 4 octet field. Wisely choosing BGP Ids can lead to very efficient distribution. 

Final word: 

Of course this proposal goes against BGP p2mp principle, but at least it is not p2p, but have potential built in to make it p2(subset-of-multipoint)peers. 

Thx a lot,
Robert.


On Tue, Sep 27, 2022 at 7:31 PM Susan Hares <shares@ndzh.com> wrote:

This begins a 2 week WG adoption and IPR call for draft-dong-idr-node-target-ext-comm-05.txt.

https://datatracker.ietf.org/doc/draft-dong-idr-node-target-ext-comm/" target="_blank" rel="nofollow">https://datatracker.ietf.org/doc/draft-dong-idr-node-target-ext-comm/

 

The authors should respond to this email with an IPR statement.

 

The WG should consider in their discussion:

1) Will this new  transitive extended community help

in operational networks?

 

2) What conflicts does this new Extended Community have

with other functions in general BGP route distribution or

VPNs (EVPN, IPVPN)?

 

3) do you have any concern about the text in the draft?

 

Cheerily, Sue

_______________________________________________
Idr mailing list
Idr@ietf.org
https://www.ietf.org/mailman/listinfo/idr" rel="noreferrer nofollow" target="_blank">https://www.ietf.org/mailman/listinfo/idr
_______________________________________________
Idr mailing list
Idr@ietf.org
https://www.ietf.org/mailman/listinfo/idr