Re: [Lsr] New Version Notification for draft-cheng-ospf-adjacency-suppress-00.txt

[Mengxiao.Chen]

Hi Les,

Thank you for your comments.
OSPF does include the LSDB sync requirement. But OSPF state machine does not 
guarantee the two routers attain FULL state at the same time.

R1(restart)--R2--R3

R1 LSDB: R1's new router-LSA, seq 8001
R2 LSDB: R1's old router-LSA, seq 8500

When R1 restarts from an unplanned outage, R1 will reinitialize its LSA 
sequence number. But R2 has the previous copies of R1's LSA, which has larger 
sequence number.
R2 thinks its local LSAs are "newer". So, R2 will attain FULL state, without 
requesting R1 to update.
This may cause temporary blackholes to occur until R1 regenerates and floods 
its own LSAs with higher sequence numbers.

Thanks,
Mengxiao

-Original Message-
From: Lsr  On Behalf Of Les Ginsberg (ginsberg)
Sent: Tuesday, March 7, 2023 1:29 AM
To: Acee Lindem ; Liyan Gong 
Cc: lsr 
Subject: Re: [Lsr] New Version Notification for 
draft-cheng-ospf-adjacency-suppress-00.txt

+1 to what Acee has said.

As historical context, the SA bit was defined in IS-IS precisely because IS-IS 
adjacency state machine does NOT include LSPDB sync as a requirement before the 
adjacency is usable (unlike OSPF).
OSPF does not need SA bit.

   Les

> -Original Message-
> From: Lsr  On Behalf Of Acee Lindem
> Sent: Monday, March 6, 2023 8:01 AM
> To: Liyan Gong 
> Cc: lsr 
> Subject: Re: [Lsr] New Version Notification for draft-cheng-ospf-adjacency-
> suppress-00.txt
>
> Hi Liyan,
>
> I should replied to this Email rather than your request for an IETF 116 slot.
> Please reply to this one.
>
> I’m sorry but I don’t get this draft from a quick read. An OSPF router would
> not advertise an adjacency until the router is in FULL state. An OSPF router
> will not attain FULL state until database synchronization is complete.
> The following statement from you use case is incorrect:
>
> So, without requesting the starting router to update its LSAs, the
> neighbors of the starting router may transition to "Full" state and
> route the traffic through the starting router.
>
> Why do you think you need this extension?
>
>
> Thanks,
> Acee
>
>
> > On Mar 6, 2023, at 9:10 AM, Liyan Gong 
> wrote:
> >
> > Dear All,
> > We have posted a new draft https://datatracker.ietf.org/doc/draft-cheng-
> ospf-adjacency-suppress/.
> > This draft describes the extension of OSPF LLS to signal adjacency
> suppression which is functionally similar to the SA bit of Restart TLV in 
> IS-IS.
> > The purpose is to avoid the temporary blackhole when a router restarts
> from unplanned outages.
> > We are looing forward to your comments.Thanks a lot.
> >
> > Best Regards,
> > Liyan
> >
> > 邮件原文
> > 发件人：internet-drafts 
> > 收件人：Changwang Lin ,Liyan Gong
> ,Mengxiao Chen
> ,Weiqiang Cheng
> 
> > 抄　送: (无)
> > 发送时间：2023-03-06 17:43:39
> > 主题：New Version Notification for draft-cheng-ospf-adjacency-suppress-
> 00.txt
> >
> >
> > A new version of I-D, draft-cheng-ospf-adjacency-suppress-00.txt
> > has been successfully submitted by Mengxiao Chen and posted to the
> > IETF repository.
> >
> > Name: draft-cheng-ospf-adjacency-suppress
> > Revision: 00
> > Title: OSPF Adjacency Suppression
> > Document date: 2023-03-06
> > Group: Individual Submission
> > Pages: 8
> > URL:https://www.ietf.org/archive/id/draft-cheng-ospf-adjacency-
> suppress-00.txt
> > Status: https://datatracker.ietf.org/doc/draft-cheng-ospf-adjacency-
> suppress/
> > Htmlized:   https://datatracker.ietf.org/doc/html/draft-cheng-ospf-
> adjacency-suppress
> >
> >
> > Abstract:
> >This document describes a mechanism for a router to signal its
> >neighbors to suppress advertising the adjacency to it until link-
> >state database synchronization is complete. This minimizes transient
> >routing disruption when a router restarts from unplanned outages.
> >
> >
> >
> >
> > The IETF Secretariat
> >
> >
> >
> > Subject：New Version Notification for draft-cheng-ospf-adjacency-
> suppress-00.txt
> >
> >
> > A new version of I-D, draft-cheng-ospf-adjacency-suppress-00.txt
> > has been successfully submitted by Mengxiao Chen and posted to the
> > IETF repository.
> >
> > Name: draft-cheng-ospf-adjacency-suppress
> > Revision: 00
> > Title: OSPF Adjacency Suppression
> > Document date: 2023-03-06
> > Group: Individual Submission
> > Pages: 8
> > URL:https://www.ietf.org/archive/id/draft-cheng-ospf-adjacency-
> suppress-00.txt
> > Status: https://datatracker.ietf.org/doc/draft-cheng-ospf-adjacency-
> suppress/
> > Htmlized:   https://datatracker.ietf.org/doc/html/draft-cheng-ospf-
> adjacency-suppress
> >
> >
> > Abstract:
> >This document describes a mechanism for a router to signal its
> >neighbors to suppress advertising the adjacency to it until link-
> >state database synchronization is complete. This minimizes transient
> >routing disruption when a router restarts from unplanned outages.
> >
> >
> >
> >
> > The IETF Secretariat
> >
> >
> >
> > _

Re: [Lsr] Slot request for LSR IETF 116

[Mengxiao.Chen]

Hi Acee,

Thank you for your review.

The problem described in that draft happens when an OSPF router restarts from 
unplanned outage.
Its neighbor has the previous copies of the starting router's LSAs. Since the 
starting router will reinitialize LSA sequence numbers, the neighbor thinks its 
local LSAs are newer. So, the neighbor will attain FULL state and advertise the 
adjacency.
Meanwhile, the starting router will try to regenerate and flood its own LSAs 
with higher sequence numbers. During this period, temporary blackhole may occur.

I think the proposed extension provides functionality similar to the SA bit of 
Restart TLV in IS-IS [RFC8706].

Thanks,
Mengxiao

-Original Message-
From: Acee Lindem 
Sent: Monday, March 6, 2023 11:59 PM
To: Liyan Gong ; lsr 
Cc: Yingzhen Qu ; lsr-chairs ; 
Weiqiang Cheng ; linchangwang (RD) 
; chenmengxiao (RD) 
Subject: Re: [Lsr] Slot request for LSR IETF 116

+LSR

I’m sorry but I don’t get this draft from a quick read. An OSPF router would 
not advertise an adjacency until the router is in FULL state. An OSPF router 
will not attain FULL state until database synchronization is complete.
The following statement from you use case is incorrect:

 So, without requesting the starting router to update its LSAs, the
 neighbors of the starting router may transition to "Full" state and
 route the traffic through the starting router.

