Re: [Lsr] IPR Poll Coinciding with WGLC for "OSPF Strict-Mode for BFD" - draft-ietf-lsr-ospf-bfd-strict-mode-04

[Rajesh M]

Hi Acee,



I am not aware of any IPR associated with this draft.



Thanks,

Rajesh


From: Acee Lindem (acee) 
Sent: Tuesday, February 8, 2022 1:21 AM
To: Rajesh M 
Cc: lsr@ietf.org; draft-ietf-lsr-ospf-bfd-strict-m...@ietf.org
Subject: Re: [Lsr] IPR Poll Coinciding with WGLC for "OSPF Strict-Mode for BFD" 
- draft-ietf-lsr-ospf-bfd-strict-mode-04

[External Email. Be cautious of content]

Hi Rajesh,
I’m missing a WG last call declaration from you.
Thanks,
Acee

From: Lsr mailto:lsr-boun...@ietf.org>> on behalf of 
"Acee Lindem (acee)" 
mailto:acee=40cisco@dmarc.ietf.org>>
Date: Thursday, January 27, 2022 at 12:16 PM
To: 
"draft-ietf-lsr-ospf-bfd-strict-m...@ietf.org"
 
mailto:draft-ietf-lsr-ospf-bfd-strict-m...@ietf.org>>
Cc: "lsr@ietf.org" mailto:lsr@ietf.org>>
Subject: [Lsr] IPR Poll Coinciding with WGLC for "OSPF Strict-Mode for BFD" - 
draft-ietf-lsr-ospf-bfd-strict-mode-04

Draft Authors,

Are you aware of any IPR that applies to
draft-ietf-ospf-bfd-strict-mode-04?
If so, has this IPR been disclosed in compliance with IETF IPR rules
(see RFCs 3979, 4879, 3669 and 5378 for more details).

If you are listed as a document author or contributor please respond
to this email regardless of whether or not you are aware of any
relevant IPR. The response needs to be sent to the LSR WG mailing
list. The document will not advance to the next stage until a
response has been received from each author and contributor.

If you are on the LSR WG email list but are not listed as an author or
contributor, then please explicitly respond only if you are aware of
any IPR that has not yet been disclosed in conformance with IETF rules.

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

Re: [Lsr] IPR Poll Coinciding with WGLC for "OSPF Strict-Mode for BFD" - draft-ietf-lsr-ospf-bfd-strict-mode-04

[Acee Lindem (acee)]

Hi Rajesh,
I’m missing a WG last call declaration from you.
Thanks,
Acee

From: Lsr  on behalf of "Acee Lindem (acee)" 

Date: Thursday, January 27, 2022 at 12:16 PM
To: "draft-ietf-lsr-ospf-bfd-strict-m...@ietf.org" 

Cc: "lsr@ietf.org" 
Subject: [Lsr] IPR Poll Coinciding with WGLC for "OSPF Strict-Mode for BFD" - 
draft-ietf-lsr-ospf-bfd-strict-mode-04

Draft Authors,

Are you aware of any IPR that applies to
draft-ietf-ospf-bfd-strict-mode-04?
If so, has this IPR been disclosed in compliance with IETF IPR rules
(see RFCs 3979, 4879, 3669 and 5378 for more details).

If you are listed as a document author or contributor please respond
to this email regardless of whether or not you are aware of any
relevant IPR. The response needs to be sent to the LSR WG mailing
list. The document will not advance to the next stage until a
response has been received from each author and contributor.

If you are on the LSR WG email list but are not listed as an author or
contributor, then please explicitly respond only if you are aware of
any IPR that has not yet been disclosed in conformance with IETF rules.

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

[Lsr] [Errata Verified] RFC8665 (6838)

[RFC Errata System]

The following errata report has been verified for RFC8665,
"OSPF Extensions for Segment Routing". 

--
You may review the report below and at:
https://www.rfc-editor.org/errata/eid6838

--
Status: Verified
Type: Editorial

Reported by: Praveen Kumar 
Date Reported: 2022-02-05
Verified by: John Scudder (IESG)

Section: 6.1

