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

[Gyan Mishra <[e-mail]>]

Hi Ketan

Welcome.  Responses in-line

Kind Regards

On Sun, Jan 30, 2022 at 12:34 PM Ketan Talaulikar <[e-mail]>
wrote:

> Hi Gyan,
>
> Thanks for your review and your comments/feedback. Please check inline
> below for responses.
>
>
> On Sun, Jan 30, 2022 at 12:29 PM Gyan Mishra <[e-mail]>
> wrote:
>
>>
>> I support WG Adoption of this draft.
>>
>> This is a real world problem that has existed with BFD that operators
>> have to deal with where OSPF adjacency comes up before BFD session
>> establishes resulting in cases where the link may have L1 issues or maybe a
>> dirty link or poor link quality resulting in BFD session establishment
>> followed by BFD immediately taking down the link.  With BFD tight timers
>> with client protocol registered ends up further exacerbating the issue with
>> link flaps resulting in IGP instability.
>>
>> This draft mirrors the ISIS block solution in RFC 6213   ISIS BFD enabled
>> TLV.
>>
>> This issue exists with BGP as well where the protocol registered with BFD
>> bootstrapped per RFC 5882 comes up before BFD resulting in instability.  I
>> believe this gap still exists for BGP.
>>
>
> KT> We have
> https://datatracker.ietf.org/doc/draft-ietf-idr-bgp-bfd-strict-mode/
>
>
Gyan> Understood to solve this issue for OSPF

>
>> When BFD comes up it performs link integrity test before session
>> establishment to detect dirty errored link does not come Up.
>>
>> RFC 5880 BFD 3-way session establishment and  does the link integrity and
>>  quality test by sending the BFD control packets to validate bi-directional
>> forwarding liveliness detection over any media.
>>
>> The case mentioned in this draft where the link is dirty, MTU issues or
>> forwarding plane issues exist that cause BFD not to establish resulting in
>> the use of default protocol timers and slow convergence is a major issue
>> for operators being solved with this draft as well as mentioned above where
>> BFD does come up after the IGP is just as bad if not worse if the link is a
>> dirty errored link resulting in flapping link.
>>
>> The main point here as I mentioned is that BFD must validate the link
>> integrity before routing protocol comes Up, so that routing protocol does
>> not come Up on a dirty errored link, so the blocking of the adjacency
>> capabilities solution here nicely solves the issue.
>>
>>
>> In this thread it has been mentioned maybe a CLI timer knob as far as
>> implementation for delay knob makes sense.
>>
>
> KT> Please check Sec 5. The terminology used might differ between
> implementations.
>

     Gyan> I see mention of BFD dampening for poor link quality issues.
However if BFD comes Up and establishes that would mean that at the time
the BFD session is established as control packet were received based on
interval and timer that the link is in a good state at the time of session
establishment. The main issue we are solving here is not allowing OSPF to
come Up on a link with packet forwarding issues. At that point when OSPF
FSM is initiated and goes to Full state we know the link to be stable as
BFD was established successfully prior.  If a link were in bad shape or
flapping BFD would not establish and that is the crux of this drafts
problem statement.  So I think to some degree this draft does preclude the
need for BFD dampening.


> I would like to note that one workaround used by operators is using RFC
>> 7130 BFD over bundle member called “BOB” or per link BFD,  and in that case
>> control protocol is in fact blocked and BFD comes up first.  This is a
>> workaround used putting even individual single links in a bundle to present
>> the issue from happening.
>>
>> I would like to note that RFC 5882 Generic Application of BFD does state
>> that if all neighbors support BFD then the registered control protocol
>> being bootstrapped should be blocked from coming up until BFD session is
>> established.  Only in case where all neighbors on a LAN do not have BFD
>> enabled, blocking the control protocol from coming Up would prevent the
>> control protocol from coming Up on neighbors that don’t have BFD enabled.
>>
>> So the way I read it implementations following BFD RFC 5882 should have
>> been blocking OSPF or ISIS  protocol from coming Up before BFD comes up w/o
>> having to require a specification for the explicit block.  Apparently most
>> all vendors implementations did not follow RFC 5882 it appears with this
>> regard and thus now the requirement for operators for this important
>> draft.  I think this implementation discrepancy happened due to normative
>> language SHOULD Block and not MUST Block is the problem.
>>
>
> KT> There are implementations that provided knobs for this strict
> mode-like behavior. The draft specifies the procedures for the same to be
> standardized for multi-vendor interop and more importantly the ability to
> signal/negotiate this mode of operation with neighbors.
>
>
    Gyan> It maybe good to reference RFC 5882 and state what the BFD
