Subject: Re: [Lsr] Working Group Last Call for "OSPF Strict-Mode for BFD" - draft-ietf-lsr-ospf-bfd-strict-mode-04

From: "Albert Fu (BLOOMBERG/ 120 PARK)" <[email-masked]>
Date: Wed, 9 Feb 2022 13:11:16 -0000

Hi Muthu,

We don't use virtual-links nor unnumbered links in our network.

I checked the Junos and XR codes on our lab routers. I found that both do not support BFD over virtual-link. I believe virtual-link is not common, that might explain the lack of feature support.

I did test OSPF BFD Strict mode for unnumbered link between Junos and XR. It work as per this draft, in that BFD must be operational before OSPF is allowed to come up. (* btw, you need to configure the hidden knob "backward-compatible-unnumbered-mask" on Junos router in order to interop OSPF unnumbered link with Cisco *).

Thanks
Albert

From: [email-masked] At: 02/08/22 09:44:32 UTC-5:00To:  Albert Fu (BLOOMBERG/ 120 PARK ) ,  [email-masked]
Cc:  acee=[email-masked],  [email-masked],  [email-masked]
Subject: Re: [Lsr] Working Group Last Call for "OSPF Strict-Mode for BFD" - draft-ietf-lsr-ospf-bfd-strict-mode-04

Hi Muthu,

I don't have the data for BFD strict-mode interop over virtual links. However, p2p unnumbered is commonly deployed and I'll let my co-author clarify on interop.

Thanks,
Ketan

On Fri, Feb 4, 2022 at 10:52 PM Muthu Arul Mozhi Perumal <[email-masked]> wrote:

Hi Ketan,

Sure, looking forward to the clarification in the draft on multi-hop BFD..

Just curious, are there interoperable implementations for OSPF multi-hop BFD strict mode for virtual links or p2p unnumbered interfaces?

Regards,
Muthu

On Fri, Feb 4, 2022 at 5:36 PM Ketan Talaulikar <[email-masked]> wrote:

Hi Muthu,

When we say a "link" here, it is in the context of the OSPF interface and neighbor FSM. My understanding is that this term includes virtual links as well. As such, we can add some text in the introduction section to clarify the same and also put a reference to RFC5883 for BFD multi-hop use for VLINKs.

I hope that works for you.

Thanks,
Ketan

On Wed, Feb 2, 2022 at 11:05 AM Muthu Arul Mozhi Perumal <[email-masked]> wrote:

Hi Ketan,

Thanks for your response..

The draft says:
<snip>
   This document defines the B-bit in the LLS Type 1 Extended Options
   and Flags field.  This bit is defined for the LLS block included in
   Hello and Database Description (DD) packets and indicates that BFD is
   enabled on the link and that the router requests strict-mode for BFD.
</smip>

You don't enable multi-hop BFD on a link, instead you enable it b/w two (multi-hop) routers, right?

How about replacing it with:
indicates that (1) single-hop BFD [RFC5881] is enabled on the link in case of point-to-point (numbered) and LAN interfaces, and (2) multi-hop BFD [RFC5883] is enabled between the neighbors in case of virtual links and point-to-point unnumbered interfaces.  

Also, add a note at the beginning of the draft that BFD refers to both single-hop and multi-hop BFD when not explicitly specified..
  
Regards,
Muthu
On Sun, Jan 30, 2022 at 10:40 PM Ketan Talaulikar <[email-masked]> wrote:

Hi Muthu,

Thanks for your review and your support.

Regarding your question, I would like to clarify that this document doesn't specify BFD operations with OSPF. That was done by RFC5882. Indeed for virtual links, there would need to be a BFD multi-hop session and the same would apply to p-t-p unnumbered. 

However, I am not sure what specific applicability or operations need to be called out for Strict Mode of operations for those links.

Thanks,
Ketan

On Sun, Jan 30, 2022 at 12:52 PM Muthu Arul Mozhi Perumal <[email-masked]> wrote:

Hi,

I support the draft. A quick question:
Should it describe the applicability of the mechanism over OSPF virtual links and unnumbered interfaces? With virtual links, one would have to establish a multi-hop BFD session, so it is slightly different from a BFD operational standpoint. For e.g, capability to support single-hop BFD may not translate to the capability to support multi-hop BFD..