Why do you think you need this extension?


Thanks,
Acee

> On Mar 6, 2023, at 9:13 AM, Liyan Gong  wrote:
>
>
> Dear Yingzhen and Chairs,
> On behalf of the co-authors, I would like to request a slot for the following 
> draft,Thanks a lot.
> • draft to be presented: OSPF Adjacency Suppression, 
> https://datatracker.ietf.org/doc/draft-cheng-ospf-adjacency-suppress/
> • presenter name: Liyan Gong（gongli...@chinamobile.com）/Weiqiang 
> Cheng(chengweiqi...@chinamobile.com)
> • estimated time: 10 mins
>
> Best Regards,
> Liyan
>
>
> 邮件原文
> 发件人：Yingzhen Qu  
> 收件人：lsr-chairs  ,lsr  
> 抄　送: (无)
> 发送时间：2023-03-01 02:37:11
> 主题：[Lsr] Slot request for LSR IETF 116
>
> Dear LSR WG:
> The preliminary agenda for IETF 116 has been released, and the LSR session is 
> scheduled on Monday Session I (9:30-11:30).
>
> Please send your presentation request to LSR WG chairs (lsr-cha...@ietf.org) 
> before the end of Monday March 13 with the following info:
> •
> draft to be presented
> • presenter name
> • estimated time needed, including Q&A
> If there is any question, please let me know.
>
> Thanks,
> Yingzhen
>

-
本邮件及其附件含有新华三集团的保密信息，仅限于发送给上面地址中列出
的个人或群组。禁止任何其他人以任何形式使用（包括但不限于全部或部分地泄露、复制、
或散发）本邮件中的信息。如果您错收了本邮件，请您立即电话或邮件通知发件人并删除本
邮件！
This e-mail and its attachments contain confidential information from New H3C, 
which is
intended only for the person or entity whose address is listed above. Any use 
of the
information contained herein in any way (including, but not limited to, total 
or partial
disclosure, reproduction, or dissemination) by persons other than the intended
recipient(s) is prohibited. If you receive this e-mail in error, please notify 
the sender
by phone or email immediately and delete it!
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] New Version Notification for draft-cheng-ospf-adjacency-suppress-00.txt

[Les Ginsberg (ginsberg)]

+1 to what Acee has said.

As historical context, the SA bit was defined in IS-IS precisely because IS-IS 
adjacency state machine does NOT include LSPDB sync as a requirement before the 
adjacency is usable (unlike OSPF).
OSPF does not need SA bit.

   Les

> -Original Message-
> From: Lsr  On Behalf Of Acee Lindem
> Sent: Monday, March 6, 2023 8:01 AM
> To: Liyan Gong 
> Cc: lsr 
> Subject: Re: [Lsr] New Version Notification for draft-cheng-ospf-adjacency-
> suppress-00.txt
> 
> Hi Liyan,
> 
> I should replied to this Email rather than your request for an IETF 116 slot.
> Please reply to this one.
> 
> I’m sorry but I don’t get this draft from a quick read. An OSPF router would
> not advertise an adjacency until the router is in FULL state. An OSPF router
> will not attain FULL state until database synchronization is complete.
> The following statement from you use case is incorrect:
> 
> So, without requesting the starting router to update its LSAs, the
> neighbors of the starting router may transition to "Full" state and
> route the traffic through the starting router.
> 
> Why do you think you need this extension?
> 
> 
> Thanks,
> Acee
> 
> 
> > On Mar 6, 2023, at 9:10 AM, Liyan Gong 
> wrote:
> >
> > Dear All,
> > We have posted a new draft https://datatracker.ietf.org/doc/draft-cheng-
> ospf-adjacency-suppress/.
> > This draft describes the extension of OSPF LLS to signal adjacency
> suppression which is functionally similar to the SA bit of Restart TLV in 
> IS-IS.
> > The purpose is to avoid the temporary blackhole when a router restarts
> from unplanned outages.
> > We are looing forward to your comments.Thanks a lot.
> >
> > Best Regards,
> > Liyan
> >
> > 邮件原文
> > 发件人：internet-drafts 
> > 收件人：Changwang Lin ,Liyan Gong
> ,Mengxiao Chen
> ,Weiqiang Cheng
> 
> > 抄　送: (无)
> > 发送时间：2023-03-06 17:43:39
> > 主题：New Version Notification for draft-cheng-ospf-adjacency-suppress-
> 00.txt
> >
> >
> > A new version of I-D, draft-cheng-ospf-adjacency-suppress-00.txt
> > has been successfully submitted by Mengxiao Chen and posted to the
> > IETF repository.
> >
> > Name: draft-cheng-ospf-adjacency-suppress
> > Revision: 00
> > Title: OSPF Adjacency Suppression
> > Document date: 2023-03-06
> > Group: Individual Submission
> > Pages: 8
> > URL:https://www.ietf.org/archive/id/draft-cheng-ospf-adjacency-
> suppress-00.txt
> > Status: https://datatracker.ietf.org/doc/draft-cheng-ospf-adjacency-
> suppress/
> > Htmlized:   https://datatracker.ietf.org/doc/html/draft-cheng-ospf-
> adjacency-suppress
> >
> >
> > Abstract:
> >This document describes a mechanism for a router to signal its
> >neighbors to suppress advertising the adjacency to it until link-
> >state database synchronization is complete. This minimizes transient
> >routing disruption when a router restarts from unplanned outages.
> >
> >
> >
> >
> > The IETF Secretariat
> >
> >
> >
> > Subject：New Version Notification for draft-cheng-ospf-adjacency-
> suppress-00.txt
> >
> >
> > A new version of I-D, draft-cheng-ospf-adjacency-suppress-00.txt
> > has been successfully submitted by Mengxiao Chen and posted to the
> > IETF repository.
> >
> > Name: draft-cheng-ospf-adjacency-suppress
> > Revision: 00
> > Title: OSPF Adjacency Suppression
> > Document date: 2023-03-06
> > Group: Individual Submission
> > Pages: 8
> > URL:https://www.ietf.org/archive/id/draft-cheng-ospf-adjacency-
> suppress-00.txt
> > Status: https://datatracker.ietf.org/doc/draft-cheng-ospf-adjacency-
> suppress/
> > Htmlized:   https://datatracker.ietf.org/doc/html/draft-cheng-ospf-
> adjacency-suppress
> >
> >
> > Abstract:
> >This document describes a mechanism for a router to signal its
> >neighbors to suppress advertising the adjacency to it until link-
> >state database synchronization is complete. This minimizes transient
> >routing disruption when a router restarts from unplanned outages.
> >
> >
> >
> >
> > The IETF Secretariat
> >
> >
> >
> > ___
> > 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
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] [Editorial Errata Reported] RFC9350 (7376)

[John Scudder]

Hi Les,