specification  says with regards to blocking IGP from coming up and that
this draft is following the specification that has been implemented by
other vendors and now making it standard for interoperability.

>
>> RFC 5882 excerpt below:
>>
>> 4.1 <https://datatracker.ietf.org/doc/html/rfc5882#section-4.1>.  Adjacency Establishment
>>
>>    If the session state on either the local or remote system (if known)
>>    is AdminDown, BFD has been administratively disabled, and the
>>    establishment of a control protocol adjacency MUST be allowed.
>>
>>    BFD sessions are typically bootstrapped by the control protocol,
>>    using the mechanism (discovery, configuration) used by the control
>>    protocol to find neighbors.  Note that it is possible in some failure
>>    scenarios for the network to be in a state such that the control
>>    protocol is capable of coming up, but the BFD session cannot be
>>    established, and, more particularly, data cannot be forwarded.  To
>>    avoid this situation, it would be beneficial not to allow the control
>>    protocol to establish a neighbor adjacency.  However, this would
>>    preclude the operation of the control protocol in an environment in
>>    which not all systems support BFD.
>>
>>
>>    Therefore, the establishment of control protocol adjacencies SHOULD
>>    be blocked if both systems are willing to establish a BFD session but
>>    a BFD session cannot be established.  One method for determining that
>>    both systems are willing to establish a BFD session is if the control
>>    protocol carries explicit signaling of this fact.  If there is no
>>    explicit signaling, the willingness to establish a BFD session may be
>>    determined by means outside the scope of this specification.
>>
>>    If it is believed that the neighboring system does not support BFD,
>>    the establishment of a control protocol adjacency SHOULD NOT be
>>    blocked.
>>
>>
>>
>> Few comments on the draft below:
>>
>> Bottom of Introduction
>>
>>
>>
>>    This document specifies the OSPF protocol extensions using link-local
>>    signaling (LLS) [RFC5613 <https://datatracker.ietf.org/doc/html/rfc5613>] for a router to indicate to its neighbor
>>    the willingness to establish its adjacency using the strict-mode for
>>    BFD.  It also introduces an extension for OSPFv3 link-local signaling
>>    of the interface IPv4 address when used for an IPv4 address-family
>>    (AF) instance to enable discovery of the IPv4 addresses for BFD
>>    session setup.
>>
>>
>> Gyan> Could you also introduce extension for IPV6 AF for discovery of IPv6 address?
>>
>>
> KT> That is not required since we have the IPv6 link-local address that is
> available for use.
>
>
     Gyan> RFC 5613 LLS data block only applies to IPv4 and not IPv6 for
OSPFV3, Understood.   OSPFV3 has the Link Local LSA to signal the B bit to
block the adjacency from forming so would you still need that B flag update
to the Link Local LSA to get tbt same IPv4 LLS data block functionality

>
>> Section 3 Local Interface IPv4 address TLV
>>
>>
>> Gyan> Should we also have a LLS Data block B bit section for Local Interface IPv6 address TLV
>>
>>
> KT> This is not required since the adjacency is either for IPv4 or IPv6 in
> the case of OSPF in separate protocol instances and not a single adjacency
> like in the case of ISIS.
>

    Gyan> Understood.  OSPF would have separate v4 and v6 adjacency where
ISIS MT single adjacency.   I understand for OSPFv3 IPv4 AFI we need the
IPv4 address  TLV for discovery of neighbor IPv4 address which is not
needed for IPv6 since we have link local address and link local LSA for the
discovery.  I am still trying to understand how the LLS signaling of the B
bit would happen for OSPF IPv6 Address family using OSPFV3 or OSPFv3
address family instance RFC 5838.  Let’s say the interface is not dual
stacked and it’s IPv6 only how would you block the adjacency from forming?

>
>
>> Section 4 Procedure
>>
>>
>>       In this state, a Hello packet has recently been received from the
>>       neighbor.  However, bidirectional communication has not yet been
>>       established with the neighbor (i.e., the router itself did not
>>       appear in the neighbor's Hello packet).  BFD session establishment
>>       with the neighbor is requested, if not already completed (e.g., in
>>       the event of transition from 2-way state).  Neighbors in Init
>>       state or higher will be listed in the Hello packets associated
>>       with the interface if they either have a corresponding BFD session
>>       established or have not advertised strict-mode for BFD in the
>>       Hello packet LLS Extended Options and Flags.
>>
>>
>> Gyan> What do you mean by “ e.g., in the event of transition from 2-way state)
>>
>>
> KT> We can have OSPF neighbor FSM state transition from 2-way (or greater)
> to Init state. In those cases, a BFD session may be already established or
> requested and hence does not need to be initiated. You can put this into
> the entire neighbor FSM of RFC2328 to get a full picture.
>

   Gyan> The verbiage seems very loose that it’s not clearly saying that
BFD MUST be established before OSPF FSM is initiated. So you are saying
that when BFD session is requested so has not even started or the request
has completed which the way it’s worded the BFD session is clearly not
established and at the same time - in the event of ospf transition from
 2-way state to init or Full.  Which one.  Also if the LLS B bit is set my
understanding is OSPF has not even started and only after BFD is
established and the B bit is clear would OSPF initiate.

>
>
>>
>> I would think OSPF is blocked and so then after BFD is established then
>> OSPF initialized but this sounds like OSPF maybe in two way state when BFD
>> establishes which means OSPF is not blocked from forming adjacency.
>> Confusing.
>>
>> So this would be a LAN mix mode where not all nodes have BFD enabled
>> maybe want to mention to make it clear.
>>
>>
>>    An implementation MUST NOT wait for BFD session establishment in Init
>>    state unless strict-mode for BFD is enabled on the router and the
>>    specific neighbor indicates strict-mode for BFD capability via its
>>    Hello LLS options.  When BFD is enabled, but the strict-mode for
>>    operation has not be signaled by both neighbors, then an
>>    implementation SHOULD start the BFD session establishment only in
>>    2-Way state or higher state.  This makes it possible for an OSPF
>>    router to support BFD operation in both strict-mode and normal mode
>>    across different interfaces or even different neighbors on the same
>>    multi-access interface.
>>
>>
>> Gyan> So in the LAN case RFC 5882 OSPF should not be blocked with LLS data block.
>>
>>
> KT> We need to be able to interop and be backward compatible. That is the
> main motivation. Normally, when all routers on a LAN support this spec,
> they would all likely do strict-mode and not a mix.
>
>

Gyan> The main motivation is to fix the problem with OSPF starting before
BFD to be implemented so that there is backwards compatibility.    I think
you should break out scenarios into P2P and LAN scenario.  This is how I
would reword.

   For Multi-access interfaces when BFD is enabled, but the strict-mode for
   operation has been signaled by multiple but not all neighbors, then an
   implementation SHOULD start the BFD session establishment only in
   2-Way state or higher state.  This makes it possible for an OSPF
   router to support BFD operation in both strict-mode and normal mode
   across different interfaces or even different neighbors.



   For interface with P2P subnet when BFD is enabled, but strict-mode for
   operation has been signaled by both neighbors, then an
   implementation SHOULD start the BFD session establishment at init state.

   In case one end of P2P link supports Strict mode and the other neighbor

   does not then BFD would come up in Normal mode.




>> So I think that is what you are trying to say that BFD can come up after OSPF is Up
>>
>> I see you mention 2-way but not fully Up.
>>
>>
> KT> Full state comes after 2-way.
>
>
>>  How would you stagger it allow BFD to come up
>>
>> in parallel to ospf still coming to Full state.
>>
>>
> KT> I am not sure if I follow this question. In the non-strict mode of
> operation, the OSPF adjacency can progress to its terminal state (e.g.
> full) without any dependence on the BFD session establishment.
>
>
    Gyan> This was related to the interoperability with devices not
supporting on LAN with mix of devices.  I think if we reword as I stated
above specifying P2P and LAN scenario that would make it clearer.

>
>>
>> Nit
>>
>>
>>
>> OLD
>>
>>
>>    When BFD is enabled on an interface over which we already have an
>>    existing OSPF adjacency, it would result in the router setting the
>>    B-bit in its subsequent Hello packets.  If the adjacency is already
>>    up (i.e., in its terminal state of Full or 2-way with non-DR routers
>>    on a multi-access interface) with a neighbor that also supports
>>    strict-mode for BFD, then an implementation SHOULD NOT bring this
>>
>>
>>
>> Gyan> 2-way is not terminal state even for DROther routers
>>
>
> KT> We are talking about the Neighbor FSM State here.
>
>
    Gyan> Yes.  The verbiage is not clear.  Non DR is technically called
DROther router I believe.  Also the DROther router would be in Full state
and not 2-way, correct?

>
>> NEW
>>
>>    When BFD is enabled on an interface over which we already have an
>>    existing OSPF adjacency, it would result in the router setting the
>>    B-bit in its subsequent Hello packets.  If the adjacency is already
>>    up (i.e., in its terminal state of Full/DR Full/BDR or Full/DROther routers
>>    on a multi-access interface) with a neighbor that also supports
>>    strict-mode for BFD, then an implementation SHOULD NOT bring this
>>
>>
>>
>> Section 4.1 OSPFv3 IPv4 address family specifics
>>
>> Gyan> Why would you not have also OSPFV3 IPv6 address family specifics
>>
>
> KT> Could you please check RFC5838 to know more about multi-AF operations
> for OSPFv3?
>

    Gyan>  I understand OSPFv3 MI separate control plane and data plane
separate v4 and v6 adjacency I would think that as we have link local
address and link local local LSA we need to still set the B bit flag to
block the adjacency from forming for v6 control plane.   Imagine if no v4
and v6 congruency and v6 had to signal the B bit as we cannot rely on v4
instance for v6 adjacency since it’s separate adjacencies.  Also for IPv6
only scenario as well now you have to signal the B bit somehow so that flag
needs to be specified in the specification.

>
> Thanks,
> Ketan
>
>
>>
>> Kind Regards
>>
>> Gyan
>>
>> On Sat, Jan 29, 2022 at 9:28 PM Aijun Wang <[e-mail]>
>> wrote:
>>
>>> Hi, Acee and Ketan:
>>> No, I don’t want to change the NBMA/Broadcast in OSPF to P2MP mode.
>>> What I want to express is that you brought up the full mesh BFD sessions
>>> among the routers within such network type. Is it necessary to bring some
>>> of them(the BFD sessions between DRothers) to DOWN after the OSPF adjacency
>>> are established between the DRother and DR/BDR router?
>>> If the BFD session is bootstrapped after the OSPF adjacency is
>>> established, there will be no such extra/useless BFD sessions
>>>
>>> Aijun Wang
>>> China Telecom
>>>
>>> On Jan 30, 2022, at 02:45, Acee Lindem (acee) <[e-mail]> wrote:
>>>
>>> 
>>>
>>> Speaking as WG member:
>>>
>>>
>>>
>>> Hi Aijun,
>>>
>>> If you want a per-neighbor state and route, you have to use P2MP. This
>>> scope of this draft isn’t to try and make NBMA/Broadcast model something
>>> that it is not. This is should be common knowledge and the draft needn’t
>>> address it. Those of us who remember ATM emulated LANs (which were not
>>> always symmetrically reliable) will recall using P2MP on an inherently
>>> multi-access network.
>>>
>>> Acee
>>>
>>>
>>>
>>> *From: *Aijun Wang <[e-mail]>
>>> *Date: *Saturday, January 29, 2022 at 3:46 AM
>>> *To: *'Ketan Talaulikar' <[e-mail]>
>>> *Cc: *"[e-mail]" <[e-mail]>, "
>>> [e-mail]" <
>>> [e-mail]>, 'Albert Fu' <
>>> [e-mail]>, Acee Lindem <[e-mail]>
>>> *Subject: *RE: [Lsr] Working Group Last Call for "OSPF Strict-Mode for
>>> BFD" - draft-ietf-lsr-ospf-bfd-strict-mode-04
>>>
>>>
>>>
>>> Hi, Ketan:
>>>
>>> OK, then back to my original question:
>>>
>>> If one of the BFD session(between DRothers) is DOWN, will it bring DOWN
>>> the OSPF adjacency(between the DRother and DR/BDR)?
>>>
>>> If not, then the traffic between these DRothers will be lost; If yes, it
>>> seems strange, because the BFD session between the DRother and DR/BDR may
>>> be still UP.
>>>
>>> I think here there are some mismatch between the BFD sessions and the
>>> OSPF adjacency in Broadcast/NBMA network, then some clarification for the
>>> procedures are needed.
>>>
>>>
>>>
>>>
>>>
>>> Best Regards
>>>
>>>
>>>
>>> Aijun Wang
>>>
>>> China Telecom
>>>
>>>
>>>
>>> *From:* [e-mail] <[e-mail]> *On Behalf Of *Ketan
>>> Talaulikar
>>> *Sent:* Saturday, January 29, 2022 4:22 PM
>>> *To:* Aijun Wang <[e-mail]>
>>> *Cc:* [e-mail]; [e-mail];
>>> Albert Fu <[e-mail]>; Acee Lindem (acee) <acee=
>>> [e-mail]>
>>> *Subject:* Re: [Lsr] Working Group Last Call for "OSPF Strict-Mode for
>>> BFD" - draft-ietf-lsr-ospf-bfd-strict-mode-04
>>>
>>>
>>>
>>> Hi Aijun,
>>>
>>>
>>>
>>> The choice of the term "adjacency" was not accurate in my previous
>>> response to you. I meant "neighborship".
>>>
>>>
>>>
>>> That said, the substance of my response still remains the same.
>>>
>>>
>>>
>>> Thanks,
>>>
>>> Ketan
>>>
>>>
>>>
>>>
>>>
>>> On Sat, Jan 29, 2022 at 1:42 PM Aijun Wang <[e-mail]>
>>> wrote:
>>>
>>> Hi, Ketan:
>>>
>>>     For the Broadcast/NMBA network type, if you establish BFD sessions
>>> before the DR/BDR selection, then there will be full mesh BFD sessions
>>> within the routers on such media type?
>>>
>>> Instead of establishing the BFD sessions with DR/BDR only, the same as
>>> the OSPF adjacency relationship? If so, if one of the BFD session that not
>>> with the DR/BDR is DOWN, what’s the action then?
>>>
>>>
>>>
>>> KT> I think there is perhaps a misunderstanding of the purpose of BFD
>>> use with OSPF. Perhaps a careful reading of RFC5882 would help? In short,
>>> BFD is used to verify bidirectional connectivity between neighbors to
>>> ensure data may be forwarded between them. OSPF adjacency is built between
>>> every router in a LAN since they can directly forward packets between
>>> themselves.
>>>
>>> *[WAJ] In Broadcast/NBMA network, OSPF adjacency is built only between
>>> the routers and DR/BDR.  *
>>>
>>>
>>>
>>> Thanks,
>>>
>>> Ketan
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> Best Regards
>>>
>>>
>>>
>>> Aijun Wang
>>>
>>> China Telecom
>>>
>>>
>>>
>>> *From:* Ketan Talaulikar <[e-mail]>
>>> *Sent:* Saturday, January 29, 2022 11:13 AM
>>> *To:* Aijun Wang <[e-mail]>
>>> *Cc:* Acee Lindem (acee) <acee=[e-mail]>; [e-mail];
>>> [e-mail]; Albert Fu <
>>> [e-mail]>
>>> *Subject:* Re: [Lsr] Working Group Last Call for "OSPF Strict-Mode for
>>> BFD" - draft-ietf-lsr-ospf-bfd-strict-mode-04
>>>
>>>
>>>
>>> Hi Aijun,
>>>
>>>
>>>
>>> Please check inline below.
>>>
>>>
>>>
>>>
>>>
>>> On Sat, Jan 29, 2022 at 7:38 AM Aijun Wang <[e-mail]>
>>> wrote:
>>>
>>> Hi, Acee:
>>>
>>>
>>>
>>> Yes. Then I think the sentence in
>>> https://datatracker.ietf.org/doc/html/draft-ietf-lsr-ospf-bfd-strict-mode#section-2
>>> as the following should be relaxed:
>>>
>>> “A router MUST include the LLS block with the LLS Type 1 Extended
>>>
>>>    Options and Flags TLV with the B-bit set in its Hello and DD packets
>>>
>>>    when strict-mode for BFD is enabled on the link.”
>>>
>>> It seems that there is no use for such information being included in the
>>> DD packets.
>>>
>>>
>>>
>>> KT> Since LLS is present in both Hello and DD packets, not including the
>>> B bit in DD packets will result in a different LLS options being seen in
>>> Hello and DD. This can trigger the change in LLS option logic
>>> unnecessarily. Hence, to keep things simple and consistent (and this should
>>> be for technically all LLS options), it makes sense to include them in both
>>> Hello and DD packets.
>>>
>>>
>>>
>>>
>>>
>>> And, one more question to the Authors of this draft:
>>>
>>> What’s the procedures for the interaction of BFD session and OSPF
>>> adjacency establishment in the Broadcast/NBMA network type interface, which
>>> is involved the DR/BDR election procedures?  The BFD session establishment
>>> should be after the DR/BDR election?
>>>
>>> Should the procedures in section 4 be updated to cover such scenario?
>>>
>>>
>>>
>>> KT> The procedures in Sec 4 update the transition to INIT state in the
>>> OSPF Neighbor FSM. This happens before DR election and is independent of
>>> the type of network/link - applies also to Broadcast/NMBA. The main goal of
>>> this proposal is to first verify BFD session establishment and only then
>>> trigger OSPF adjacency procedures. Doing DR election before BFD session
>>> does not serve the purpose.
>>>
>>>
>>>
>>> Thanks,
>>>
>>> Ketan
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> Best Regards
>>>
>>>
>>>
>>> Aijun Wang
>>>
>>> China Telecom
>>>
>>>
>>>
>>> *From:* [e-mail] <[e-mail]> *On Behalf Of *Acee
>>> Lindem (acee)
>>> *Sent:* Friday, January 28, 2022 8:30 PM
>>> *To:* Aijun Wang <[e-mail]>; 'Ketan Talaulikar' <
>>> [e-mail]>
>>> *Cc:* [e-mail]; [e-mail];
>>> 'Albert Fu' <[e-mail]>
>>> *Subject:* Re: [Lsr] Working Group Last Call for "OSPF Strict-Mode for
>>> BFD" - draft-ietf-lsr-ospf-bfd-strict-mode-04
>>>
>>>
>>>
>>> Hi Aijun,
>>>
>>>
>>>
>>> *From: *Aijun Wang <[e-mail]>
>>> *Date: *Friday, January 28, 2022 at 1:41 AM
>>> *To: *'Ketan Talaulikar' <[e-mail]>
>>> *Cc: *"[e-mail]" <[e-mail]>, "
>>> [e-mail]" <
>>> [e-mail]>, Acee Lindem <
>>> [e-mail]>, 'Albert Fu' <[e-mail]>
>>> *Subject: *RE: [Lsr] Working Group Last Call for "OSPF Strict-Mode for
>>> BFD" - draft-ietf-lsr-ospf-bfd-strict-mode-04
>>>
>>>
>>>
>>> Hi, Ketan:
>>>
>>>
>>>
>>> I know. According to the description of RFC 5613, the LLS Data Block is
>>> only attached at the OSPF hello and DD packets.
>>>
>>>
>>>
>>> If you read section 4 of the draft, you’ll see that the strict mode
>>> behavior is based on the LLS block in OSPF Hello packets.
>>>
>>>
>>>
>>> Thanks,
>>> Acee
>>>
>>>
>>>
>>>
>>>
>>> *From:* [e-mail] <[e-mail]> *On Behalf Of *Aijun
>>> Wang
>>> *Sent:* Friday, January 28, 2022 2:02 PM
>>> *To:* 'Ketan Talaulikar' <[e-mail]>
>>> *Cc:* [e-mail]; [e-mail]; 'Acee
>>> Lindem (acee)' <[e-mail]>; 'Albert Fu' <[e-mail]>
>>> *Subject:* Re: [Lsr] Working Group Last Call for "OSPF Strict-Mode for
>>> BFD" - draft-ietf-lsr-ospf-bfd-strict-mode-04
>>>
>>>
>>>
>>> Hi, Ketan:
>>>
>>> What I want to know is that where to encapsulate the LLS Data Block if
>>> the router uses OSPFv3 Extended LSAs to establish the adjacency?
>>>
>>>
>>>
>>> Best Regards
>>>
>>>
>>>
>>> Aijun Wang
>>>
>>> China Telecom
>>>
>>>
>>>
>>> *From:* [e-mail] <[e-mail]> *On Behalf Of *Ketan
>>> Talaulikar
>>> *Sent:* Friday, January 28, 2022 12:56 PM
>>> *To:* Aijun Wang <[e-mail]>
>>> *Cc:* [e-mail]; [e-mail]; Acee
>>> Lindem (acee) <[e-mail]>; Albert Fu <[e-mail]>
>>> *Subject:* Re: [Lsr] Working Group Last Call for "OSPF Strict-Mode for
>>> BFD" - draft-ietf-lsr-ospf-bfd-strict-mode-04
>>>
>>>
>>>
>>> Hi Aijun,
>>>
>>>
>>>
>>> This document proposes changes to the adjacency establishment procedures
>>> and the use of LLS for negotiations. As such, it is independent of OSPFv3
>>> Extended LSAs. Please let us know if you believe otherwise.
>>>
>>>
>>>
>>> Thanks,
>>>
>>> Ketan
>>>
>>>
>>>
>>>
>>>
>>> On Fri, Jan 28, 2022 at 8:29 AM Aijun Wang <[e-mail]>
>>> wrote:
>>>
>>> Hi, Albert:
>>>
>>>
>>>
>>> Want to how to accomplish this aim when router conforms to RFC8362?
>>>
>>>
>>>
>>>
>>>
>>> Best Regards
>>>
>>>
>>>
>>> Aijun Wang
>>>
>>> China Telecom
>>>
>>>
>>>
>>> *From:* [e-mail] <[e-mail]> *On Behalf Of *Albert
>>> Fu (BLOOMBERG/ 120 PARK)
>>> *Sent:* Friday, January 28, 2022 4:25 AM
>>> *To:* [e-mail]; [e-mail]
>>> *Cc:* [e-mail]
>>> *Subject:* Re: [Lsr] Working Group Last Call for "OSPF Strict-Mode for
>>> BFD" - draft-ietf-lsr-ospf-bfd-strict-mode-04
>>>
>>>
>>>
>>>
>>>
>>> I support this draft, as one of the authors, as well as a BFD user, and
>>> hope it becomes a standard.
>>>
>>>
>>>
>>> This draft addresses an issue that we have encountered in our production
>>> network, hence we have been actively working with our vendors.
>>>
>>>
>>>
>>> Most people deploy BFD with OSPF (or any routing protocols) to enable
>>> fast failure detection. This is to ensure that routing/forwarding path is
>>> diverted as soon as a connectivity issue is detected.
>>>
>>>
>>>
>>> OSPF BFD strict mode ensures this, in that it requires that the BFD
>>> session to be established before OSPF adjacency will be allowed to be
>>> established, thus ensuring that routing/forwarding will not use the path
>>> without a working BFD adjacency.
>>>
>>>
>>>
>>> Without this standard, as per most current default OSPF BFD deployment,
>>> OSPF adjacency is established without BFD. OSPF adjacency then triggers the
>>> BFD session to be established. If a "break-in-middle" issue occurred (where
>>> last mile interface status remains up) before BFD session comes up, we
>>> would lose the fast failure detection capability. This situation will
>>> require lengthy OSPF protocol timeout to detect such failure, resulting in
>>> traffic being black-holed for extended period.
>>>
>>>
>>>
>>> We have a large network consisting of several thousand links throughout
>>> the world, and have seen this issue several times that had impacted
>>> production traffic negatively.
>>>
>>>
>>>
>>> As mentioned in a previous email, we have successfully tested this
>>> feature on the Juniper MX (JUNOS 19.4) and also Cisco ASR9k (XR 7.3.2)
>>> platforms.
>>>
>>>
>>>
>>> Thanks
>>>
>>> Albert Fu
>>>
>>> Bloomberg
>>>
>>>
>>>
>>> From: [e-mail] At: 01/27/22 12:08:36 UTC-5:00
>>>
>>> To: [e-mail]
>>> Cc: [e-mail]
>>> Subject: Working Group Last Call for "OSPF Strict-Mode for BFD" -
>>> draft-ietf-lsr-ospf-bfd-strict-mode-04
>>>
>>>
>>>
>>> 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 11
>>> th, 20222. Also, review comments are certainly welcome.
>>>
>>> Thanks,
>>> Acee
>>>
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> Lsr mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/lsr
>>>
>>> _______________________________________________
>>> Lsr mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/lsr
>>>
>> --
>>
>> <http://www.verizon.com/>
>>
>> *Gyan Mishra*
>>
>> *Network Solutions A**rchitect *
>>
>> *Email [e-mail] <[e-mail]>*
>>
>>
>>
>> *M 301 502-1347*
>>
>> --

<http://www.verizon.com/>

*Gyan Mishra*

*Network Solutions A**rchitect *

*Email [e-mail] <[e-mail]>*



*M 301 502-1347*