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

[Muthu Arul Mozhi Perumal]

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)  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 11
> th, 20222. Also, review comments are certainly welcome.
>
> Thanks,
> Acee
>
>
> ___
> Lsr mailing list
> Lsr@ietf.org
> https://www.ietf.org/mailman/listinfo/lsr
>
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

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

[Gyan Mishra]

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.

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.

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.

RFC 5882 excerpt below:

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

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

[Aijun Wang]

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)  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 
> Date: Saturday, January 29, 2022 at 3:46 AM
> To: 'Ketan Talaulikar' 
> Cc: "lsr@ietf.org" , 
> "draft-ietf-lsr-ospf-bfd-strict-m...@ietf.org" 
> , 'Albert Fu' 
> , Acee Lindem 
> 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: lsr-boun...@ietf.org  On Behalf Of Ketan 
> Talaulikar
> Sent: Saturday, January 29, 2022 4:22 PM
> To: Aijun Wang 
> Cc: lsr@ietf.org; draft-ietf-lsr-ospf-bfd-strict-m...@ietf.org; Albert Fu 
> ; Acee Lindem (acee) 
> 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  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  
> Sent: Saturday, January 29, 2022 11:13 AM
> To: Aijun Wang 
> Cc: Acee Lindem (acee) ; lsr@ietf.org; 
> draft-ietf-lsr-ospf-bfd-strict-m...@ietf.org; Albert Fu 
> 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  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 
> 

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

[Robert Raszuk]

Hi Les,

That timer and its consistency on both ends clearly belongs to OSPF not to
> BFD.
>


> *[LES:] I disagree. The definition of UP state belongs to the BFD
> protocol/implementation.*
>
> *If you don’t want BFD clients (like OSPF) to react “too quickly” then
> build additional config/logic into your BFD implementation so it does not
> signal UP state before additional criteria is met – do not make each BFD
> client (and there could be multiple for a given session) configure its own
> definition of BFD UP.*
>

I think we are looking at this from different perspectives.

I am saying bring BFD UP and allow X seconds/minutes/hours to run a
sequence of testing before bringing OSPF adj up.

You are saying do not declare BFD as UP before all of those testing passes.
That test sequence could be just running vanilla normal BFD for X
seconds/minutes/hours.

That would require introducing a completely new BFD state. Worse, that
timer may be very different on a per type of interface basis as each
interface type has completely different characteristics. Also such timer
would need to have a different value on a per BFD client basis. (For
example OSPF adj UP could be very different then PE-PE BFD for BGP as PULSE
alternative :)

Sorry I really do not think this belongs to BFD at all. It is a local
client thing how long from t0 = BFD UP it will wait before proceeding
further.

And last but not least - such extended testing does not need to kick in
every time interface flaps. Maybe the operator only wants to run it during
maintenance windows once per day ? Or once per week ?

But I am not going to even remotely hope I can convince you :) So let's
forget it.

Cheers,
R/
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

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

[Les Ginsberg (ginsberg)]

Robert -

From: Robert Raszuk 
Sent: Saturday, January 29, 2022 12:20 PM
To: Les Ginsberg (ginsberg) 
Cc: Acee Lindem (acee) ; Ketan Talaulikar 
; draft-ietf-lsr-ospf-bfd-strict-m...@ietf.org; Albert 
Fu ; lsr 
Subject: Re: [Lsr] Working Group Last Call for "OSPF Strict-Mode for BFD" - 
draft-ietf-lsr-ospf-bfd-strict-mode-04

Hi Les,

> Discussion of how to make BFD failure detection more robust belongs in the 
> BFD WG
> If you do not want the BFD session to come back up too quickly after a failure

Nothing I suggested is related to any of the above.

Let me perhaps provide a very simple example.

BFD being used is *AS*IS*.

All the operator wants is to run it for say X sec without ever going down 
before bringing OSPF adj up.

That timer and its consistency on both ends clearly belongs to OSPF not to BFD.
[LES:] I disagree. The definition of UP state belongs to the BFD 
protocol/implementation.
If you don’t want BFD clients (like OSPF) to react “too quickly” then build 
additional config/logic into your BFD implementation so it does not signal UP 
state before additional criteria is met – do not make each BFD client (and 
there could be multiple for a given session) configure its own definition of 
BFD UP.