Thanks for the input. I’ve verified the erratum as editorial/HFDU already under 
the doctrine of “doesn’t hurt, might help”. Apart from other considerations, 
the existence of the erratum serves as further documentation that the text in 
question does *not* mean the protocol (IS-IS).

—John

> On Mar 6, 2023, at 11:01 AM, Les Ginsberg (ginsberg) 
>  wrote:
> 
> 
> [External Email. Be cautious of content]
> 
> 
> (At the risks of giving this issue more attention than it merits…)
>  
> My interpretation of the filed Errata is that the submitter incorrectly 
> thought that the text should be referring to the protocol (IS-IS) and that 
> the text had been inadvertently truncated. Consider that the “Note” says:
>  
> “Incorrect name of protocol (IS instead IS-IS).”
>  
> We all agree that the text is in fact referring to a router (an IS) that 
> supports the IS-IS protocol. The text is therefore correct as it stands.
>  
> Acee has pointed out further that we are not required to expand this 
> particular acronym on first use – therefore there really is no reason to 
> accept this Errata (IMHO).
>  
> John – whatever you want to do here is fine – but I think your statement “the 
> lack of expansion confused at least one person” is being overly generous in 
> this case.
>  
> Les
>  
> From: Lsr  On Behalf Of John Scudder
> Sent: Monday, March 6, 2023 4:57 AM
> To: Acee Lindem 
> Cc: Peter Psenak (ppsenak) ; Tony Li ; 
> RFC Errata System ; nmal...@protokols.ru; Shraddha 
> Hegde ; Clarence Filsfils (cfilsfil) 
> ; Ketan Talaulikar ; 
> arkadiy.gu...@edwardjones.com; lsr 
> Subject: Re: [Lsr] [Editorial Errata Reported] RFC9350 (7376)
>  
> “Hold For Document Update” is exactly for the purpose [1] of making nominal 
> but inessential improvements. This one seems roughly on the level of “trivial 
> grammar correction” (item 4 of [1]) which is in-scope for HFDU, and 
> apparently the lack of expansion confused at least one person, so I’m 
> inclined to verify as HFDU with Tony’s text, unless there’s a strong case not 
> to. 
>  
> —John
>  
> [1] https://www.ietf.org/about/groups/iesg/statements/processing-rfc-errata/
> 
> 
> On Mar 6, 2023, at 7:39 AM, Acee Lindem  wrote:
> 
> 
> Hi Peter,
> 
> I agree it is not an errata. We really don’t want to set precedence of having 
> published RFC text nominally improved via Errata. I’ve copied John for Errata 
> resolution.
> 
> Thanks,
> Acee
> 
> 
> On Mar 6, 2023, at 4:14 AM, Peter Psenak  wrote:
>  
> Acee,
>  
> if you ask me, I would not do anything. "IS" is correct in the text and it's 
> well known.
>  
> my 2c,
> Peter
>  
>  
> On 05/03/2023 14:32, Acee Lindem wrote:
> Hi Tony,
> On Mar 4, 2023, at 4:42 PM, Tony Li  wrote:
>  
>  
> Hi all,
>  
> IMHO, this erratum is correct, but the proposed fix is incorrect.
>  
> In this case, the original text seeks to use ‘IS’ as an abbreviation for 
> ‘Intermediate System’ (i.e., router). Thus, a better fix would be:
>  
> One of the limitations of IS-IS [ISO10589] is that the length of a
> TLV/sub-TLV is limited to a maximum of 255 octets.  For the FAD sub-
> TLV, there are a number of sub-sub-TLVs (defined below) that are
> supported.  For a given Flex-Algorithm, it is possible that the total
> number of octets required to completely define a FAD exceeds the
> maximum length supported by a single FAD sub-TLV.  In such cases, the
> FAD MAY be split into multiple such sub-TLVs, and the content of the
> multiple FAD sub-TLVs are combined to provide a complete FAD for the
> Flex-Algorithm.  In such a case, the fixed portion of the FAD (see
> Section 5.1) MUST be identical in all FAD sub-TLVs for a given Flex-
> Algorithm from a given IS (Intermediate System).
>  
> Please note the recurrence of the use of ‘IS’ in the next sentence and again 
> in the next paragraph.
> Strictly speaking, the expansion is not required as IS in the context of 
> IS-IS is “well-known” as 
> perhttps://urldefense.com/v3/__https://www.rfc-editor.org/materials/abbrev.expansion.txt__;!!NEt6yMaO-gk!Gpea-h_uboqENXj9y1qHNFUDOqCRbNMUKkG5Sp1r2-kD8X7cc3819anwOcRNYutT1iR1sYOZdVtLolo$
>  . However, I agree that expansion on first use is an improvement.
> Thanks,
> Acee
>  
> Regards,
> Tony
>  
>  
> On Mar 4, 2023, at 1:28 PM, RFC Errata System  
> wrote:
>  
> The following errata report has been submitted for RFC9350,
> "IGP Flexible Algorithm".
>  
> --
> You may review the report below and at:
> https://urldefense.com/v3/__https://www.rfc-editor.org/errata/eid7376__;!!NEt6yMaO-gk!Gpea-h_uboqENXj9y1qHNFUDOqCRbNMUKkG5Sp1r2-kD8X7cc3819anwOcRNYutT1iR1sYOZBstDDr4$
>  
> --
> Type: Editorial
> Reported by: Nikolai Malykh 
>  
> Section: 6
>  
> Original Text
> -
> One of the limitations of IS-IS [ISO10589] is that the length of a
> TLV/sub-TLV is limited to a maximum of 255 octets.  For the FAD sub-
> TLV, there are a number of sub-sub-TLVs (defined below) that a

Re: [Lsr] [Editorial Errata Reported] RFC9350 (7376)

[Les Ginsberg (ginsberg)]

(At the risks of giving this issue more attention than it merits…)

My interpretation of the filed Errata is that the submitter incorrectly thought 
that the text should be referring to the protocol (IS-IS) and that the text had 
been inadvertently truncated. Consider that the “Note” says:

“Incorrect name of protocol (IS instead IS-IS).”

We all agree that the text is in fact referring to a router (an IS) that 
supports the IS-IS protocol. The text is therefore correct as it stands.

Acee has pointed out further that we are not required to expand this particular 
acronym on first use – therefore there really is no reason to accept this 
Errata (IMHO).

John – whatever you want to do here is fine – but I think your statement “the 
lack of expansion confused at least one person” is being overly generous in 
this case.

Les

From: Lsr  On Behalf Of John Scudder
Sent: Monday, March 6, 2023 4:57 AM
To: Acee Lindem 
Cc: Peter Psenak (ppsenak) ; Tony Li ; RFC 
Errata System ; nmal...@protokols.ru; Shraddha Hegde 
; Clarence Filsfils (cfilsfil) ; 
Ketan Talaulikar ; arkadiy.gu...@edwardjones.com; lsr 

Subject: Re: [Lsr] [Editorial Errata Reported] RFC9350 (7376)