Original Text
-
B-Flag:  Backup Flag.  If set, the Adj-SID refers to an
   adjacency that is eligible for protection (e.g., using IP
   Fast Reroute or MPLS-FRR (MPLS-Fast Reroute) as described
   in Section 2.1 of [RFC8402].

Corrected Text
--
B-Flag:  Backup Flag.  If set, the Adj-SID refers to an
   adjacency that is eligible for protection (e.g., using IP
   Fast Reroute or MPLS-FRR (MPLS-Fast Reroute) as described
   in Section 3.4 of [RFC8402].

Notes
-
I don't see any section 2.1 in RFC 8402. Reference of section 2.1 of RFC 8402 
seems incorrect. It should be section 3.4 as per my understanding. Kindly fix 
it if possible.

--
RFC8665 (draft-ietf-ospf-segment-routing-extensions-27)
--
Title   : OSPF Extensions for Segment Routing
Publication Date: December 2019
Author(s)   : P. Psenak, Ed., S. Previdi, Ed., C. Filsfils, H. Gredler, 
R. Shakir, W. Henderickx, J. Tantsura
Category: PROPOSED STANDARD
Source  : Open Shortest Path First IGP
Area: Routing
Stream  : IETF
Verifying Party : IESG

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

[Lsr] Early Code Point AAlocation for draft-ietf-lsr-isis-fast-flooding

[Les Ginsberg (ginsberg)]

Designated Experts/WG Chairs -

The authors of draft-ietf-lsr-isis-fast-flooding request early allocation for 
the top level TLV codepoint: Flooding Parameters TLV

as specified in 
https://www.ietf.org/archive/id/draft-ietf-lsr-isis-fast-flooding-00.html#name-iana-considerations

Thanx.

   Les (on behalf of the authors)

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

Re: [Lsr] Lsr Digest, Vol 49, Issue 24

[Robert Raszuk]

HI Albert,

> This is precisely the issue that this draft intends to address,
> making sure that OSPF is not established, until BFD is UP.

What this draft tries to address is obvious. The real issue is however in
the true meaning of what "BFD UP" trigger means.

Some folks, perhaps including yourself, naturally and intuitively think
that BFD UP means that BFD session has been established and data plane has
been confirmed to work between local and remote node over the subject link.

That is unfortunate not the case modulo local implementation hacks. BFD
RFC5880 says that BFD UP only means that BFD session signaling completed.
It says nothing about the actual data plane being tested at least once
between two peers on the very link you are going to bring OSPF adj UP.

RFC5882 recommends implementation of BFD dampening but as we established
this does not cover the point of the discussion. It also discusses
interaction between BFD and client(s) when a session goes DOWN. It is
pretty silent on the session UP event leaving this pretty open to the
implementations.

*Proposal: *

If you do not want to add any text describing any recommended behavior on
the client why just not add instead a single sentence defining that in the
context of this draft "BFD UP" trigger as received by the client means not
only BFD session UP but at least one full test cycle to pass successfully ?
Is there any harm associated with adding such statement ?

Regards,
R.

PS,

> We know that BFD UP, as it stands today, does not mean that the link is
100% good
> (e.g. MTU-sized packets might not get through). IMO, link quality issue
is
> outside the scope of this draft.

That is not the point. The point it to make link really works in the data
plane. The extra testing is indeed out of scope and as I mentioned it was
just an example.





On Mon, Feb 7, 2022 at 3:51 PM Albert Fu (BLOOMBERG/ 120 PARK) <
af...@bloomberg.net> wrote:

> Hi Robert,
>
> This is precisely the issue that this draft intends to address, making
> sure that OSPF is not established, until BFD is UP.
>
> This ensures that there is a mechanism to quickly detect BFD failures, and
> avoid having to rely on lengthy OSPF protocol timer for failure detection
> (where OSPF is UP without BFD).
>
> If there's an issue where BFD packets can not get through after OSPF is
> UP, the fast detect mechanism will kick in as per the configured
> timer/multiplier, and bring OSPF down, diverting traffic away from the link.
>
> We know that BFD UP, as it stands today, does not mean that the link is
> 100% good (e.g. MTU-sized packets might not get through). IMO, link quality
> issue is outside the scope of this draft.
>
> Thanks
> Albert
>
> From: Robert Raszuk  To: Les Ginsberg <
> ginsb...@cisco.com>
> Subject: Re: [Lsr] Working Group Last Call for "OSPF Strict-Mode for BFD"
> - draft-ietf-lsr-ospf-bfd-strict-mode-04
> Date: Mon, 7 Feb 2022 00:31:04 +0100
>
> ..
>
> When the interface goes UP OSPF will not bring adj UP till BFD comes UP.
> But then we are back in square one as OSPF adj comes UP and BFD after a
> full cycle of testing brings it back down. So what have we accomplished
> with this draft/RFC - nothing.
>
>
>
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] Lsr Digest, Vol 49, Issue 24

[Albert Fu (BLOOMBERG/ 120 PARK)]

Hi Robert,

This is precisely the issue that this draft intends to address, making sure 
that OSPF is not established, until BFD is UP. 

This ensures that there is a mechanism to quickly detect BFD failures, and 
avoid having to rely on lengthy OSPF protocol timer for failure detection 
(where OSPF is UP without BFD). 

If there's an issue where BFD packets can not get through after OSPF is UP, the 
fast detect mechanism will kick in as per the configured timer/multiplier, and 
bring OSPF down, diverting traffic away from the link.

We know that BFD UP, as it stands today, does not mean that the link is 100% 
good (e.g. MTU-sized packets might not get through). IMO, link quality issue is 
outside the scope of this draft. 

Thanks
Albert


From: Robert Raszuk  To: Les Ginsberg 
Subject: Re: [Lsr] Working Group Last Call for "OSPF Strict-Mode for BFD" - 
draft-ietf-lsr-ospf-bfd-strict-mode-04
Date: Mon, 7 Feb 2022 00:31:04 +0100

..

When the interface goes UP OSPF will not bring adj UP till BFD comes UP. But 
then we are back in square one as OSPF adj comes UP and BFD after a full cycle 
of testing brings it back down. So what have we accomplished with this 
draft/RFC - nothing. 


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