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

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

Greg –

Thanx for the good discussion.

As the IGP support is no longer part of the draft, all my concerns have been addressed.

   Les

From: Greg Mirsky <[e-mail]>
Sent: Thursday, July 25, 2024 9:41 PM
To: Les Ginsberg (ginsberg) <[e-mail]>
Cc: Les Ginsberg (ginsberg) <[e-mail]>; [e-mail]; [e-mail]; [e-mail]
Subject: Re: [Bier] Re: Call for review for draft-ietf-bier-bfd

Hi Les,
Thank you for granting me your time for further discussion. I've updated the working version as we agreed. I would appreciate it if you could confirm that the updates address your concerns. The current working version and the diff highlighting all applied changes are attached.

Regards,
Greg

On Wed, Jul 24, 2024 at 10:12 AM Greg Mirsky <[e-mail]<mailto:[e-mail]>> wrote:
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) <[e-mail]<mailto:[e-mail]>> 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 <[e-mail]<mailto:[e-mail]>>
Sent: Tuesday, July 23, 2024 10:56 AM
To: Les Ginsberg (ginsberg) <ginsberg=[e-mail]<mailto:[e-mail]>>
Cc: [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[e-mail]>; [e-mail]<mailto:[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]>