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

[Greg Mirsky <[e-mail]>]

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]> 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]> 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]>
>> *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]> 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]
>>
>>