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

[Greg Mirsky <[e-mail]>]

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=
[e-mail]> 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:* [e-mail] <[e-mail]>
> *Sent:* Tuesday, June 25, 2024 12:25 AM
> *To:* [e-mail]; [e-mail]
> *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 -- [e-mail]
> To unsubscribe send an email to [e-mail]
>