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

["Les Ginsberg (ginsberg)" <[e-mail]>]

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

2)More importantly, looking at the revised IGP advertisement in

From: Greg Mirsky <[e-mail]>
Sent: Tuesday, July 23, 2024 10:56 AM
To: Les Ginsberg (ginsberg) <ginsberg=[e-mail]>
Cc: [e-mail]; [e-mail]; [e-mail]
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=[e-mail]<mailto:[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]<mailto:[e-mail]> <[e-mail]<mailto:[e-mail]>>
Sent: Tuesday, June 25, 2024 12:25 AM
To: [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[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]<mailto:[e-mail]>
To unsubscribe send an email to [e-mail]<mailto:[e-mail]>