“Hold For Document Update” is exactly for the purpose [1] of making nominal but 
inessential improvements. This one seems roughly on the level of “trivial 
grammar correction” (item 4 of [1]) which is in-scope for HFDU, and apparently 
the lack of expansion confused at least one person, so I’m inclined to verify 
as HFDU with Tony’s text, unless there’s a strong case not to.

—John

[1] https://www.ietf.org/about/groups/iesg/statements/processing-rfc-errata/


On Mar 6, 2023, at 7:39 AM, Acee Lindem 
mailto:acee.i...@gmail.com>> wrote:

Hi Peter,

I agree it is not an errata. We really don’t want to set precedence of having 
published RFC text nominally improved via Errata. I’ve copied John for Errata 
resolution.

Thanks,
Acee


On Mar 6, 2023, at 4:14 AM, Peter Psenak 
mailto:ppse...@cisco.com>> wrote:

Acee,

if you ask me, I would not do anything. "IS" is correct in the text and it's 
well known.

my 2c,
Peter


On 05/03/2023 14:32, Acee Lindem wrote:
Hi Tony,
On Mar 4, 2023, at 4:42 PM, Tony Li mailto:tony...@tony.li>> 
wrote:


Hi all,

IMHO, this erratum is correct, but the proposed fix is incorrect.

In this case, the original text seeks to use ‘IS’ as an abbreviation for 
‘Intermediate System’ (i.e., router). Thus, a better fix would be:

One of the limitations of IS-IS [ISO10589] is that the length of a
TLV/sub-TLV is limited to a maximum of 255 octets.  For the FAD sub-
TLV, there are a number of sub-sub-TLVs (defined below) that are
supported.  For a given Flex-Algorithm, it is possible that the total
number of octets required to completely define a FAD exceeds the
maximum length supported by a single FAD sub-TLV.  In such cases, the
FAD MAY be split into multiple such sub-TLVs, and the content of the
multiple FAD sub-TLVs are combined to provide a complete FAD for the
Flex-Algorithm.  In such a case, the fixed portion of the FAD (see
Section 5.1) MUST be identical in all FAD sub-TLVs for a given Flex-
Algorithm from a given IS (Intermediate System).

Please note the recurrence of the use of ‘IS’ in the next sentence and again in 
the next paragraph.
Strictly speaking, the expansion is not required as IS in the context of IS-IS 
is “well-known” as per 
https://urldefense.com/v3/__https://www.rfc-editor.org/materials/abbrev.expansion.txt__;!!NEt6yMaO-gk!Gpea-h_uboqENXj9y1qHNFUDOqCRbNMUKkG5Sp1r2-kD8X7cc3819anwOcRNYutT1iR1sYOZdVtLolo$
 . However, I agree that expansion on first use is an improvement.
Thanks,
Acee

Regards,
Tony


On Mar 4, 2023, at 1:28 PM, RFC Errata System 
mailto:rfc-edi...@rfc-editor.org>> wrote:

The following errata report has been submitted for RFC9350,
"IGP Flexible Algorithm".

--
You may review the report below and at:
https://urldefense.com/v3/__https://www.rfc-editor.org/errata/eid7376__;!!NEt6yMaO-gk!Gpea-h_uboqENXj9y1qHNFUDOqCRbNMUKkG5Sp1r2-kD8X7cc3819anwOcRNYutT1iR1sYOZBstDDr4$

--
Type: Editorial
Reported by: Nikolai Malykh mailto:nmal...@protokols.ru>>

Section: 6

Original Text
-
One of the limitations of IS-IS [ISO10589] is that the length of a
TLV/sub-TLV is limited to a maximum of 255 octets.  For the FAD sub-
TLV, there are a number of sub-sub-TLVs (defined below) that are
supported.  For a given Flex-Algorithm, it is possible that the total
number of octets required to completely define a FAD exceeds the
maximum length supported by a single FAD sub-TLV.  In such cases, the
FA

Re: [Lsr] New Version Notification for draft-cheng-ospf-adjacency-suppress-00.txt

[Acee Lindem]

Hi Liyan, 

I should replied to this Email rather than your request for an IETF 116 slot. 
Please reply to this one.

I’m sorry but I don’t get this draft from a quick read. An OSPF router would 
not advertise an adjacency until the router is in FULL state. An OSPF router 
will not attain FULL state until database synchronization is complete.
The following statement from you use case is incorrect:

So, without requesting the starting router to update its LSAs, the
neighbors of the starting router may transition to "Full" state and
route the traffic through the starting router. 

Why do you think you need this extension? 


Thanks,
Acee


> On Mar 6, 2023, at 9:10 AM, Liyan Gong  wrote:
> 
> Dear All,
> We have posted a new draft 
> https://datatracker.ietf.org/doc/draft-cheng-ospf-adjacency-suppress/.
> This draft describes the extension of OSPF LLS to signal adjacency 
> suppression which is functionally similar to the SA bit of Restart TLV in 
> IS-IS.
> The purpose is to avoid the temporary blackhole when a router restarts from 
> unplanned outages.
> We are looing forward to your comments.Thanks a lot.
> 
> Best Regards,
> Liyan
> 
> 邮件原文
> 发件人：internet-drafts 
> 收件人：Changwang Lin ,Liyan Gong 
> ,Mengxiao Chen ,Weiqiang 
> Cheng 
> 抄　送: (无)
> 发送时间：2023-03-06 17:43:39
> 主题：New Version Notification for draft-cheng-ospf-adjacency-suppress-00.txt
> 
> 
> A new version of I-D, draft-cheng-ospf-adjacency-suppress-00.txt
> has been successfully submitted by Mengxiao Chen and posted to the
> IETF repository.
> 
> Name: draft-cheng-ospf-adjacency-suppress
> Revision: 00
> Title: OSPF Adjacency Suppression
> Document date: 2023-03-06
> Group: Individual Submission
> Pages: 8
> URL:
> https://www.ietf.org/archive/id/draft-cheng-ospf-adjacency-suppress-00.txt
> Status: 
> https://datatracker.ietf.org/doc/draft-cheng-ospf-adjacency-suppress/
> Htmlized:   
> https://datatracker.ietf.org/doc/html/draft-cheng-ospf-adjacency-suppress
> 
> 
> Abstract:
>This document describes a mechanism for a router to signal its
>neighbors to suppress advertising the adjacency to it until link-
>state database synchronization is complete. This minimizes transient
>routing disruption when a router restarts from unplanned outages.
> 
>   
> 
> 
> 
> The IETF Secretariat
> 
> 
> 
> Subject：New Version Notification for 
> draft-cheng-ospf-adjacency-suppress-00.txt
> 
> 
> A new version of I-D, draft-cheng-ospf-adjacency-suppress-00.txt
> has been successfully submitted by Mengxiao Chen and posted to the
> IETF repository.
> 
> Name: draft-cheng-ospf-adjacency-suppress
> Revision: 00
> Title: OSPF Adjacency Suppression
> Document date: 2023-03-06
> Group: Individual Submission
> Pages: 8
> URL:
> https://www.ietf.org/archive/id/draft-cheng-ospf-adjacency-suppress-00.txt
> Status: 
> https://datatracker.ietf.org/doc/draft-cheng-ospf-adjacency-suppress/
> Htmlized:   
> https://datatracker.ietf.org/doc/html/draft-cheng-ospf-adjacency-suppress
> 
> 
> Abstract:
>This document describes a mechanism for a router to signal its
>neighbors to suppress advertising the adjacency to it until link-
>state database synchronization is complete. This minimizes transient
>routing disruption when a router restarts from unplanned outages.
> 
>   
> 
> 
> 
> The IETF Secretariat
> 
> 
> 
> ___
> 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] Slot request for LSR IETF 116

