[Bier] Re: Call for review for draft-ietf-bier-bfd

Greg Mirsky <gregimirsky@gmail.com> Wed, 24 July 2024 17:12 UTC

Return-Path: <gregimirsky@gmail.com>
X-Original-To: bier@ietfa.amsl.com
Delivered-To: bier@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A5B4C1840C8; Wed, 24 Jul 2024 10:12:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.851
X-Spam-Level:
X-Spam-Status: No, score=-5.851 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, NORMAL_HTTP_TO_IP=0.001, NUMERIC_HTTP_ADDR=1.242, RCVD_IN_DNSWL_HI=-5, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_HTML_ATTACH=0.01, T_SCC_BODY_TEXT_LINE=-0.01, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=0.001] autolearn=unavailable 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 usD2_-ZOQkkm; Wed, 24 Jul 2024 10:12:30 -0700 (PDT)
Received: from mail-yb1-xb2a.google.com (mail-yb1-xb2a.google.com [IPv6:2607:f8b0:4864:20::b2a]) (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 EC959C180B5A; Wed, 24 Jul 2024 10:12:29 -0700 (PDT)
Received: by mail-yb1-xb2a.google.com with SMTP id 3f1490d57ef6-e0878971aa9so83630276.0; Wed, 24 Jul 2024 10:12:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1721841149; x=1722445949; darn=ietf.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=wwHwjSFCrAMUQfuubNOgI7TOvf5G6bA081vPgeFshU8=; b=RUzp9LRDhTNn95+USxm91VPNccWMGq4rCcIre+pJv5OpC7hUBTQCJuSJtwRkV7+dis AMr1XHNma02uwN842LCMyea7TjiBjZgkSUvdvy50BjB54i/UJZevb6oObho2aiUdynJQ 7kMEmDVJF1h9fUdqXyKsRA227Gv7TAfWnD1vADMWbQAkL7PGemmSnq3oxzv8N3pG34mG Y/wxl7nS/aNV+EXXv8O0IE+cP0W0dtuvNytcbek3ISwU/qgyM1gctJyeJiQ4W8W4Ar/r IcmNchOEKi4Qwdk+5ZnzKlIFIqUimtzC7dugHQm6oTF/FkdKf/Gj36GttDPYjJ/uA6wM is4Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1721841149; x=1722445949; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=wwHwjSFCrAMUQfuubNOgI7TOvf5G6bA081vPgeFshU8=; b=eiwFnXSaxteWXqcaKz0UIUC9TF5czP06y5/q6HgKS+e4i2VRzNzJ5uLMbZIScSgNHe 8d3Mv4YuXv1+3uYRPHdU6CxOsglYIDY5NnZO1zXiXCOQnglYBn4KItl/h0zDEB6hng7i o7mX2v3CQhdU62vl3snjfIfr5I5CkdnLn/Xh2doA629SAzinf9dt3cZ2dEGhrL79u6i1 ZYKR6s1RcXmo70PNAKlRmdidbcrRWEt2n92dniJJfoTrAH5XxUm/xARguQfb4ZrHafUi p6xdS+6559ENAOK2bHI7Qyfx+LNV8kNx2WsLom6MgUL+rhDP42KWAt2jWytwRIzPfySv BKpA==
X-Forwarded-Encrypted: i=1; AJvYcCWFaSkDoivHg+l1a1a0LuHzakpy3WLlcPp5Oebm73TMV0RJiaVSxlFN80MPWlb+MKhpJsiiqhT5rT7xcqYXYXdq0ZRo16+7DYE99H39OL2E
X-Gm-Message-State: AOJu0YxwHeumJUbFcCGlM0UJbd5H97aJE+AYCbi4wAQ+OrH89E08GyUr RPmiT9KqVIhEIwxfrxrt0RTXAFhmvCmlgQ8JEqr3Sm/oUF/CTjASOA8rS8WQCH4b9DlZP2cFGs7 Hk8vakX1Eeh7b7MKnkvQGtiD9CIA=
X-Google-Smtp-Source: AGHT+IEvC1uugWy8Pmi8ptcSh5cBLjsGNDvn+/jRJgpO1X1H7T0OWO/H9GsT6/FwloU7qvM66M9piCqpINdc1jrpxUg=
X-Received: by 2002:a05:6902:2609:b0:e05:f97e:c417 with SMTP id 3f1490d57ef6-e0b225c2b75mr227076276.24.1721841148654; Wed, 24 Jul 2024 10:12:28 -0700 (PDT)
MIME-Version: 1.0
References: <20240625152506310zqVv53aO_wi-6iOS8xsZs@zte.com.cn> <BY5PR11MB43374713B3726C0C170DF720C1DA2@BY5PR11MB4337.namprd11.prod.outlook.com> <CA+RyBmVEgqkB6RAZ7kUGVdJ4FgHfmuMaumt6Mep4CRHOjDKDeA@mail.gmail.com> <BY5PR11MB43370EDC112AADF6205C430AC1AA2@BY5PR11MB4337.namprd11.prod.outlook.com>
In-Reply-To: <BY5PR11MB43370EDC112AADF6205C430AC1AA2@BY5PR11MB4337.namprd11.prod.outlook.com>
From: Greg Mirsky <gregimirsky@gmail.com>
Date: Wed, 24 Jul 2024 10:12:18 -0700
Message-ID: <CA+RyBmVufnPA48M3iJknDJMDeA51SBouhmTRD5gK61tZdwDy9A@mail.gmail.com>
To: "Les Ginsberg (ginsberg)" <ginsberg@cisco.com>
Content-Type: multipart/mixed; boundary="000000000000069b87061e016207"
Message-ID-Hash: HYSATKIM2CLDKWT2WCEYGUMZ5KWOYC7X
X-Message-ID-Hash: HYSATKIM2CLDKWT2WCEYGUMZ5KWOYC7X
X-MailFrom: gregimirsky@gmail.com
X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; header-match-bier.ietf.org-0; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header
CC: "Les Ginsberg (ginsberg)" <ginsberg=40cisco.com@dmarc.ietf.org>, "zhang.zheng@zte.com.cn" <zhang.zheng@zte.com.cn>, "rtg-bfd@ietf.org" <rtg-bfd@ietf.org>, "bier@ietf.org" <bier@ietf.org>
X-Mailman-Version: 3.3.9rc4
Precedence: list
Subject: [Bier] Re: Call for review for draft-ietf-bier-bfd
List-Id: "\"Bit Indexed Explicit Replication discussion list\"" <bier.ietf.org>
Archived-At: <https://mailarchive.ietf.org/arch/msg/bier/GWpdgaMzIZWWWLEXo48bolSamI0>
List-Archive: <https://mailarchive.ietf.org/arch/browse/bier>
List-Help: <mailto:bier-request@ietf.org?subject=help>
List-Owner: <mailto:bier-owner@ietf.org>
List-Post: <mailto:bier@ietf.org>
List-Subscribe: <mailto:bier-join@ietf.org>
List-Unsubscribe: <mailto:bier-leave@ietf.org>

Hi Les,
thank you for your thorough review and patience. Please find my follow-up
notes below tagged GIM2>>.  Attached, please find the updated working
version with the diff highlighting al the applied updates.

Regards,
Greg

On Tue, Jul 23, 2024 at 6:47 PM Les Ginsberg (ginsberg) <ginsberg@cisco.com>
wrote:

> (accidentally hit send too soon – please ignore previous email)
>
>
>
> Greg –
>
>
>
> Thanx for responding to my comments.
>
>
>
> Looking at the revised draft, I confess to being somewhat confused. Please
> help me understand.
>
>
>
> 1)The text in Section 4.2 is unchanged. It still says:
>
>
>
> “The BFIR generates the My Discriminator value for each multicast flow
>
>    and advertises it to the expecting BFERs, which is indicated by the
>
>    Bitstring and the BIFT-id,”
>
>
>
> This is not consistent with the revised format of the IGP advertisements.
>
GIM2>> My sincere apologies for rather sloppy cleanup. Bitstring is
removed.

