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  Kethan

Thank you for answering all my questions. I am all set.

Responses in-line

Kind Regards

Gyan
On Sun, Jan 30, 2022 at 11:48 PM Ketan Talaulikar <[e-mail]>
wrote:

> Hi Gyan,
>
> Please check inline with KT2.
>
>
> On Mon, Jan 31, 2022 at 1:20 AM Gyan Mishra <[e-mail]> wrote:
>
>> Hi Ketan
>>
>> Welcome.  Responses in-line Gyan2
>>
>> 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.
>>
>
> KT2> Ack. We will add text for do this in the Introduction section.
>

    Gyan2>  Excellent!  Thank you

>
>
>>
>>>> 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
>>
>
> KT2> LLS is for both OSPFv2 and OSPFv3. The B-bit is common and available
> for OSPFv3 protocol instances both IPv4 and IPv6.
>

   Gyan2> Ack.  Makes sense

>
>
>>
>>>> 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?
>>
>
> KT2> I hope the response to your previous comment clarifies this.
>
>
     Gyan2> Yes it does, Thanks

>
>>>
>>>> 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.
>>
>
> KT2> I am not sure if I follow. This document specifies the change in the
> OSPF Neighbor FSM and it is assumed that the reader understands that well.
> We are not going to describe state transitions into and out of Init state.
> In short, BFD session establishment for a neighbor is triggered when it
> starts in the Init state and the FSM is not allowed to progress further
> into the 2way state until the BFD session is established.
>
>
    Gyan2> Ack.  Thank you for explaining

>
>>>
>>>>
>>>> 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.
>>
>
> KT2> I am not sure what text and in which section you are suggesting to be
> reworded. I do not see the difference in the behavior based on the type of
> link when it comes to BFD strict mode.
>

    Gyan2> Below verbiage is reword of section 4 6th paragraph.

Here is the original text

       “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.”





>
>>
>>    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?
>>
>
> KT2> This document is talking of OSPF Neighbor FSM state. I don't see the
> need to discuss DR-Other or such terminologies in this document.
>

    Gyan2> Ack

>
>
>>
>>>> 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.
>>
>
> KT2> I hope my response to a previous comment clarifies this.
>

     Gyan2> Yes it does, Thanks

>
> Thanks,
> Ketan
>
>
>
>>
>>> 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 11th, 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*
>>
>> --

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

*Gyan Mishra*

*Network Solutions A**rchitect *

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



*M 301 502-1347*