[Acee Lindem]

+LSR

I’m sorry but I don’t get this draft from a quick read. An OSPF router would 
not advertise an adjacency until the router is in FULL state. An OSPF router 
will not attain FULL state until database synchronization is complete.
The following statement from you use case is incorrect:

 So, without requesting the starting router to update its LSAs, the
 neighbors of the starting router may transition to "Full" state and
 route the traffic through the starting router. 

Why do you think you need this extension? 


Thanks,
Acee

> On Mar 6, 2023, at 9:13 AM, Liyan Gong  wrote:
> 
> 
> Dear Yingzhen and Chairs,
> On behalf of the co-authors, I would like to request a slot for the following 
> draft,Thanks a lot.
> • draft to be presented: OSPF Adjacency Suppression, 
> https://datatracker.ietf.org/doc/draft-cheng-ospf-adjacency-suppress/
> • presenter name: Liyan Gong（gongli...@chinamobile.com）/Weiqiang 
> Cheng(chengweiqi...@chinamobile.com)
> • estimated time: 10 mins
> 
> Best Regards,
> Liyan
> 
> 
> 邮件原文
> 发件人：Yingzhen Qu  
> 收件人：lsr-chairs  ,lsr  
> 抄　送: (无)
> 发送时间：2023-03-01 02:37:11
> 主题：[Lsr] Slot request for LSR IETF 116
> 
> Dear LSR WG:
> The preliminary agenda for IETF 116 has been released, and the LSR session is 
> scheduled on Monday Session I (9:30-11:30).
> 
> Please send your presentation request to LSR WG chairs (lsr-cha...@ietf.org) 
> before the end of Monday March 13 with the following info:
> • 
> draft to be presented
> • presenter name
> • estimated time needed, including Q&A
> If there is any question, please let me know.
> 
> Thanks,
> Yingzhen
> 

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

[Lsr] [Errata Held for Document Update] RFC9350 (7376)

[RFC Errata System]

The following errata report has been held for document update 
for RFC9350, "IGP Flexible Algorithm". 

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

--
Status: Held for Document Update
Type: Editorial

Reported by: Nikolai Malykh 
Date Reported: 2023-03-04
Held by: John Scudder (IESG)

Section: 6

Original Text
-
   One of the limitations of IS-IS [ISO10589] is that the length of a
   TLV/sub-TLV is limited to a maximum of 255 octets.  For the FAD sub-
   TLV, there are a number of sub-sub-TLVs (defined below) that are
   supported.  For a given Flex-Algorithm, it is possible that the total
   number of octets required to completely define a FAD exceeds the
   maximum length supported by a single FAD sub-TLV.  In such cases, the
   FAD MAY be split into multiple such sub-TLVs, and the content of the
   multiple FAD sub-TLVs are combined to provide a complete FAD for the
   Flex-Algorithm.  In such a case, the fixed portion of the FAD (see
   Section 5.1) MUST be identical in all FAD sub-TLVs for a given Flex-
   Algorithm from a given IS.  

Corrected Text
--
   One of the limitations of IS-IS [ISO10589] is that the length of a
   TLV/sub-TLV is limited to a maximum of 255 octets.  For the FAD sub-
   TLV, there are a number of sub-sub-TLVs (defined below) that are
   supported.  For a given Flex-Algorithm, it is possible that the total
   number of octets required to completely define a FAD exceeds the
   maximum length supported by a single FAD sub-TLV.  In such cases, the
   FAD MAY be split into multiple such sub-TLVs, and the content of the
   multiple FAD sub-TLVs are combined to provide a complete FAD for the
   Flex-Algorithm.  In such a case, the fixed portion of the FAD (see
   Section 5.1) MUST be identical in all FAD sub-TLVs for a given Flex-
   Algorithm from a given IS (Intermediate System).

Notes
-
Although "IS" is listed in 
https://www.rfc-editor.org/materials/abbrev.expansion.txt as well-known, this 
evidently confused at least one reader, so it seems worth expanding on first 
use. See also 
https://mailarchive.ietf.org/arch/msg/lsr/LICQJ8U3cBAY9Z1LHMfAI4v7xRg/

--
RFC9350 (draft-ietf-lsr-flex-algo-26)
--
Title   : IGP Flexible Algorithm
Publication Date: February 2023
Author(s)   : P. Psenak, Ed., S. Hegde, C. Filsfils, K. Talaulikar, A. 
Gulko
Category: PROPOSED STANDARD
Source  : Link State Routing
Area: Routing
Stream  : IETF
Verifying Party : IESG

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

[Lsr] Fw:New Version Notification for draft-cheng-ospf-adjacency-suppress-00.txt

[Liyan Gong]

Dear All,

We have posted a new draft 
https://datatracker.ietf.org/doc/draft-cheng-ospf-adjacency-suppress/.

This draft describes the extension of OSPF LLS to signal adjacency suppression 
which is functionally similar to the SA bit of Restart TLV in IS-IS.

The purpose is to avoid the temporary blackhole when a router restarts from 
unplanned outages.

We are looing forward to your comments.Thanks a lot.



Best Regards,

Liyan



邮件原文发件人：internet-drafts 收件人：Changwang Lin 
,Liyan Gong ,Mengxiao 
Chen ,Weiqiang Cheng 抄　送: 
(无)发送时间：2023-03-06 17:43:39主题：New Version Notification for 
draft-cheng-ospf-adjacency-suppress-00.txtA new version of I-D, 
draft-cheng-ospf-adjacency-suppress-00.txthas been successfully submitted by 
Mengxiao Chen and posted to theIETF repository.Name:   
draft-cheng-ospf-adjacency-suppressRevision:00Title:OSPF 
Adjacency SuppressionDocument date:2023-03-06Group:
Individual SubmissionPages: 8URL:
https://www.ietf.org/archive/id/draft-cheng-ospf-adjacency-suppress-00.txtStatus:
 
https://datatracker.ietf.org/doc/draft-cheng-ospf-adjacency-suppress/Htmlized:  
 
https://datatracker.ietf.org/doc/html/draft-cheng-ospf-adjacency-suppressAbstract:
   This document describes a mechanism for a router to signal its   neighbors 
to suppress advertising the adjacency to it until link-   state database 
synchronization is complete. This minimizes transient   routing disruption when 
a router restarts from unplanned outages.   
   The IETF SecretariatSubject：New 