>
>
> 2)More importantly, looking at the revised IGP advertisement in Section
> 4.2.1, we have:
>
>   No. of octets
>
>     +-----------------------------+
>
>     | Type = TBD3                 |     1
>
>     +-----------------------------+
>
>     | Length (multiple of 2)      |     1
>
>     +-----------------------------+
>
>     | BIFT-id                     |     2
>
>     +-----------------------------+
>
>     | My Discriminator(s)         |     4 * Number of My Discriminator(s)
>
>     :                             :
>
>     +-----------------------------+
>
>
>
> I do not understand the relationship between the multiple discriminators
> and the single BIFT-id.
>
GIM2>> BIFT-id may be used in demultiplexing BFD control packets as defined
in Section 5:
  The source address is BFIR-id and
   BIER MPLS Label (MPLS network) or BFIR-id and BIFT-id (Non-MPLS
   network) for BIER BFD.  My Discriminator value is advertised in BIER
   BFD bootstrapping using one of the options described in Section 4.
It is expected that the BFIR advertises its My Discriminators without
specifing intended BFERs. A BFER will use My Discriminator values, and
possibly BIFT-id, to demultiplex BFD Control packets received over UDP port
3784 (RFC 8562 <http://3784>).


> Don’t you use the same Discriminator for all of the BFERs for a given
> multipoint path??
>
 GIM2>> Yes, BFERs that belong to the same multicast distribution tree
receive BFD Control packets with the same My Discriminator. But the same
BFIR will use a different My Discriminator value to monitor another
multipoint path with, possibly, an overlapping set of BFERs.

>
>
> Previously the bit string presumably identified the set of BFERs.
>
> Now you have multiple discriminators.
>
> I am frankly lost here.
>
> ??
>
GIM2>> A BFER will use all My Discriminators advertised by the given
BFIR to demultiplex received BFD Control packet. Upon disucssing, we
realized that identifying the set of BFERs expected to receive a BFD
Control packet with the specified My Discriminator is too burdensome,
unnecessary.

>
>
>    Les
>
>
>
>
>
> *From:* Greg Mirsky <gregimirsky@gmail.com>
> *Sent:* Tuesday, July 23, 2024 10:56 AM
> *To:* Les Ginsberg (ginsberg) <ginsberg=40cisco.com@dmarc.ietf.org>
> *Cc:* zhang.zheng@zte.com.cn; rtg-bfd@ietf.org; bier@ietf.org
> *Subject:* [Bier] Re: Call for review for draft-ietf-bier-bfd
>
>
>
> Hi Les,
>
> thank you for your thoughtful questions and comments; much appreciated.
> The authors discussed them and we propose updates that are reflected in the
> attached copy of the working version and highlighted in the diff.
> Although the BitString information is useful for a tail, it, for the
> purpose of reporting defects to the head of the multicast tree, is
> optional. In fact, the identity if the BFIR and its unique My Discriminator
> value are sufficient to correlate a notification from the tail to the
> appropriate BitString set.
>
> Your comments on the updates are most welcome.
>
>
>
> Regards,
>
> Greg
>
>
>
> On Sun, Jul 7, 2024 at 10:15 PM Les Ginsberg (ginsberg) <ginsberg=
> 40cisco.com@dmarc.ietf.org> wrote:
>
> Folks –
>
>
>
> I apologize for the lateness of my comments – I don’t consistently track
> BIER WG. Some of what I say below would certainly have been more beneficial
> if provided earlier.
>
> Nevertheless..
>
>
>
> Regarding the proposal for new IGP Extensions for advertising BIER BFD
> information:
>
>
>
> I am troubled at the idea of having the IGP advertise information which
> includes the BIER Bit-String representing the relevant BFR-IDs. This string
> (defined in RFC 8296) can potentially be up to 4K bits (512 bytes) long.
>
> This is a lot of information for the IGPs to carry – and is particularly
> troublesome for IS-IS where it exceeds the carrying capacity of a single
> TLV (max 255 bytes).
>
>
>
> As a more minor point, the presence of the RESERVED field is inappropriate
> for IS-IS. This is commonly done in OSPF to preserve 4 byte field
> alignment, but this is useless in IS-IS and only serves to bloat the TLV
> size unnecessarily.
>
>
>
> In a larger context, the only previous use of the IGPs to advertise BFD
> discriminators that I am aware of was done in support of S-BFD (RFC 7883).
> To my knowledge, implementations have not made use of this extension –
> perhaps in part because assignment of discriminators based on information
> in an IGP database has not proved appealing – which calls into question why
> we should do this here.
>
> NOTE: I am happy to hear feedback from others that RFC 7883 is in fact
> being used.
>
>
>
> Finally, I ask whether any implementation of this draft – even as a POC –
> has been done? If so, what has been learned?
>
> In general, I am concerned that in the absence of implementation
> experience we may be standardizing things prematurely.
>
>
>
> Thanx for listening to my very late remarks.
>
>
>
>     Les
>
>
>
>
>
> *From:* zhang.zheng@zte.com.cn <zhang.zheng@zte.com.cn>
> *Sent:* Tuesday, June 25, 2024 12:25 AM
> *To:* rtg-bfd@ietf.org; bier@ietf.org
> *Subject:* [Bier] Call for review for draft-ietf-bier-bfd
>
>
>
> Hi,
>
> The draft-ietf-bier-bfd passed last call in BIER WG.
>
> We'd like to get more review in BFD WG:
> https://datatracker.ietf.org/doc/draft-ietf-bier-bfd/
>
> Comments and suggestion welcomed, please send your comments before 9th,
> July.
>
>
>
> And please volunteer if you want to be the shepherd of this draft.
>
> Thank you!
>
> Best regards,
>
> Sandy
>
>
>
>
>
> _______________________________________________
> BIER mailing list -- bier@ietf.org
> To unsubscribe send an email to bier-leave@ietf.org
>
>