Regards,
Muthu
On Thu, Jan 27, 2022 at 10:38 PM Acee Lindem (acee) <acee=[email-masked]> wrote:

LSR WG,  
  
This begins a two week last call for the subject draft. Please indicate your support or objection on this list prior to 12:00 AM UTC on February 11th, 20222. Also, review comments are certainly  welcome. 
Thanks,
Acee 
   _______________________________________________
Lsr mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/lsr

---

From: Muthu Arul Mozhi Perumal <[email-masked]>
Date: Wed, 9 Feb 2022 19:40:30 +0530

Thanks Albert..this is a useful piece of information.

Regards,
Muthu

On Wed, Feb 9, 2022 at 6:41 PM Albert Fu (BLOOMBERG/ 120 PARK) <
[email-masked]> wrote:

> I checked the Junos and XR codes on our lab routers. I found that both do
> not support BFD over virtual-link. I believe virtual-link is not common,
> that might explain the lack of feature support.
>
> I did test OSPF BFD Strict mode for unnumbered link between Junos and XR.
> It work as per this draft, in that BFD must be operational before OSPF is
> allowed to come up. (* btw, you need to configure the hidden knob
> "backward-compatible-unnumbered-mask" on Junos router in order to interop
> OSPF unnumbered link with Cisco *).
>
> Thanks
> Albert
>
> From: [email-masked] At: 02/08/22 09:44:32 UTC-5:00
> To: Albert Fu (BLOOMBERG/ 120 PARK ) <[email-masked]>,
> [email-masked]
> Cc: acee=[email-masked], [email-masked],
> [email-masked]
> I don't have the data for BFD strict-mode interop over virtual links.
> However, p2p unnumbered is commonly deployed and I'll let my co-author
> clarify on interop.
>
> Thanks,
> Ketan
>
>
>> Just curious, are there interoperable implementations for OSPF multi-hop
>> BFD strict mode for virtual links or p2p unnumbered interfaces?
>>
>> Regards,
>> Muthu
>>
>>> When we say a "link" here, it is in the context of the OSPF interface
>>> and neighbor FSM. My understanding is that this term includes virtual links
>>> as well. As such, we can add some text in the introduction section to
>>> clarify the same and also put a reference to RFC5883 for BFD multi-hop use
>>> for VLINKs.
>>>
>>>>    Hello and Database Description (DD) packets and
>>>> *indicates that BFD is   enabled on the link* and that the router
>>>> requests strict-mode for BFD.
>>>> </smip>
>>>>
>>>> indicates that (1) single-hop BFD [RFC5881] is enabled on the link in
>>>> case of point-to-point (numbered) and LAN interfaces, and (2) multi-hop BFD
>>>> [RFC5883] is enabled between the neighbors in case of virtual links and
>>>> point-to-point unnumbered interfaces.
>>>>
>>>> Also, add a note at the beginning of the draft that BFD refers to both
>>>> single-hop and multi-hop BFD when not explicitly specified..
>>>>
>>>> Regards,
>>>> Muthu
>>>>
>>>>> Regarding your question, I would like to clarify that this document
>>>>> doesn't specify BFD operations with OSPF. That was done by RFC5882. Indeed
>>>>> for virtual links, there would need to be a BFD multi-hop session and the
>>>>> same would apply to p-t-p unnumbered.
>>>>>
>>>>> However, I am not sure what specific applicability or operations need
>>>>> to be called out for Strict Mode of operations for those links.
>>>>>
>>>>> Thanks,
>>>>> Ketan
>>>>>
>>>>>
>>>>>> Should it describe the applicability of the mechanism over OSPF
>>>>>> virtual links and unnumbered interfaces? With virtual links, one would have
>>>>>> to establish a multi-hop BFD session, so it is slightly different from a
>>>>>> BFD operational standpoint. For e.g, capability to support single-hop BFD
>>>>>> may not translate to the capability to support multi-hop BFD..
>>>>>>
>>>>>> Regards,
>>>>>> Muthu
>>>>>>
>>>>>>> This begins a two week last call for the subject draft. Please
>>>>>>> indicate your support or objection on this list prior to 12:00 AM UTC on
>>>>>>> February 11th, 20222. Also, review comments are certainly welcome.
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Acee
>>>>>>>
>>>>>>>