Version Notification for draft-cheng-ospf-adjacency-suppress-00.txtA new 
version of I-D, draft-cheng-ospf-adjacency-suppress-00.txthas been successfully 
submitted by Mengxiao Chen and posted to theIETF repository.Name:  
draft-cheng-ospf-adjacency-suppressRevision:00Title:OSPF 
Adjacency SuppressionDocument date:2023-03-06Group:
Individual SubmissionPages: 8URL:
https://www.ietf.org/archive/id/draft-cheng-ospf-adjacency-suppress-00.txtStatus:
 
https://datatracker.ietf.org/doc/draft-cheng-ospf-adjacency-suppress/Htmlized:  
 
https://datatracker.ietf.org/doc/html/draft-cheng-ospf-adjacency-suppressAbstract:
   This document describes a mechanism for a router to signal its   neighbors 
to suppress advertising the adjacency to it until link-   state database 
synchronization is complete. This minimizes transient   routing disruption when 
a router restarts from unplanned outages.   
   The IETF Secretariat

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

Re: [Lsr] [Editorial Errata Reported] RFC9350 (7376)

[Acee Lindem]

> On Mar 6, 2023, at 7:57 AM, John Scudder  wrote:
> 
> “Hold For Document Update” is exactly for the purpose [1] of making nominal 
> but inessential improvements. This one seems roughly on the level of “trivial 
> grammar correction” (item 4 of [1]) which is in-scope for HFDU, and 
> apparently the lack of expansion confused at least one person, so I’m 
> inclined to verify as HFDU with Tony’s text, unless there’s a strong case not 
> to. 

My point was that the RFC editor guidelines for acronym expansion would not 
require “IS” first-use expansion. However, this expansion could fall under the 
following text from https://www.rfc-editor.org/materials/abbrev.expansion.txt: 

 However, since there are so many different abbreviations and
 there is a range of knowledge among RFC readers, we tend to
 expand abbreviations in case of doubt.

So, HDFU would be fine as well. 


Thanks,
Acee



> 
> —John
> 
> [1] https://www.ietf.org/about/groups/iesg/statements/processing-rfc-errata/
> 
>> On Mar 6, 2023, at 7:39 AM, Acee Lindem  wrote:
>> 
>> 
>> Hi Peter,
>> 
>> I agree it is not an errata. We really don’t want to set precedence of 
>> having published RFC text nominally improved via Errata. I’ve copied John 
>> for Errata resolution.
>> 
>> Thanks,
>> Acee
>> 
>>> On Mar 6, 2023, at 4:14 AM, Peter Psenak  wrote:
>>> 
>>> Acee,
>>> 
>>> if you ask me, I would not do anything. "IS" is correct in the text and 
>>> it's well known.
>>> 
>>> my 2c,
>>> Peter
>>> 
>>> 
>>> On 05/03/2023 14:32, Acee Lindem wrote:
 Hi Tony,
> On Mar 4, 2023, at 4:42 PM, Tony Li  wrote:
> 
> 
> Hi all,
> 
> IMHO, this erratum is correct, but the proposed fix is incorrect.
> 
> In this case, the original text seeks to use ‘IS’ as an abbreviation for 
> ‘Intermediate System’ (i.e., router). Thus, a better fix would be:
> 
> One of the limitations of IS-IS [ISO10589] is that the length of a
> TLV/sub-TLV is limited to a maximum of 255 octets.  For the FAD sub-
> TLV, there are a number of sub-sub-TLVs (defined below) that are
> supported.  For a given Flex-Algorithm, it is possible that the total
> number of octets required to completely define a FAD exceeds the
> maximum length supported by a single FAD sub-TLV.  In such cases, the
> FAD MAY be split into multiple such sub-TLVs, and the content of the
> multiple FAD sub-TLVs are combined to provide a complete FAD for the
> Flex-Algorithm.  In such a case, the fixed portion of the FAD (see
> Section 5.1) MUST be identical in all FAD sub-TLVs for a given Flex-
> Algorithm from a given IS (Intermediate System).
> 
> Please note the recurrence of the use of ‘IS’ in the next sentence and 
> again in the next paragraph.
 Strictly speaking, the expansion is not required as IS in the context of 
 IS-IS is “well-known” as per 
 https://urldefense.com/v3/__https://www.rfc-editor.org/materials/abbrev.expansion.txt__;!!NEt6yMaO-gk!Gpea-h_uboqENXj9y1qHNFUDOqCRbNMUKkG5Sp1r2-kD8X7cc3819anwOcRNYutT1iR1sYOZdVtLolo$
  . However, I agree that expansion on first use is an improvement.
 Thanks,
 Acee
> 
> Regards,
> Tony
> 
> 
>> On Mar 4, 2023, at 1:28 PM, RFC Errata System 
>>  wrote:
>> 
>> The following errata report has been submitted for RFC9350,
>> "IGP Flexible Algorithm".
>> 
>> --
>> You may review the report below and at:
>> https://urldefense.com/v3/__https://www.rfc-editor.org/errata/eid7376__;!!NEt6yMaO-gk!Gpea-h_uboqENXj9y1qHNFUDOqCRbNMUKkG5Sp1r2-kD8X7cc3819anwOcRNYutT1iR1sYOZBstDDr4$
>> 
>> --
>> Type: Editorial
>> Reported by: Nikolai Malykh 
>> 
>> Section: 6
>> 
>> Original Text
>> -
>> One of the limitations of IS-IS [ISO10589] is that the length of a
>> TLV/sub-TLV is limited to a maximum of 255 octets.  For the FAD sub-
>> TLV, there are a number of sub-sub-TLVs (defined below) that are
>> supported.  For a given Flex-Algorithm, it is possible that the total
>> number of octets required to completely define a FAD exceeds the
>> maximum length supported by a single FAD sub-TLV.  In such cases, the
>> FAD MAY be split into multiple such sub-TLVs, and the content of the
>> multiple FAD sub-TLVs are combined to provide a complete FAD for the
>> Flex-Algorithm.  In such a case, the fixed portion of the FAD (see
>> Section 5.1) MUST be identical in all FAD sub-TLVs for a given Flex-
>> Algorithm from a given IS.
>> 
>> Corrected Text
>> --
>> One of the limitations of IS-IS [ISO10589] is that the length of a
>> TLV/sub-TLV is limited to a maximum of 255 octets.  For the FAD sub-
>> TLV, there are a number of sub-sub-TLVs (defined below) that are
>> supported.  For a given Flex-Algorithm, it is possibl

Re: [Lsr] [Editorial Errata Reported] RFC9350 (7376)

[John Scudder]

“Hold For Document Update” is exactly for the purpose [1] of making nominal but 
inessential improvements. This one seems roughly on the level of “trivial 
grammar correction” (item 4 of [1]) which is in-scope for HFDU, and apparently 
the lack of expansion confused at least one person, so I’m inclined to verify 
as HFDU with Tony’s text, unless there’s a strong case not to.

—John