Now what happens within those 30 sec, what BFD packets are formed and how they 
are exchanged is all BFD business - but I am not suggesting to include any of 
those in this draft.

Do we have a common understanding so far ?

Hint: Albert already stated that he needs that timer and that both vendors 
provided it via cfg. All that confirms is that timer is needed. All I am 
suggesting (even before being aware of the manual cfg for it) was to 
synchronize the value or pick lower configured between two peers.

[LES:] I don’t know if Albert and I disagree.
I am saying that the implementations I am familiar with have introduced this 
capability for OSPF precisely because OSPF did not have strict mode support as 
defined in this draft.
There has been no need for this with IS-IS – which has had equivalent support 
(RFC 6213) for many years.
And once OSPF strict-mode support becomes widely deployed there won’t be a need 
for such a timer for OSPF either.

   Les

Kind regards,
R.
















On Sat, Jan 29, 2022 at 9:08 PM Les Ginsberg (ginsberg) 
mailto:ginsb...@cisco.com>> wrote:
Robert –

It is good that you take an active interest in this technology – but I think 
the suggestions you are making should not be targeted at IGP use of BFD.

Discussion of how to make BFD failure detection more robust belongs in the BFD 
WG – and – as you know – that WG has taken an interest in such problems e.g., 
MTU.

In regards to “dampening” = which I think is the relevant term for the timer 
related suggestions you are making - this also does not belong in the IGP. If 
you do not want the BFD session to come back up too quickly after a failure, 
the proper place to put timers is either at the interface layer or in the BFD 
implementation.
I am familiar with implementations which apply this timer at the protocol level 
(AKA BFD client in this context) and this is done precisely because the 
protocol does NOT have the functionality being defined in this draft. Once you 
have implemented “wait-for-BFD” logic as defined in this draft you do not need 
additional delay timers in the protocol.

I don’t think the suggestions you are making belong in this document.

Les


From: Lsr mailto:lsr-boun...@ietf.org>> On Behalf Of 
Robert Raszuk
Sent: Saturday, January 29, 2022 11:25 AM
To: Acee Lindem (acee) mailto:a...@cisco.com>>
Cc: Ketan Talaulikar mailto:ketant.i...@gmail.com>>; 
draft-ietf-lsr-ospf-bfd-strict-m...@ietf.org;
 Albert Fu mailto:af...@bloomberg.net>>; lsr 
mailto:lsr@ietf.org>>
Subject: Re: [Lsr] Working Group Last Call for "OSPF Strict-Mode for BFD" - 
draft-ietf-lsr-ospf-bfd-strict-mode-04

Hi Acee,

Can you suggest text which with you’d be happy? I’m sure the authors would add 
you to the acknowledgements.

Actually instead of suggesting any new text I would suggest to delete the two 
below sentences and it will be fine:

"In certain other scenarios, a degraded or poor quality link will allow OSPF 
adjacency formation to succeed
but the BFD session establishment will fail or the BFD session will flap.  In 
this case, traffic that gets
forwarded over such a link may experience packet drops while the failure of the 
BFD session establishment
would not enable fast routing convergence if the link were to go down or flap."

This could be described but I don’t think it should be normative. This begs the 
question as to why a hold down timer is not a part of the BFD protocol itself.

There is one - BFD calls it multiplier.

