Re: [yang-doctors] Dealing with BFD RFC 9127 client-cfg-parms for PIM, OSPF, ISIS and other BFD clients on some platforms

[Jeffrey Haas <[e-mail]>]

Rob,

Thanks for your patience.  Mahesh was good enough to help us avoid coordination issues by getting this centralized in github.

https://github.com/mjethanandani/rfc9127-bis/tree/v01/draft <https://github.com/mjethanandani/rfc9127-bis/tree/v01/draft>

You will find the target draft, and the diff in the above portion of the repo.

What I think the next steps look like:
- Yang doctors confirm they're happy with things.
- We post the draft and request BFD WG review as part of immediate last-call and give a few days for that review.
- Submit 9127-bis draft and simultaneously request RFC Editor to clear blocks on pending cluster documents since the issue is resolved without changes needed.

I think the RFC Editor may need to be requested to revert the changes Acee had started with when we began this.

-- Jeff




> On Nov 19, 2021, at 4:56 AM, Rob Wilton (rwilton) <[e-mail]> wrote:
> 
> Hi Jeff, Mahesh,
> 
> Any update on that diff?
> 
> Thanks,
> Rob
> 
> 
> -----Original Message-----
> From: Jeffrey Haas <[e-mail]> 
> Sent: 10 November 2021 23:26
> To: Rob Wilton (rwilton) <[e-mail]>
> Cc: Martin Björklund <[e-mail]>se>; [e-mail]; [e-mail]; [e-mail]; Reshad Rahman <[e-mail]>
> Subject: Re: [yang-doctors] Dealing with BFD RFC 9127 client-cfg-parms for PIM, OSPF, ISIS and other BFD clients on some platforms
> 
> I spent some time talking to Mahesh this afternoon and think we’re in sync. 
> 
> Expect a complete diff from him soon. 
> 
> Jeff
> 
>> On Nov 10, 2021, at 4:42 PM, Rob Wilton (rwilton) <[e-mail]> wrote:
>> 
>> [Resending with Reshad's correct address]
>> 
>> Hi,
>> 
>> Thanks for the input so far.
>> 
>> Having chatted with Alvaro and John, I believe that we are looking for a solution such that (1) we know what is being done in RFC 9127bis, and (2) allows the Auth48 of the protocol drafts to complete so that they can be published.  I.e., it is okay to delay Auth48 by a couple of weeks so that we know exactly what changes need to be made to the modules in Auth48, but not to delay publishing of the protocol drafts until RFC 9217bis has gone through the process.
>> 
>> We would like to reach an agreement on what the plan/changes are no later than Nov 24th, sooner if possible.
>> 
>> My reading of the consensus so far so that it is acceptable to make non-backwards-compatible changes to RFC 9217bis, if necessary, but we should not make non-backwards-compatible changes without a good justification.
>> 
>> I think, if I understand the proposals correctly, that I'm leaning towards option (2) that Martin described below.
>> 
>> Regards,
>> Rob
>> 
>> 
>> -----Original Message-----
>> From: Martin Björklund <[e-mail]> 
>> Sent: 10 November 2021 15:26
>> To: [e-mail]
>> Cc: Rob Wilton (rwilton) <[e-mail]>om>; [e-mail]; [e-mail]; [e-mail]; [e-mail]
>> Subject: Re: [yang-doctors] Dealing with BFD RFC 9127 client-cfg-parms for PIM, OSPF, ISIS and other BFD clients on some platforms
>> 
>> Jeffrey Haas <[e-mail]> wrote:
>>>> On Wed, Nov 10, 2021 at 03:24:19PM +0100, Martin Björklund wrote:
>>>> I'm not ok with this violation in general, but I am ok with it in this
>>>> particular case.  Hence my questions.
>>> 
>>> Understood.
>>> 
>>>> If it turns out that in the end
>>>> you modify the AUTH48-docs and wait for the bis anyway, then I don't
>>>> think this is the right way to go.
>>> 
>>> So, your preference is "ship AUTH48 docs unchanged, even though it'd have a
>>> potentially redundant 'feature bfd'"?
>> 
>> Of course my preference is to not violate the upgrade rules, if
>> possible.
>> 
>> 1.  publish the auth48-docs now with redundant "bfd" feature
>> 2.  publish the auth48-docs now and remove the redundant "bfd" feature
>> 3.  remove the redundant "bfd" feature and wait for -bis
>> 
>> I am not sure I understand what the proposal is at this point (as I
>> understood it, your original proposal was (1), but also w/o "bfd" in
>> -bis).
>> 
>> With (2), the published docs won't be very useful until the -bis is
>> published, right?
>> 
>> In the case of (3), I think it is better to make a proper fix to -bis.
>> 
>> And in the case of (1), you could as well introduce redundant
>> "client-cfg-param" features (as I suggested earlier), and avoid the
>> proposed -bis YANG upgrade rule violation.
>> 
>> Anyway, if you still decide to go with (1) or (2), I am ok with the
>> proposed -bis.  (I prefer (2) over (1)).
>> 
>> 
>> 
>> /martin
>