[1] https://www.ietf.org/about/groups/iesg/statements/processing-rfc-errata/

On Mar 6, 2023, at 7:39 AM, Acee Lindem  wrote:


Hi Peter,

I agree it is not an errata. We really don’t want to set precedence of having 
published RFC text nominally improved via Errata. I’ve copied John for Errata 
resolution.

Thanks,
Acee

On Mar 6, 2023, at 4:14 AM, Peter Psenak  wrote:

Acee,

if you ask me, I would not do anything. "IS" is correct in the text and it's 
well known.

my 2c,
Peter


On 05/03/2023 14:32, Acee Lindem wrote:
Hi Tony,
On Mar 4, 2023, at 4:42 PM, Tony Li  wrote:


Hi all,

IMHO, this erratum is correct, but the proposed fix is incorrect.

In this case, the original text seeks to use ‘IS’ as an abbreviation for 
‘Intermediate System’ (i.e., router). Thus, a better fix would be:

One of the limitations of IS-IS [ISO10589] is that the length of a
TLV/sub-TLV is limited to a maximum of 255 octets.  For the FAD sub-
TLV, there are a number of sub-sub-TLVs (defined below) that are
supported.  For a given Flex-Algorithm, it is possible that the total
number of octets required to completely define a FAD exceeds the
maximum length supported by a single FAD sub-TLV.  In such cases, the
FAD MAY be split into multiple such sub-TLVs, and the content of the
multiple FAD sub-TLVs are combined to provide a complete FAD for the
Flex-Algorithm.  In such a case, the fixed portion of the FAD (see
Section 5.1) MUST be identical in all FAD sub-TLVs for a given Flex-
Algorithm from a given IS (Intermediate System).

Please note the recurrence of the use of ‘IS’ in the next sentence and again in 
the next paragraph.
Strictly speaking, the expansion is not required as IS in the context of IS-IS 
is “well-known” as per 
https://urldefense.com/v3/__https://www.rfc-editor.org/materials/abbrev.expansion.txt__;!!NEt6yMaO-gk!Gpea-h_uboqENXj9y1qHNFUDOqCRbNMUKkG5Sp1r2-kD8X7cc3819anwOcRNYutT1iR1sYOZdVtLolo$
 . However, I agree that expansion on first use is an improvement.
Thanks,
Acee

Regards,
Tony


On Mar 4, 2023, at 1:28 PM, RFC Errata System  wrote:

The following errata report has been submitted for RFC9350,
"IGP Flexible Algorithm".

--
You may review the report below and at:
https://urldefense.com/v3/__https://www.rfc-editor.org/errata/eid7376__;!!NEt6yMaO-gk!Gpea-h_uboqENXj9y1qHNFUDOqCRbNMUKkG5Sp1r2-kD8X7cc3819anwOcRNYutT1iR1sYOZBstDDr4$

--
Type: Editorial
Reported by: Nikolai Malykh 

Section: 6

Original Text
-
One of the limitations of IS-IS [ISO10589] is that the length of a
TLV/sub-TLV is limited to a maximum of 255 octets.  For the FAD sub-
TLV, there are a number of sub-sub-TLVs (defined below) that are
supported.  For a given Flex-Algorithm, it is possible that the total
number of octets required to completely define a FAD exceeds the
maximum length supported by a single FAD sub-TLV.  In such cases, the
FAD MAY be split into multiple such sub-TLVs, and the content of the
multiple FAD sub-TLVs are combined to provide a complete FAD for the
Flex-Algorithm.  In such a case, the fixed portion of the FAD (see
Section 5.1) MUST be identical in all FAD sub-TLVs for a given Flex-
Algorithm from a given IS.

Corrected Text
--
One of the limitations of IS-IS [ISO10589] is that the length of a
TLV/sub-TLV is limited to a maximum of 255 octets.  For the FAD sub-
TLV, there are a number of sub-sub-TLVs (defined below) that are
supported.  For a given Flex-Algorithm, it is possible that the total
number of octets required to completely define a FAD exceeds the
maximum length supported by a single FAD sub-TLV.  In such cases, the
FAD MAY be split into multiple such sub-TLVs, and the content of the
multiple FAD sub-TLVs are combined to provide a complete FAD for the
Flex-Algorithm.  In such a case, the fixed portion of the FAD (see
Section 5.1) MUST be identical in all FAD sub-TLVs for a given Flex-
Algorithm from a given IS-IS.

Notes
-
Incorrect name of protocol (IS instead IS-IS).

Instructions:
-
This erratum is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party
can log in to change the status and edit the report, if necessary.

--
RFC9350 (draft-ietf-lsr-flex-algo-26)
--
Title   : IGP Flexible Algorithm
Publication Date: February 2023
Author(s)   : P. Psenak, Ed., S. Hegde, C. Filsfils, K. Talaulikar, A. 
Gulko
Category 

Re: [Lsr] [Editorial Errata Reported] RFC9350 (7376)

[Acee Lindem]

Hi Peter, 

I agree it is not an errata. We really don’t want to set precedence of having 
published RFC text nominally improved via Errata. I’ve copied John for Errata 
resolution. 

Thanks,
Acee