But the timer I am suggesting is not related to BFD operation, but to OSPF 
(and/or ISIS). It is not about BFD sessions being UP or DOWN. It is about 
allowing BFD for more testing (with various parameters (for example increasing 
test packet 

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

[Robert Raszuk]

Hi Les,

> Discussion of how to make BFD failure detection more robust belongs in
the BFD WG
> If you do not want the BFD session to come back up too quickly after a
failure

Nothing I suggested is related to any of the above.

Let me perhaps provide a very simple example.

BFD being used is *AS*IS*.

All the operator wants is to run it for say X sec without ever going
down before bringing OSPF adj up.

That timer and its consistency on both ends clearly belongs to OSPF not to
BFD.

Now what happens within those 30 sec, what BFD packets are formed and how
they are exchanged is all BFD business - but I am not suggesting to include
any of those in this draft.

Do we have a common understanding so far ?

Hint: Albert already stated that he needs that timer and that both vendors
provided it via cfg. All that confirms is that timer is needed. All I am
suggesting (even before being aware of the manual cfg for it) was to
synchronize the value or pick lower configured between two peers.

Kind regards,
R.
















On Sat, Jan 29, 2022 at 9:08 PM Les Ginsberg (ginsberg) 
wrote:

> Robert –
>
>
>
> It is good that you take an active interest in this technology – but I
> think the suggestions you are making should not be targeted at IGP use of
> BFD.
>
>
>
> Discussion of how to make BFD failure detection more robust belongs in the
> BFD WG – and – as you know – that WG has taken an interest in such problems
> e.g., MTU.
>
>
>
> In regards to “dampening” = which I think is the relevant term for the
> timer related suggestions you are making - this also does not belong in the
> IGP. If you do not want the BFD session to come back up too quickly after a
> failure, the proper place to put timers is either at the interface layer or
> in the BFD implementation.
>
> I am familiar with implementations which apply this timer at the protocol
> level (AKA BFD client in this context) and this is done precisely because
> the protocol does NOT have the functionality being defined in this draft.
> Once you have implemented “wait-for-BFD” logic as defined in this draft you
> do not need additional delay timers in the protocol.
>
>
>
> I don’t think the suggestions you are making belong in this document.
>
>
>
> Les
>
>
>
>
>
> *From:* Lsr  *On Behalf Of * Robert Raszuk
> *Sent:* Saturday, January 29, 2022 11:25 AM
> *To:* Acee Lindem (acee) 
> *Cc:* Ketan Talaulikar ;
> draft-ietf-lsr-ospf-bfd-strict-m...@ietf.org; Albert Fu <
> af...@bloomberg.net>; lsr 
> *Subject:* Re: [Lsr] Working Group Last Call for "OSPF Strict-Mode for
> BFD" - draft-ietf-lsr-ospf-bfd-strict-mode-04
>
>
>
> Hi Acee,
>
>
>
> Can you suggest text which with you’d be happy? I’m sure the authors would
> add you to the acknowledgements.
>
>
>
> Actually instead of suggesting any new text I would suggest to delete the
> two below sentences and it will be fine:
>
>
>
> *"In certain other scenarios, a degraded or poor quality link will allow
> OSPF adjacency formation to succeed*
>
> *but the BFD session establishment will fail or the BFD session
> will flap.  In this case, traffic that gets *
>
> *forwarded over such a link may experience packet drops while the failure
> of the BFD session establishment *
>
> *would not enable fast routing convergence if the link were to go down or
> flap."*
>
>
>
> This could be described but I don’t think it should be normative. This
> begs the question as to why a hold down timer is not a part of the BFD
> protocol itself.
>
>
>
> There is one - BFD calls it multiplier.
>
>
>
> But the timer I am suggesting is not related to BFD operation, but to OSPF
> (and/or ISIS). It is not about BFD sessions being UP or DOWN. It is about
> allowing BFD for more testing (with various parameters (for example
> increasing test packet size in some discrete steps) before OSPF is happy to
> bring the adj. up.
>
>
>
> Thx,
>
> R.
>
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

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

[Les Ginsberg (ginsberg)]

Robert –

It is good that you take an active interest in this technology – but I think 
the suggestions you are making should not be targeted at IGP use of BFD.

Discussion of how to make BFD failure detection more robust belongs in the BFD 
WG – and – as you know – that WG has taken an interest in such problems e.g., 
MTU.

In regards to “dampening” = which I think is the relevant term for the timer 
related suggestions you are making - this also does not belong in the IGP. If 
you do not want the BFD session to come back up too quickly after a failure, 
the proper place to put timers is either at the interface layer or in the BFD 
implementation.
I am familiar with implementations which apply this timer at the protocol level 
(AKA BFD client in this context) and this is done precisely because the 
protocol does NOT have the functionality being defined in this draft. Once you 
have implemented “wait-for-BFD” logic as defined in this draft you do not need 
additional delay timers in the protocol.

I don’t think the suggestions you are making belong in this document.

Les


From: Lsr  On Behalf Of Robert Raszuk
Sent: Saturday, January 29, 2022 11:25 AM
To: Acee Lindem (acee) 
Cc: Ketan Talaulikar ; 
draft-ietf-lsr-ospf-bfd-strict-m...@ietf.org; Albert Fu ; 
lsr 
Subject: Re: [Lsr] Working Group Last Call for "OSPF Strict-Mode for BFD" - 
draft-ietf-lsr-ospf-bfd-strict-mode-04

Hi Acee,

Can you suggest text which with you’d be happy? I’m sure the authors would add 
you to the acknowledgements.

Actually instead of suggesting any new text I would suggest to delete the two 
below sentences and it will be fine:

"In certain other scenarios, a degraded or poor quality link will allow OSPF 
adjacency formation to succeed
but the BFD session establishment will fail or the BFD session will flap.  In 
this case, traffic that gets
forwarded over such a link may experience packet drops while the failure of the 
BFD session establishment
would not enable fast routing convergence if the link were to go down or flap."

This could be described but I don’t think it should be normative. This begs the 
question as to why a hold down timer is not a part of the BFD protocol itself.

There is one - BFD calls it multiplier.

But the timer I am suggesting is not related to BFD operation, but to OSPF 
(and/or ISIS). It is not about BFD sessions being UP or DOWN. It is about 
allowing BFD for more testing (with various parameters (for example increasing 
test packet size in some discrete steps) before OSPF is happy to bring the adj. 
up.

Thx,
R.
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

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

[Robert Raszuk]

Acee,


> I don’t anyone has implemented the later capability. This MTU test
> extension could be added in a separate draft if there were a strong
> requirement.
>

I think you are mixing an example of what BFD could be doing to make sure
the link is fine with the delay timer allowing it to do whatever it needs.

The former is a local operator's decision. The latter IMO could be added to
the draft to make the interoperability seamless. But this is just a
suggestion/hint. Nothing more.

Many thx,
R.


>
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

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

[Acee Lindem (acee)]

Hi Robert,

From: Robert Raszuk 
Date: Saturday, January 29, 2022 at 2:25 PM
To: Acee Lindem 
Cc: Ketan Talaulikar , lsr , 
"draft-ietf-lsr-ospf-bfd-strict-m...@ietf.org" 
, Albert Fu 
Subject: Re: [Lsr] Working Group Last Call for "OSPF Strict-Mode for BFD" - 
draft-ietf-lsr-ospf-bfd-strict-mode-04

Hi Acee,

Can you suggest text which with you’d be happy? I’m sure the authors would add 
you to the acknowledgements.

Actually instead of suggesting any new text I would suggest to delete the two 
below sentences and it will be fine:

"In certain other scenarios, a degraded or poor quality link will allow OSPF 
adjacency formation to succeed
but the BFD session establishment will fail or the BFD session will flap.  In 
this case, traffic that gets
forwarded over such a link may experience packet drops while the failure of the 
BFD session establishment
would not enable fast routing convergence if the link were to go down or flap."

That would be fine with me but I’ll defer to the authors.

This could be described but I don’t think it should be normative. This begs the 
question as to why a hold down timer is not a part of the BFD protocol itself.

There is one - BFD calls it multiplier.

But the timer I am suggesting is not related to BFD operation, but to OSPF 
(and/or ISIS). It is not about BFD sessions being UP or DOWN. It is about 
allowing BFD for more testing (with various parameters (for example increasing 
test packet size in some discrete steps) before OSPF is happy to bring the adj. 
up.

I don’t anyone has implemented the later capability. This MTU test extension 
could be added in a separate draft if there were a strong requirement.

Thanks,
Acee

Thx,
R.
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

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

[Robert Raszuk]

Hi Acee,

Can you suggest text which with you’d be happy? I’m sure the authors would
> add you to the acknowledgements.
>

Actually instead of suggesting any new text I would suggest to delete the
two below sentences and it will be fine:

*"In certain other scenarios, a degraded or poor quality link will allow
OSPF adjacency formation to succeed*
*but the BFD session establishment will fail or the BFD session will flap.
In this case, traffic that gets *
*forwarded over such a link may experience packet drops while the failure
of the BFD session establishment *
*would not enable fast routing convergence if the link were to go down or
flap."*

This could be described but I don’t think it should be normative. This begs
> the question as to why a hold down timer is not a part of the BFD protocol
> itself.
>

There is one - BFD calls it multiplier.

But the timer I am suggesting is not related to BFD operation, but to OSPF
(and/or ISIS). It is not about BFD sessions being UP or DOWN. It is about
allowing BFD for more testing (with various parameters (for example
increasing test packet size in some discrete steps) before OSPF is happy to
bring the adj. up.

Thx,
R.

>
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

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

[Acee Lindem (acee)]

Speaking as Document Shepherd:

Hi Robert,

From: Robert Raszuk 
Date: Saturday, January 29, 2022 at 11:15 AM
To: Ketan Talaulikar 
Cc: lsr , "draft-ietf-lsr-ospf-bfd-strict-m...@ietf.org" 
, Albert Fu 
, Acee Lindem 
Subject: Re: [Lsr] Working Group Last Call for "OSPF Strict-Mode for BFD" - 
draft-ietf-lsr-ospf-bfd-strict-mode-04

Hi Ketan and all,

I support this draft - it is a useful addition.

There are two elements which I would suggest to adjust in the text before 
publication.

#1 Overpromise

Even below you say:

> Since there is a issue with forwarding (which is what BFD detects)

and in the text we see:

"In certain other scenarios, a degraded or poor quality link will allow OSPF 
adjacency formation to succeed
   but the BFD session establishment will fail or the BFD session will flap."

Reader may get an impression that if he enables strict mode he is 100% safe. 
Sure he is safer then before but not 100% safe.

Can you suggest text which with you’d be happy? I’m sure the authors would add 
you to the acknowledgements.

Real networks prove that there are classes of failures which BFD can not 
detect. And Albert knows them too :)

For example some emulated circuits can experience periodic drops only at some 
MTUs and only when link utilization reaches X %. While there is ongoing 
extension to BFD to fill it with payload I don't think that BFD can be useful 
to also saturate say in 80% 10G link with probes to test it well before 
allowing OSPF to be established.

#2 Timer

What I find missing in the draft is a mutually (between OSPF peers) timer fired 
after BFD session is up which in OSPF could hold on allowing BFD to do some 
more testing before declaring adj to be established. I think just bringing OSPF 
adj immediately after the BFD session is up is not a good thing. Keep in mind 
that we are bringing the interface up so by applying such a timer we are not 
dropping packets .. in fact quite the reverse we are making sure user packets 
would not be dropped.

This could be described but I don’t think it should be normative. This begs the 
question as to why a hold down timer is not a part of the BFD protocol itself.

Thanks,
Acee

Cheers,
Robert

___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

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

[Acee Lindem (acee)]

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 
Date: Saturday, January 29, 2022 at 3:46 AM
To: 'Ketan Talaulikar' 
Cc: "lsr@ietf.org" , 
"draft-ietf-lsr-ospf-bfd-strict-m...@ietf.org" 
, 'Albert Fu' 
, Acee Lindem 
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: lsr-boun...@ietf.org  On Behalf Of Ketan Talaulikar
Sent: Saturday, January 29, 2022 4:22 PM
To: Aijun Wang 
Cc: lsr@ietf.org; draft-ietf-lsr-ospf-bfd-strict-m...@ietf.org; Albert Fu 
; Acee Lindem (acee) 
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 
mailto:wangai...@tsinghua.org.cn>> 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 mailto:ketant.i...@gmail.com>>
Sent: Saturday, January 29, 2022 11:13 AM
To: Aijun Wang mailto:wangai...@tsinghua.org.cn>>
Cc: Acee Lindem (acee) 
mailto:40cisco@dmarc.ietf.org>>; 
lsr@ietf.org; 
draft-ietf-lsr-ospf-bfd-strict-m...@ietf.org;
 Albert Fu mailto:af...@bloomberg.net>>
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 
mailto:wangai...@tsinghua.org.cn>> 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 

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

[Robert Raszuk]

Hi Albert,

> [AF] This draft ensures that BFD can be used to detect failure quickly
> when there is a complete path failure between the nodes. You are right that
> there are many other types of failure that BFD cannot detect.
>
> Indeed, but the draft says otherwise. I think that needs to be adjusted
before publication. If you say it detects complete path failure then
perfect. It could detect more than that ... say path failure at some MTUs
if more time is allowed to test the link before ospf adj comes up.

[AF] This is a good point you brought up. Both router vendors that I have
> tested (Cisco & Juniper) do indeed have timer mechanism to delay when OSPF
> would be allowed to come up, which we have tested (useful to guard against
> flapping links). I am not sure if this "hold down" mechanism needs to be
> included in the draft.
>
>
Sure one option is to keep it as a cfg knob.

But If you do not exchange this timer with agreement to choose a lower one
between peers you are both risking misconfiguration as well as adding a bit
more operational complexity.

Even if this is not exchanged, draft/rfc should still mention it and
recommend some wise default timer - say 5 sec. Maybe more. But I see no
harm to signal it explicitly between peers.

Moreover there can be implementations which will not support that timer and
it will be needed to ask them each time to add it.

Thx,
R.
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

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

[Albert Fu (BLOOMBERG/ 120 PARK)]

Hi Robert,

Thanks for your comment. Please see my response inline.

From: rob...@raszuk.net At: 01/29/22 11:14:59 UTC-5:00To:  ketant.i...@gmail.com
Cc:  Albert Fu (BLOOMBERG/ 120 PARK ) ,  lsr@ietf.org,  
draft-ietf-lsr-ospf-bfd-strict-m...@ietf.org,  acee=40cisco@dmarc.ietf.org
Subject: Re: [Lsr] Working Group Last Call for "OSPF Strict-Mode for BFD" - 
draft-ietf-lsr-ospf-bfd-strict-mode-04

Hi Ketan and all,

I support this draft - it is a useful addition. 

There are two elements which I would suggest to adjust in the text before 
publication. 

#1 Overpromise

Even below you say: 

> Since there is a issue with forwarding (which is what BFD detects)

and in the text we see: 

"In certain other scenarios, a degraded or poor quality link will allow OSPF 
adjacency formation to succeed   but the BFD session establishment will fail or 
the BFD session will flap." 

Reader may get an impression that if he enables strict mode he is 100% safe. 
Sure he is safer then before but not 100% safe. 

Real networks prove that there are classes of failures which BFD can not 
detect. And Albert knows them too :) 

For example some emulated circuits can experience periodic drops only at some 
MTUs and only when link utilization reaches X %. While there is ongoing 
extension to BFD to fill it with payload I don't think that BFD can be useful 
to also saturate say in 80% 10G link with probes to test it well before 
allowing OSPF to be established. 

[AF] This draft ensures that BFD can be used to detect failure quickly when 
there is a complete path failure between the nodes. You are right that there 
are many other types of failure that BFD cannot detect. For example, one other 
one we have seen from time to time is when an interface fails to forward 
configured MTU-sized packet (see the other draft that we have proposed to 
address this is 
https://datatracker.ietf.org/doc/html/draft-ietf-bfd-large-packets). 

There are also other types of failures, such as link errors. 

Another error type that we have encountered are errors due to pattern sensitive 
pattern where BFD/Routing protocols are working fine, but user traffic cannot 
be forwarded due to bit flip.

I tend to think that these type of errors are best handled outside this draft, 
and from previous discussions with various people in the BFD working group, 
they are keen to keep BFD as simple as possible.


#2 Timer 

What I find missing in the draft is a mutually (between OSPF peers) timer fired 
after BFD session is up which in OSPF could hold on allowing BFD to do some 
more testing before declaring adj to be established. I think just bringing OSPF 
adj immediately after the BFD session is up is not a good thing. Keep in mind 
that we are bringing the interface up so by applying such a timer we are not 
dropping packets .. in fact quite the reverse we are making sure user packets 
would not be dropped. 

[AF] This is a good point you brought up. Both router vendors that I have 
tested (Cisco & Juniper) do indeed have timer mechanism to delay when OSPF 
would be allowed to come up, which we have tested (useful to guard against 
flapping links). I am not sure if this "hold down" mechanism needs to be 
included in the draft.


Cheers,
Robert


Thanks,
Albert___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

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

[Robert Raszuk]

Hi Ketan and all,

I support this draft - it is a useful addition.

There are two elements which I would suggest to adjust in the text before
publication.

*#1 Overpromise*

Even below you say:

> Since there is a issue with forwarding *(which is what BFD detects)*

and in the text we see:

"In certain other scenarios, a degraded or poor quality link will allow
OSPF adjacency formation to succeed
   but the *BFD session establishment will fail or the BFD session
will flap*."

Reader may get an impression that if he enables strict mode he is 100%
safe. Sure he is safer then before but not 100% safe.

Real networks prove that there are classes of failures which BFD can not
detect. And Albert knows them too :)

For example some emulated circuits can experience periodic drops only at
some MTUs and only when link utilization reaches X %. While there is
ongoing extension to BFD to fill it with payload I don't think that BFD can
be useful to also saturate say in 80% 10G link with probes to test it well
before allowing OSPF to be established.

*#2 Timer *

What I find missing in the draft is a mutually (between OSPF peers) timer
fired after BFD session is up which in OSPF could hold on allowing BFD to
do some more testing before declaring adj to be established. I think just
bringing OSPF adj immediately after the BFD session is up is not a good
thing. Keep in mind that we are bringing the interface up so by applying
such a timer we are not dropping packets .. in fact quite the reverse we
are making sure user packets would not be dropped.

Cheers,
Robert
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

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

[Ketan Talaulikar]

Hi Aijun,

Please check inline below.


On Sat, Jan 29, 2022 at 2:15 PM Aijun Wang 
wrote:

> 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)?
>

KT> No. Those are different neighborships and the document does not bring
any dependencies between them.


> If not, then the traffic between these DRothers will be lost;
>

KT> Yes. Since there is a issue with forwarding (which is what BFD
detects), the traffic would not get forwarded between those neighbors in
any way. The neighborship going down (and staying down) prevents silent
failures and flapping of that neighborship as explained in the draft. There
is the possibility that an alternate path exists which might be used
instead.


> If yes, it seems strange, because the BFD session between the DRother and
> DR/BDR may be still UP.
>

KT> That makes no difference. It isn't as if all traffic between routers on
the LAN goes through the DR.

Thanks,
Ketan


> 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:* lsr-boun...@ietf.org  *On Behalf Of *Ketan
> Talaulikar
> *Sent:* Saturday, January 29, 2022 4:22 PM
> *To:* Aijun Wang 
> *Cc:* lsr@ietf.org; draft-ietf-lsr-ospf-bfd-strict-m...@ietf.org; Albert
> Fu ; Acee Lindem (acee)  40cisco@dmarc.ietf.org>
> *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 
> 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 
> *Sent:* Saturday, January 29, 2022 11:13 AM
> *To:* Aijun Wang 
> *Cc:* Acee Lindem (acee) ; lsr@ietf.org;
> draft-ietf-lsr-ospf-bfd-strict-m...@ietf.org; Albert Fu <
> af...@bloomberg.net>
> *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 
> 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 

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

[Aijun Wang]

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: lsr-boun...@ietf.org  On Behalf Of Ketan Talaulikar
Sent: Saturday, January 29, 2022 4:22 PM
To: Aijun Wang 
Cc: lsr@ietf.org; draft-ietf-lsr-ospf-bfd-strict-m...@ietf.org; Albert Fu 
; Acee Lindem (acee) 
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 mailto:wangai...@tsinghua.org.cn> > 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 mailto:ketant.i...@gmail.com> > 
Sent: Saturday, January 29, 2022 11:13 AM
To: Aijun Wang mailto:wangai...@tsinghua.org.cn> >
Cc: Acee Lindem (acee) mailto:40cisco@dmarc.ietf.org> >; lsr@ietf.org  ; 
draft-ietf-lsr-ospf-bfd-strict-m...@ietf.org 
 ; Albert Fu 
mailto:af...@bloomberg.net> >
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 mailto:wangai...@tsinghua.org.cn> > 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: lsr-boun...@ietf.org   mailto:lsr-boun...@ietf.org> > On Behalf Of Acee Lindem (acee)
Sent: Friday, January 28, 2022 8:30 PM
To: Aijun Wang mailto:wangai...@tsinghua.org.cn> >; 
'Ketan Talaulikar' mailto:ketant.i...@gmail.com> >
Cc: lsr@ietf.org  ; 
draft-ietf-lsr-ospf-bfd-strict-m...@ietf.org 
 ; 'Albert Fu' 
mailto:af...@bloomberg.net> >
Subject: Re: [Lsr] Working Group Last 

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

[Ketan Talaulikar]

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 
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 
> *Sent:* Saturday, January 29, 2022 11:13 AM
> *To:* Aijun Wang 
> *Cc:* Acee Lindem (acee) ; lsr@ietf.org;
> draft-ietf-lsr-ospf-bfd-strict-m...@ietf.org; Albert Fu <
> af...@bloomberg.net>
> *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 
> 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:* lsr-boun...@ietf.org  *On Behalf Of *Acee
> Lindem (acee)
> *Sent:* Friday, January 28, 2022 8:30 PM
> *To:* Aijun Wang ; 'Ketan Talaulikar' <
> ketant.i...@gmail.com>
> *Cc:* lsr@ietf.org; draft-ietf-lsr-ospf-bfd-strict-m...@ietf.org; 'Albert
> Fu' 
> *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 
> *Date: *Friday, January 28, 2022 at 1:41 AM
> *To: *'Ketan Talaulikar' 
> *Cc: *"lsr@ietf.org" , "
> draft-ietf-lsr-ospf-bfd-strict-m...@ietf.org" <
> draft-ietf-lsr-ospf-bfd-strict-m...@ietf.org>, Acee Lindem ,
> 'Albert Fu' 
> *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:* lsr-boun...@ietf.org  *On Behalf Of *Aijun
> Wang
> *Sent:* Friday, January 28, 2022 2:02 PM
> *To:* 'Ketan Talaulikar' 
> *Cc:* lsr@ietf.org; draft-ietf-lsr-ospf-bfd-strict-m...@ietf.org; 'Acee
> Lindem (acee)' ; 'Albert Fu' 
> *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 

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

[Aijun Wang]

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 mailto:ketant.i...@gmail.com> > 
Sent: Saturday, January 29, 2022 11:13 AM
To: Aijun Wang mailto:wangai...@tsinghua.org.cn> >
Cc: Acee Lindem (acee) mailto:40cisco@dmarc.ietf.org> >; lsr@ietf.org  ; 
draft-ietf-lsr-ospf-bfd-strict-m...@ietf.org 
 ; Albert Fu 
mailto:af...@bloomberg.net> >
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 mailto:wangai...@tsinghua.org.cn> > 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: lsr-boun...@ietf.org   mailto:lsr-boun...@ietf.org> > On Behalf Of Acee Lindem (acee)
Sent: Friday, January 28, 2022 8:30 PM
To: Aijun Wang mailto:wangai...@tsinghua.org.cn> >; 
'Ketan Talaulikar' mailto:ketant.i...@gmail.com> >
Cc: lsr@ietf.org  ; 
draft-ietf-lsr-ospf-bfd-strict-m...@ietf.org 
 ; 'Albert Fu' 
mailto:af...@bloomberg.net> >
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 mailto:wangai...@tsinghua.org.cn> >
Date: Friday, January 28, 2022 at 1:41 AM
To: 'Ketan Talaulikar' mailto:ketant.i...@gmail.com> >
Cc: "lsr@ietf.org  " mailto:lsr@ietf.org> 
>, "draft-ietf-lsr-ospf-bfd-strict-m...@ietf.org 
 " 
mailto:draft-ietf-lsr-ospf-bfd-strict-m...@ietf.org> >, Acee Lindem 
mailto:a...@cisco.com> >, 'Albert Fu' mailto:af...@bloomberg.net> >
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: lsr-boun...@ietf.org   mailto:lsr-boun...@ietf.org> > On Behalf Of Aijun Wang
Sent: Friday, January 28, 2022 2:02 PM
To: 'Ketan Talaulikar' mailto:ketant.i...@gmail.com> >
Cc: lsr@ietf.org