Ahh ok .. this is "OSPF virtual link" not an emulated "virtual link" seen
as p2p to any routing protocol.
Thx,
R.
On Fri, Feb 4, 2022 at 7:14 PM Acee Lindem (acee) wrote:
> Hi Robert,
>
> There is no tunnel for an OSPF virtual link, the transit area will require
> leaking of backbone routes
Hi Robert,
There is no tunnel for an OSPF virtual link, the transit area will require
leaking of backbone routes without summarization. Also note that the virtual
link endpoint could be reachable in the transit area but may not be up.
Multi-hop BFD would still be useful for a virtual link.
Muthu,
If you are using virtual link why is this still multihop BFD ?
Thx,
R.
On Fri, Feb 4, 2022 at 6:22 PM Muthu Arul Mozhi Perumal <
muthu.a...@gmail.com> wrote:
> Hi Ketan,
>
> Sure, looking forward to the clarification in the draft on multi-hop BFD..
>
> Just curious, are there
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
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
On Thu, Feb 3, 2022 at 10:14 PM Acee Lindem (acee) wrote:
> Hi Ketan,
>
> Do you remember who this comment came from? I definitely think anyone who
> reads the abstract of the draft wouldn’t be confused and don’t agree with
> the comment.
>
>
>
> Also, this is meant to be a per-interface