> On Mar 6, 2023, at 4:14 AM, Peter Psenak  wrote:
> 
> Acee,
> 
> if you ask me, I would not do anything. "IS" is correct in the text and it's 
> well known.
> 
> my 2c,
> Peter
> 
> 
> On 05/03/2023 14:32, Acee Lindem wrote:
>> Hi Tony,
>>> On Mar 4, 2023, at 4:42 PM, Tony Li  wrote:
>>> 
>>> 
>>> Hi all,
>>> 
>>> IMHO, this erratum is correct, but the proposed fix is incorrect.
>>> 
>>> In this case, the original text seeks to use ‘IS’ as an abbreviation for 
>>> ‘Intermediate System’ (i.e., router). Thus, a better fix would be:
>>> 
>>> One of the limitations of IS-IS [ISO10589] is that the length of a
>>>  TLV/sub-TLV is limited to a maximum of 255 octets.  For the FAD sub-
>>>  TLV, there are a number of sub-sub-TLVs (defined below) that are
>>>  supported.  For a given Flex-Algorithm, it is possible that the total
>>>  number of octets required to completely define a FAD exceeds the
>>>  maximum length supported by a single FAD sub-TLV.  In such cases, the
>>>  FAD MAY be split into multiple such sub-TLVs, and the content of the
>>>  multiple FAD sub-TLVs are combined to provide a complete FAD for the
>>>  Flex-Algorithm.  In such a case, the fixed portion of the FAD (see
>>>  Section 5.1) MUST be identical in all FAD sub-TLVs for a given Flex-
>>>  Algorithm from a given IS (Intermediate System).
>>> 
>>> Please note the recurrence of the use of ‘IS’ in the next sentence and 
>>> again in the next paragraph.
>> Strictly speaking, the expansion is not required as IS in the context of 
>> IS-IS is “well-known” as per 
>> https://www.rfc-editor.org/materials/abbrev.expansion.txt. However, I agree 
>> that expansion on first use is an improvement.
>> Thanks,
>> Acee
>>> 
>>> Regards,
>>> Tony
>>> 
>>> 
 On Mar 4, 2023, at 1:28 PM, RFC Errata System  
 wrote:
 
 The following errata report has been submitted for RFC9350,
 "IGP Flexible Algorithm".
 
 --
 You may review the report below and at:
 https://www.rfc-editor.org/errata/eid7376
 
 --
 Type: Editorial
 Reported by: Nikolai Malykh 
 
 Section: 6
 
 Original Text
 -
 One of the limitations of IS-IS [ISO10589] is that the length of a
  TLV/sub-TLV is limited to a maximum of 255 octets.  For the FAD sub-
  TLV, there are a number of sub-sub-TLVs (defined below) that are
  supported.  For a given Flex-Algorithm, it is possible that the total
  number of octets required to completely define a FAD exceeds the
  maximum length supported by a single FAD sub-TLV.  In such cases, the
  FAD MAY be split into multiple such sub-TLVs, and the content of the
  multiple FAD sub-TLVs are combined to provide a complete FAD for the
  Flex-Algorithm.  In such a case, the fixed portion of the FAD (see
  Section 5.1) MUST be identical in all FAD sub-TLVs for a given Flex-
  Algorithm from a given IS.
 
 Corrected Text
 --
 One of the limitations of IS-IS [ISO10589] is that the length of a
  TLV/sub-TLV is limited to a maximum of 255 octets.  For the FAD sub-
  TLV, there are a number of sub-sub-TLVs (defined below) that are
  supported.  For a given Flex-Algorithm, it is possible that the total
  number of octets required to completely define a FAD exceeds the
  maximum length supported by a single FAD sub-TLV.  In such cases, the
  FAD MAY be split into multiple such sub-TLVs, and the content of the
  multiple FAD sub-TLVs are combined to provide a complete FAD for the
  Flex-Algorithm.  In such a case, the fixed portion of the FAD (see
  Section 5.1) MUST be identical in all FAD sub-TLVs for a given Flex-
  Algorithm from a given IS-IS.
 
 Notes
 -
 Incorrect name of protocol (IS instead IS-IS).
 
 Instructions:
 -
 This erratum is currently posted as "Reported". If necessary, please
 use "Reply All" to discuss whether it should be verified or
 rejected. When a decision is reached, the verifying party
 can log in to change the status and edit the report, if necessary.
 
 --
 RFC9350 (draft-ietf-lsr-flex-algo-26)
 --
 Title   : IGP Flexible Algorithm
 Publication Date: February 2023
 Author(s)   : P. Psenak, Ed., S. Hegde, C. Filsfils, K. 
 Talaulikar, A. Gulko
 Category: PROPOSED STANDARD
 Source  : Link State Routing
 Area: Routing
 Stream  : IETF
 Verifying Party : IESG
 
 ___
 Lsr mailing list

Re: [Lsr] [Editorial Errata Reported] RFC9350 (7376)

[Peter Psenak]

Acee,

if you ask me, I would not do anything. "IS" is correct in the text and 
it's well known.


my 2c,
Peter


On 05/03/2023 14:32, Acee Lindem wrote:

Hi Tony,


On Mar 4, 2023, at 4:42 PM, Tony Li  wrote:


Hi all,

IMHO, this erratum is correct, but the proposed fix is incorrect.

In this case, the original text seeks to use ‘IS’ as an abbreviation for 
‘Intermediate System’ (i.e., router). Thus, a better fix would be:

One of the limitations of IS-IS [ISO10589] is that the length of a
  TLV/sub-TLV is limited to a maximum of 255 octets.  For the FAD sub-
  TLV, there are a number of sub-sub-TLVs (defined below) that are
  supported.  For a given Flex-Algorithm, it is possible that the total
  number of octets required to completely define a FAD exceeds the
  maximum length supported by a single FAD sub-TLV.  In such cases, the
  FAD MAY be split into multiple such sub-TLVs, and the content of the
  multiple FAD sub-TLVs are combined to provide a complete FAD for the
  Flex-Algorithm.  In such a case, the fixed portion of the FAD (see
  Section 5.1) MUST be identical in all FAD sub-TLVs for a given Flex-
  Algorithm from a given IS (Intermediate System).

Please note the recurrence of the use of ‘IS’ in the next sentence and again in 
the next paragraph.


Strictly speaking, the expansion is not required as IS in the context of IS-IS 
is “well-known” as per 
https://www.rfc-editor.org/materials/abbrev.expansion.txt. However, I agree 
that expansion on first use is an improvement.

Thanks,
Acee




Regards,
Tony



On Mar 4, 2023, at 1:28 PM, RFC Errata System  wrote:

The following errata report has been submitted for RFC9350,
"IGP Flexible Algorithm".

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

--
Type: Editorial
Reported by: Nikolai Malykh 

Section: 6

Original Text
-
One of the limitations of IS-IS [ISO10589] is that the length of a
  TLV/sub-TLV is limited to a maximum of 255 octets.  For the FAD sub-
  TLV, there are a number of sub-sub-TLVs (defined below) that are
  supported.  For a given Flex-Algorithm, it is possible that the total
  number of octets required to completely define a FAD exceeds the
  maximum length supported by a single FAD sub-TLV.  In such cases, the
  FAD MAY be split into multiple such sub-TLVs, and the content of the
  multiple FAD sub-TLVs are combined to provide a complete FAD for the
  Flex-Algorithm.  In such a case, the fixed portion of the FAD (see
  Section 5.1) MUST be identical in all FAD sub-TLVs for a given Flex-
  Algorithm from a given IS.

Corrected Text
--
One of the limitations of IS-IS [ISO10589] is that the length of a
  TLV/sub-TLV is limited to a maximum of 255 octets.  For the FAD sub-
  TLV, there are a number of sub-sub-TLVs (defined below) that are
  supported.  For a given Flex-Algorithm, it is possible that the total
  number of octets required to completely define a FAD exceeds the
  maximum length supported by a single FAD sub-TLV.  In such cases, the
  FAD MAY be split into multiple such sub-TLVs, and the content of the
  multiple FAD sub-TLVs are combined to provide a complete FAD for the
  Flex-Algorithm.  In such a case, the fixed portion of the FAD (see
  Section 5.1) MUST be identical in all FAD sub-TLVs for a given Flex-
  Algorithm from a given IS-IS.

Notes
-
Incorrect name of protocol (IS instead IS-IS).

Instructions:
-
This erratum is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party
can log in to change the status and edit the report, if necessary.

--
RFC9350 (draft-ietf-lsr-flex-algo-26)
--
Title   : IGP Flexible Algorithm
Publication Date: February 2023
Author(s)   : P. Psenak, Ed., S. Hegde, C. Filsfils, K. Talaulikar, A. 
Gulko
Category: PROPOSED STANDARD
Source  : Link State Routing
Area: Routing
Stream  : IETF
Verifying Party : IESG

___
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





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