Re: [Lsr] Roman Danyliw's Discuss on draft-ietf-lsr-ospfv3-extended-lsa-yang-28: (with DISCUSS and COMMENT)

[Acee Lindem]

> On Feb 1, 2024, at 16:28, Yingzhen Qu  wrote:
> 
> Hi,
> 
> The configuration to enable/disable OSPFv3 Extended LSA is for migration, 
> please refer to RFC 8362 section 6 (RFC 8362 - OSPFv3 Link State 
> Advertisement (LSA) Extensibility (ietf.org) 
> ). If it's disabled, 
> the router under attack won't be able to exchange extended LSAs with other 
> routers, and new features using only extended LSAs won't work. 
> 
> How about the following changes?
> old:
>   /ospf:ospf/ospf:areas/ospf:area/extended-lsa-support
>   The ability to disable OSPFv3 Extended LSA support can result in a
>   denial of service.
> new:
>   /ospf:ospf/ospf:areas/ospf:area/extended-lsa-support
>   The ability to disable OSPFv3 Extended LSA support can result in a
>   denial of service. Any OSPFv3 extensions using only Extended LSAs won't 
> work.

No - there will not be connectivity between the OSPFv3 routers. For the draft 
that became RFC 8263, we initially had a complex interoperability mode but when 
no vendors signed up for implementation,  we simplified the specification to 
use either the base or extended LSAs for the base SPF. One could use 
sparse-mode for specific features (e.g., segment routing) but this is dependent 
on the feature configuration. 

I’ll change it to “enable or disable” since either could have this consequence. 

Thanks,
Acee


> 
> Thanks,
> Yingzhen
> 
> On Thu, Feb 1, 2024 at 9:54 AM Acee Lindem  > wrote:
>> Hi John, 
>> 
>> > On Feb 1, 2024, at 11:55 AM, John Scudder > > > wrote:
>> > 
>> > Hi Acee, Roman, all,
>> > 
>> > [top posting, hope that’s OK]
>> > 
>> > After talking with Roman about this today, what I understand his position 
>> > to be is (at least in part), since the document identifies one specific 
>> > case of a type of attack ("The ability to disable OSPFv3 Extended LSA 
>> > support can result in a denial of service”), shouldn’t it also list other 
>> > cases? What’s special about "denial of service” vs. other things such as 
>> > the ones Roman mentioned? I don’t think he was seeking an in-depth 
>> > exploration of these, just a more complete summary list. I also wonder if 
>> > the concern could equally be satisfied by removing the one special case.
>> 
>> By enabling or disabling this parameter, you can only limit exchange of 
>> OSPFv3 LSAs between OSPFv3 routers. You cannot inject compromised LSAs into 
>> the OSPFv3 routing domain through modification of this parameter alone? 
>> How could this exploit be used to: 
>> 
>>  modify network topologies to enable select traffic to avoid inspection 
>>  or
>>  treatment by security controls; route traffic in a way that it would be 
>>  subject
>>  to inspect/modification by an adversary node; or gain access to 
>>  otherwise
>>  segregated parts of the network.
>> 
>> 
>> 
>> Thanks,
>> Acee
>> 
>> 
>> 
>> > 
>> > I’m sure Roman will chime in if I’ve gotten this wrong.
>> > 
>> > Thanks,
>> > 
>> > —John
>> > 
>> >> On Jan 31, 2024, at 8:50 PM, Acee Lindem > >> > wrote:
>> >> 
>> >> 
>> >> 
>> >>> On Jan 31, 2024, at 20:14, Acee Lindem > >>> > wrote:
>> >>> 
>> >>> 
>> >>> 
>>  On Jan 31, 2024, at 19:56, Roman Danyliw via Datatracker 
>>  mailto:nore...@ietf.org>> wrote:
>>  
>>  Roman Danyliw has entered the following ballot position for
>>  draft-ietf-lsr-ospfv3-extended-lsa-yang-28: Discuss
>>  
>>  When responding, please keep the subject line intact and reply to all
>>  email addresses included in the To and CC lines. (Feel free to cut this
>>  introductory paragraph, however.)
>>  
>>  
>>  Please refer to 
>>  https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/
>>   
>>  for more information about how to handle DISCUSS and COMMENT positions.
>>  
>>  
>>  The document, along with other ballot positions, can be found here:
>>  https://datatracker.ietf.org/doc/draft-ietf-lsr-ospfv3-extended-lsa-yang/
>>  
>>  
>>  
>>  --
>>  DISCUSS:
>>  --
>>  
>>  ** Section 5.
>>  
>>  Write
>>  operations (e.g., edit-config) to these data nodes without proper
>>  protection can have a negative effect on network operations.  There
>>  are the subtrees and data nodes and their sensitivity/vulnerability:
>>  
>> /ospf:ospf/extended-lsa-support
>> /ospf:ospf/ospf:areas/ospf:area/extended-lsa-support
>> The ability to disable OSPFv3 Extended LSA support can result in a
>> denial of service.
>>  
>>  Isn’t it more than just denial of service?  In certain environments 
>>  wouldn’t
>>  the 

Re: [Lsr] Roman Danyliw's Discuss on draft-ietf-lsr-ospfv3-extended-lsa-yang-28: (with DISCUSS and COMMENT)

[Yingzhen Qu]

Hi,

The configuration to enable/disable OSPFv3 Extended LSA is for migration,
please refer to RFC 8362 section 6 (RFC 8362 - OSPFv3 Link State
Advertisement (LSA) Extensibility (ietf.org)
). If it's
disabled, the router under attack won't be able to exchange extended LSAs
with other routers, and new features using only extended LSAs won't work.

How about the following changes?
old:

  /ospf:ospf/ospf:areas/ospf:area/extended-lsa-support
  The ability to disable OSPFv3 Extended LSA support can result in a
  denial of service.

new:

  /ospf:ospf/ospf:areas/ospf:area/extended-lsa-support
  The ability to disable OSPFv3 Extended LSA support can result in a
  denial of service. Any OSPFv3 extensions using only Extended
LSAs won't work.


Thanks,

Yingzhen


On Thu, Feb 1, 2024 at 9:54 AM Acee Lindem  wrote:

> Hi John,
>
> > On Feb 1, 2024, at 11:55 AM, John Scudder  wrote:
> >
> > Hi Acee, Roman, all,
> >
> > [top posting, hope that’s OK]
> >
> > After talking with Roman about this today, what I understand his
> position to be is (at least in part), since the document identifies one
> specific case of a type of attack ("The ability to disable OSPFv3 Extended
> LSA support can result in a denial of service”), shouldn’t it also list
> other cases? What’s special about "denial of service” vs. other things such
> as the ones Roman mentioned? I don’t think he was seeking an in-depth
> exploration of these, just a more complete summary list. I also wonder if
> the concern could equally be satisfied by removing the one special case.
>
> By enabling or disabling this parameter, you can only limit exchange of
> OSPFv3 LSAs between OSPFv3 routers. You cannot inject compromised LSAs into
> the OSPFv3 routing domain through modification of this parameter alone?
> How could this exploit be used to:
>
>  modify network topologies to enable select traffic to avoid
> inspection or
>  treatment by security controls; route traffic in a way that it would
> be subject
>  to inspect/modification by an adversary node; or gain access to
> otherwise
>  segregated parts of the network.
>
>
>
> Thanks,
> Acee
>
>
>
> >
> > I’m sure Roman will chime in if I’ve gotten this wrong.
> >
> > Thanks,
> >
> > —John
> >
> >> On Jan 31, 2024, at 8:50 PM, Acee Lindem  wrote:
> >>
> >>
> >>
> >>> On Jan 31, 2024, at 20:14, Acee Lindem  wrote:
> >>>
> >>>
> >>>
>  On Jan 31, 2024, at 19:56, Roman Danyliw via Datatracker <
> nore...@ietf.org> wrote:
> 
>  Roman Danyliw has entered the following ballot position for
>  draft-ietf-lsr-ospfv3-extended-lsa-yang-28: Discuss
> 
>  When responding, please keep the subject line intact and reply to all
>  email addresses included in the To and CC lines. (Feel free to cut
> this
>  introductory paragraph, however.)
> 
> 
>  Please refer to
> https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/
>  for more information about how to handle DISCUSS and COMMENT
> positions.
> 
> 
>  The document, along with other ballot positions, can be found here:
> 
> https://datatracker.ietf.org/doc/draft-ietf-lsr-ospfv3-extended-lsa-yang/
> 
> 
> 
>  --
>  DISCUSS:
>  --
> 
>  ** Section 5.
> 
>  Write
>  operations (e.g., edit-config) to these data nodes without proper
>  protection can have a negative effect on network operations.  There
>  are the subtrees and data nodes and their sensitivity/vulnerability:
> 
> /ospf:ospf/extended-lsa-support
> /ospf:ospf/ospf:areas/ospf:area/extended-lsa-support
> The ability to disable OSPFv3 Extended LSA support can result in a
> denial of service.
> 
>  Isn’t it more than just denial of service?  In certain environments
> wouldn’t
>  the ability to modify OSPF Extended LSA configurations enable an
> attacker to:
>  modify network topologies to enable select traffic to avoid
> inspection or
>  treatment by security controls; route traffic in a way that it would
> be subject
>  to inspect/modification by an adversary node; or gain access to
> otherwise
>  segregated parts of the network.
> >>>
> >>> Only if they were able to craft extended LSAs on behalf of the
> original as well as
> >>> modify the YANG configuration added by this document. I didn’t think
> we’d have to
> >>> reiterate all the possible protocol attacks for every incremental
> enhancement.
> >>
> >> Furthermore, no one is going to use the support of extended LSAs to
> isolate OSPFv3 domains
> >> from one another. The configuration is to control migration to the
> extended LSA encodings.
> >> Please see RFC 8362 for more information on OSPFv3 Extended LSAs.
> >>
> >> Acee
> >>
> >>
> >>
> 

[Lsr] I-D Action: draft-ietf-lsr-flooding-topo-min-degree-09.txt

[internet-drafts]

Internet-Draft draft-ietf-lsr-flooding-topo-min-degree-09.txt is now
available. It is a work item of the Link State Routing (LSR) WG of the IETF.

   Title:   Flooding Topology Minimum Degree Algorithm
   Authors: Huaimo Chen
Mehmet Toy
Yi Yang
Aijun Wang
Xufeng Liu
Yanhe Fan
Lei Liu
   Name:draft-ietf-lsr-flooding-topo-min-degree-09.txt
   Pages:   12
   Dates:   2024-02-01

Abstract:

   This document proposes an algorithm for a node to compute a flooding
   topology, which is a subgraph of the complete topology per underline
   physical network.  When every node in an area automatically
   calculates a flooding topology by using a same algorithm and floods
   the link states using the flooding topology, the amount of flooding
   traffic in the network is greatly reduced.  This would reduce
   convergence time with a more stable and optimized routing
   environment.

The IETF datatracker status page for this Internet-Draft is:
https://datatracker.ietf.org/doc/draft-ietf-lsr-flooding-topo-min-degree/

There is also an HTMLized version available at:
https://datatracker.ietf.org/doc/html/draft-ietf-lsr-flooding-topo-min-degree-09

A diff from the previous version is available at:
https://author-tools.ietf.org/iddiff?url2=draft-ietf-lsr-flooding-topo-min-degree-09

Internet-Drafts are also available by rsync at:
rsync.ietf.org::internet-drafts


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

Re: [Lsr] AD review of draft-ietf-lsr-isis-fast-flooding-05

[Les Ginsberg (ginsberg)]

Acee -

So in 6.2.1.1 you propose to change:

" By sending the Receive Window sub-TLV..."

To

" By sending the Burst Size sub-TLV..."

I agree with that change. 
Bruno - what do you think?

In 6.2.2.2 you propose to change:

" In order for the LSP Receive Window to be a useful parameter, an LSP
   transmitter needs to be able to keep track of the number of un-
   acknowledged LSPs it has sent to a given LSP receiver."

To 

" In order for the LSP Burst Size to be a useful parameter, an LSP
   transmitter needs to be able to keep track of the number of un-
   acknowledged LSPs it has sent to a given LSP receiver."

I don’t agree with this.

6.2.1.1 has text specific for receiving LSPs " without an intervening delay".
6.2.2.2 does not have that text - though maybe it should.

I think to fully address your concern, we need to make 6.2.1.1 and 6.2.2.2 more 
analogous - which will require some additional changes.
I am open to this - Bruno - what do you think?

I also agree with changing "Receive Window sub-TLV" to " LSP Receive Window 
sub-TLV". Definitely improves consistency in naming.

   Les


> -Original Message-
> From: Lsr  On Behalf Of Acee Lindem
> Sent: Thursday, February 1, 2024 9:42 AM
> To: Les Ginsberg (ginsberg) 
> Cc: DECRAENE Bruno INNOV/NET ; John
> Scudder ; lsr ; Tony Li ;
> gsoli...@protonmail.com; Antoni Przygienda ; Gunter van
> de Velde (Nokia) ; Marek Karasek
> (mkarasek) 
> Subject: Re: [Lsr] AD review of draft-ietf-lsr-isis-fast-flooding-05
> 
> 
> 
> > On Feb 1, 2024, at 12:33 PM, Les Ginsberg (ginsberg)
>  wrote:
> >
> > Acee -
> >
> >>> ---
> >>> //Acee
> >>>
> >>> A bigger issue from that historical artifact is that some text refers to 
> >>> "LSP
> >> Burst Window" when they should refer to the "new" (from -01) "Receive
> >> Window sub-TLV". That's a bigger issue as "in letter" this may be seen as
> >> technical change (even if "in spirit" the Flow Control Receive Window
> logically
> >> refers to the Receive Window sub-TLV)
> >>> This requires the following changes in the 6.2.1 "Flow control" section:
> >>
> >> I see that the changes are already in place in -06. Note that I think you
> should
> >> rename “Receive Window” to “LSP Burst Window” for consistency.  In
> reading
> >> the guidance in section 6.2.1, It seems to me that this should have been
> “LSP
> >> Receive Window” all along. We are not changing the semantics of "LSP
> Burst
> >> Window" or "LSP Receive Window”.
> >>
> >> I’d be interested in what the other co-authors think (especially Les ).
> >
> > [LES:] It seems to me you are confusing "Burst" and "Receive".
> >
> > When we discuss fast-flooding we tend to focus on the "major incidents"
> e.g., a node with 1000 neighbors goes down - we are likely to need to flood
> 1000 LSPs.
> > "Burst" isn't very useful here because the Burst Size (was Burst Window) is
> small compared to the total number of LSPs that need to be flooded as quickly
> as possible.
> >
> > But far more common are the "minor incidents" where a single link goes
> down - where a small number (typically 2) LSPs need to be flooded - or a 
> single
> node with a modest number of neighbors goes down where the number of
> LSPs which will be flooded is still modest (5 or 10 or 20). In these cases, 
> being
> able to flood a "burst" is worthwhile because it means we can flood all the
> LSPs associated with a topology change more quickly - meaning fewer SPFs
> need to be executed. This notion was first highlighted 20 years ago when
> "fast-convergence" work was done.
> >
> > But the "Burst Size" is certainly expected to be significantly smaller than 
> > the
> "Receive Window" - and the latter logically includes the LSPs received as 
> part of
> a Burst.
> >
> > So I don’t see that what you are suggesting makes sense.
> 
> I’m talking about -06 changes to section 6.2.1.1 and 6.2.1.2 to reference
> “Receive Window” rather than “LSP Burst”. Please look at these.
> 
> 
> Thanks,
> Acee
> 
> 
> 
> >
> > Let me know if I have misunderstood your point.
> >
> >   Les
> >
> >>
> >> 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
___
Lsr mailing list
Lsr@ietf.org
https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] Roman Danyliw's Discuss on draft-ietf-lsr-ospfv3-extended-lsa-yang-28: (with DISCUSS and COMMENT)

[Acee Lindem]

Hi John, 

> On Feb 1, 2024, at 11:55 AM, John Scudder  wrote:
> 
> Hi Acee, Roman, all,
> 
> [top posting, hope that’s OK]
> 
> After talking with Roman about this today, what I understand his position to 
> be is (at least in part), since the document identifies one specific case of 
> a type of attack ("The ability to disable OSPFv3 Extended LSA support can 
> result in a denial of service”), shouldn’t it also list other cases? What’s 
> special about "denial of service” vs. other things such as the ones Roman 
> mentioned? I don’t think he was seeking an in-depth exploration of these, 
> just a more complete summary list. I also wonder if the concern could equally 
> be satisfied by removing the one special case.

By enabling or disabling this parameter, you can only limit exchange of OSPFv3 
LSAs between OSPFv3 routers. You cannot inject compromised LSAs into the OSPFv3 
routing domain through modification of this parameter alone? 
How could this exploit be used to: 

 modify network topologies to enable select traffic to avoid inspection or
 treatment by security controls; route traffic in a way that it would be 
 subject
 to inspect/modification by an adversary node; or gain access to otherwise
 segregated parts of the network.



Thanks,
Acee



> 
> I’m sure Roman will chime in if I’ve gotten this wrong.
> 
> Thanks,
> 
> —John
> 
>> On Jan 31, 2024, at 8:50 PM, Acee Lindem  wrote:
>> 
>> 
>> 
>>> On Jan 31, 2024, at 20:14, Acee Lindem  wrote:
>>> 
>>> 
>>> 
 On Jan 31, 2024, at 19:56, Roman Danyliw via Datatracker 
  wrote:
 
 Roman Danyliw has entered the following ballot position for
 draft-ietf-lsr-ospfv3-extended-lsa-yang-28: Discuss
 
 When responding, please keep the subject line intact and reply to all
 email addresses included in the To and CC lines. (Feel free to cut this
 introductory paragraph, however.)
 
 
 Please refer to 
 https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/
  
 for more information about how to handle DISCUSS and COMMENT positions.
 
 
 The document, along with other ballot positions, can be found here:
 https://datatracker.ietf.org/doc/draft-ietf-lsr-ospfv3-extended-lsa-yang/
 
 
 
 --
 DISCUSS:
 --
 
 ** Section 5.
 
 Write
 operations (e.g., edit-config) to these data nodes without proper
 protection can have a negative effect on network operations.  There
 are the subtrees and data nodes and their sensitivity/vulnerability:
 
/ospf:ospf/extended-lsa-support
/ospf:ospf/ospf:areas/ospf:area/extended-lsa-support
The ability to disable OSPFv3 Extended LSA support can result in a
denial of service.
 
 Isn’t it more than just denial of service?  In certain environments 
 wouldn’t
 the ability to modify OSPF Extended LSA configurations enable an attacker 
 to:
 modify network topologies to enable select traffic to avoid inspection or
 treatment by security controls; route traffic in a way that it would be 
 subject
 to inspect/modification by an adversary node; or gain access to otherwise
 segregated parts of the network.
>>> 
>>> Only if they were able to craft extended LSAs on behalf of the original as 
>>> well as
>>> modify the YANG configuration added by this document. I didn’t think we’d 
>>> have to
>>> reiterate all the possible protocol attacks for every incremental 
>>> enhancement.
>> 
>> Furthermore, no one is going to use the support of extended LSAs to isolate 
>> OSPFv3 domains 
>> from one another. The configuration is to control migration to the extended 
>> LSA encodings.
>> Please see RFC 8362 for more information on OSPFv3 Extended LSAs.  
>> 
>> Acee
>> 
>> 
>> 
>> 
>> 
>>> 
>>> Acee
>>> 
>>> 
>>> 
 
 
 --
 COMMENT:
 --
 
 As an editorial note, I would have benefit from some narrative prose on 
 the data model.
>> 
>> ___
>> Lsr mailing list
>> Lsr@ietf.org
>> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/lsr__;!!NEt6yMaO-gk!CSaaziWFGrg6dv81sm55-XN-CP5eUEsFoeObIEuQzH8mYmJPURb3VboumvFzwTwOiHyiHP8O67tleiE$
> 

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

Re: [Lsr] AD review of draft-ietf-lsr-isis-fast-flooding-05

[Acee Lindem]

Hi Bruno, 

See inline. 

> On Feb 1, 2024, at 12:30 PM, bruno.decra...@orange.com wrote:
> 
> Hi Acee,
> 
> Thanks for your quick feedback. Please see inline [Bruno2]
> 
>> From: Acee Lindem 
>> 
>> Hi Bruno,
>> 
>> Thanks for the work on John’s review comments. See inline.
>> 
>> 
>>> On Feb 1, 2024, at 09:38, bruno.decra...@orange.com wrote:
>>> 
>>> [+Acee as I'm proposing a change which could be seen as a technical
>>> change. Please looks for //Acee ]
>>> 
>>> Hi John,
>>> 
>>> Many thanks for your careful review, your comments and your propositions.
>>> I'll upload -06 within minutes.
>>> 
>>> Please see inline [Bruno]
>>> 
>>> 
 From: John Scudder 
 Sent: Thursday, January 25, 2024 6:52 PM
 
 Hi Authors, WG,
 
 Thanks for this document.
 
 I’ve supplied my questions and comments in the form of an edited copy of 
 the draft. Minor editorial suggestions I’ve made in place without further 
 comment, more substantive questions and comments are done in-line and 
 prefixed with “jgs:”. You can use your favorite diff tool to review them; 
 I’ve attached the iddiff output for your convenience if you’d like to use 
 it. I’ve also pasted a traditional diff below in case you want to use it 
 for in-line reply.
>>> 
>>> [Bruno] Ack. Minor editorial comments should be included -06
>>> 
 I’ve also requested a TSV early review of the document.
>>> 
>>> [Bruno] Thank you.
>>> 
 —John
 
 --- draft-ietf-lsr-isis-fast-flooding-05.txt   2024-01-24 
 19:46:21.0 -0500
 +++ draft-ietf-lsr-isis-fast-flooding-05-jgs-comments.txt  2024-01-25 
 12:43:39.0 -0500
 @@ -285,6 +285,9 @@
 4.1.  LSP Burst Window sub-TLV
 
 The LSP Burst Window sub-TLV advertises the maximum number of LSPs
 +--
 +jgs: should this say "maximum number of un-acknowledged LSPs"?
>>> 
>>> 
>>> [Bruno] Thinking about this, I don't believe so.
>>> The receiver is receiving LSPs. It does not matter for the receiver whether 
>>> they have been acknowledged not.
>>> Also the number of un-acknowledged LSPs is tracked by the flow control 
>>> algorithm. The LSP Burst Window is more general and may be used by an 
>>> implementation not implementing flow control.
>>> 
>>> That being said, your comment is logical given some errors in the draft and 
>>> the use of a sub-optimal name.
>>> So instead of applying your proposed resolution, we are proposing the 
>>> following resolution:
>>> 
>>> 
>>> 
>>> OLD:  4.1 LSP Burst Window sub-TLV
>>> NEW: 4.1 LSP Burst Size sub-TLV
>>> Motivation: the term "Window" is being used by the flow control
>>> algorithm. Re-using the same term is incorrect in this case and a
>>> source of incomprehension for the reader. The error is coming from an
>>> historical artefact before the addition of the "4.6 Receive Window
>>> sub-TLV" in draft version -01
>>> 
>>> Obviously, the change needs to be replicated in the whole document.
>>> 
>>> 
>>> In §4.2
>>> OLD:  The LSP Transmission Interval sub-TLV advertises the minimum
>>> interval, in micro-seconds, between LSPs arrivals which can be received on 
>>> this interface, after the maximum number of un-acknowledged LSPs have been 
>>> sent.
>>> NEW:The LSP Transmission Interval sub-TLV advertises the minimum interval, 
>>> in micro-seconds, between LSPs arrivals which can be sustained on this 
>>> receiving interface.
>>> .
>>> 
>>> 
>>> In §6.2.1.1
>>> OLD:  After having sent a full burst of un-acknowledged LSPs, it MUST send 
>>> the subsequent LSPs with an LSP Transmission Interval between LSP 
>>> transmissions.
>>> NEW: After having sent a full burst of LSPs, it MUST send the subsequent 
>>> LSPs with a minimum of LSP Transmission Interval between LSP transmissions..
>>> 
>>> (I would assume that the above text was the main reason for your
>>> comment, as indeed " un-acknowledged LSPs " was explicitly stated
>>> 
>>> ---
>>> //Acee
>>> 
>>> A bigger issue from that historical artifact is that some text refers
>>> to "LSP Burst Window" when they should refer to the "new" (from -01) 
>>> "Receive Window sub-TLV". That's a bigger issue as "in letter" this may be 
>>> seen as technical change (even if "in spirit" the Flow Control Receive 
>>> Window logically refers to the Receive Window sub-TLV) This requires the 
>>> following changes in the 6.2.1 "Flow control" section:
>> 
>> I see that the changes are already in place in -06.
> 
> [Bruno2] Yes change are in place in -06. Diff are small and easy to see so I 
> think it's better to discuss on the real document.
> 
>> Note that I think you should rename “Receive Window” to “LSP Burst Window” 
>> for consistency.
> 
> [Bruno2] I would assume that you mean renaming “Receive Window” to “LSP 
> Receive Window”. If so, I had though the same when doing this -06 but on the 
> other hand a longer name is harder to read in sentences. More "consistency" 
> also mean less distinction between names and given that I already 

Re: [Lsr] AD review of draft-ietf-lsr-isis-fast-flooding-05

[Acee Lindem]

> On Feb 1, 2024, at 12:33 PM, Les Ginsberg (ginsberg) 
>  wrote:
> 
> Acee -
> 
>>> ---
>>> //Acee
>>> 
>>> A bigger issue from that historical artifact is that some text refers to 
>>> "LSP
>> Burst Window" when they should refer to the "new" (from -01) "Receive
>> Window sub-TLV". That's a bigger issue as "in letter" this may be seen as
>> technical change (even if "in spirit" the Flow Control Receive Window 
>> logically
>> refers to the Receive Window sub-TLV)
>>> This requires the following changes in the 6.2.1 "Flow control" section:
>> 
>> I see that the changes are already in place in -06. Note that I think you 
>> should
>> rename “Receive Window” to “LSP Burst Window” for consistency.  In reading
>> the guidance in section 6.2.1, It seems to me that this should have been “LSP
>> Receive Window” all along. We are not changing the semantics of "LSP Burst
>> Window" or "LSP Receive Window”.
>> 
>> I’d be interested in what the other co-authors think (especially Les ).
> 
> [LES:] It seems to me you are confusing "Burst" and "Receive".
> 
> When we discuss fast-flooding we tend to focus on the "major incidents" e.g., 
> a node with 1000 neighbors goes down - we are likely to need to flood 1000 
> LSPs.
> "Burst" isn't very useful here because the Burst Size (was Burst Window) is 
> small compared to the total number of LSPs that need to be flooded as quickly 
> as possible.
> 
> But far more common are the "minor incidents" where a single link goes down - 
> where a small number (typically 2) LSPs need to be flooded - or a single node 
> with a modest number of neighbors goes down where the number of LSPs which 
> will be flooded is still modest (5 or 10 or 20). In these cases, being able 
> to flood a "burst" is worthwhile because it means we can flood all the LSPs 
> associated with a topology change more quickly - meaning fewer SPFs need to 
> be executed. This notion was first highlighted 20 years ago when 
> "fast-convergence" work was done.
> 
> But the "Burst Size" is certainly expected to be significantly smaller than 
> the "Receive Window" - and the latter logically includes the LSPs received as 
> part of a Burst.
> 
> So I don’t see that what you are suggesting makes sense.

I’m talking about -06 changes to section 6.2.1.1 and 6.2.1.2 to reference 
“Receive Window” rather than “LSP Burst”. Please look at these. 


Thanks,
Acee



> 
> Let me know if I have misunderstood your point.
> 
>   Les
> 
>> 
>> 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] AD review of draft-ietf-lsr-isis-fast-flooding-05

[Les Ginsberg (ginsberg)]

Acee -

> > ---
> > //Acee
> >
> > A bigger issue from that historical artifact is that some text refers to 
> > "LSP
> Burst Window" when they should refer to the "new" (from -01) "Receive
> Window sub-TLV". That's a bigger issue as "in letter" this may be seen as
> technical change (even if "in spirit" the Flow Control Receive Window 
> logically
> refers to the Receive Window sub-TLV)
> > This requires the following changes in the 6.2.1 "Flow control" section:
> 
> I see that the changes are already in place in -06. Note that I think you 
> should
> rename “Receive Window” to “LSP Burst Window” for consistency.  In reading
> the guidance in section 6.2.1, It seems to me that this should have been “LSP
> Receive Window” all along. We are not changing the semantics of "LSP Burst
> Window" or "LSP Receive Window”.
> 
> I’d be interested in what the other co-authors think (especially Les ).

[LES:] It seems to me you are confusing "Burst" and "Receive".

When we discuss fast-flooding we tend to focus on the "major incidents" e.g., a 
node with 1000 neighbors goes down - we are likely to need to flood 1000 LSPs.
"Burst" isn't very useful here because the Burst Size (was Burst Window) is 
small compared to the total number of LSPs that need to be flooded as quickly 
as possible.

But far more common are the "minor incidents" where a single link goes down - 
where a small number (typically 2) LSPs need to be flooded - or a single node 
with a modest number of neighbors goes down where the number of LSPs which will 
be flooded is still modest (5 or 10 or 20). In these cases, being able to flood 
a "burst" is worthwhile because it means we can flood all the LSPs associated 
with a topology change more quickly - meaning fewer SPFs need to be executed. 
This notion was first highlighted 20 years ago when "fast-convergence" work was 
done.

But the "Burst Size" is certainly expected to be significantly smaller than the 
"Receive Window" - and the latter logically includes the LSPs received as part 
of a Burst.

So I don’t see that what you are suggesting makes sense.

Let me know if I have misunderstood your point.

   Les

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

Re: [Lsr] AD review of draft-ietf-lsr-isis-fast-flooding-05

[bruno . decraene]

Hi Acee,

Thanks for your quick feedback. Please see inline [Bruno2]

> From: Acee Lindem 
>
> Hi Bruno,
>
> Thanks for the work on John’s review comments. See inline.
>
>
> > On Feb 1, 2024, at 09:38, bruno.decra...@orange.com wrote:
> >
> > [+Acee as I'm proposing a change which could be seen as a technical
> > change. Please looks for //Acee ]
> >
> > Hi John,
> >
> > Many thanks for your careful review, your comments and your propositions.
> > I'll upload -06 within minutes.
> >
> > Please see inline [Bruno]
> >
> >
> >> From: John Scudder 
> >> Sent: Thursday, January 25, 2024 6:52 PM
> >>
> >> Hi Authors, WG,
> >>
> >> Thanks for this document.
> >>
> >> I’ve supplied my questions and comments in the form of an edited copy of 
> >> the draft. Minor editorial suggestions I’ve made in place without further 
> >> comment, more substantive questions and comments are done in-line and 
> >> prefixed with “jgs:”. You can use your favorite diff tool to review them; 
> >> I’ve attached the iddiff output for your convenience if you’d like to use 
> >> it. I’ve also pasted a traditional diff below in case you want to use it 
> >> for in-line reply.
> >
> > [Bruno] Ack. Minor editorial comments should be included -06
> >
> >> I’ve also requested a TSV early review of the document.
> >
> > [Bruno] Thank you.
> >
> >> —John
> >>
> >> --- draft-ietf-lsr-isis-fast-flooding-05.txt   2024-01-24 
> >> 19:46:21.0 -0500
> >> +++ draft-ietf-lsr-isis-fast-flooding-05-jgs-comments.txt  2024-01-25 
> >> 12:43:39.0 -0500
> >> @@ -285,6 +285,9 @@
> >> 4.1.  LSP Burst Window sub-TLV
> >>
> >> The LSP Burst Window sub-TLV advertises the maximum number of LSPs
> >> +--
> >> +jgs: should this say "maximum number of un-acknowledged LSPs"?
> >
> >
> > [Bruno] Thinking about this, I don't believe so.
> > The receiver is receiving LSPs. It does not matter for the receiver whether 
> > they have been acknowledged not.
> > Also the number of un-acknowledged LSPs is tracked by the flow control 
> > algorithm. The LSP Burst Window is more general and may be used by an 
> > implementation not implementing flow control.
> >
> > That being said, your comment is logical given some errors in the draft and 
> > the use of a sub-optimal name.
> > So instead of applying your proposed resolution, we are proposing the 
> > following resolution:
> >
> >
> >
> > OLD:  4.1 LSP Burst Window sub-TLV
> > NEW: 4.1 LSP Burst Size sub-TLV
> > Motivation: the term "Window" is being used by the flow control
> > algorithm. Re-using the same term is incorrect in this case and a
> > source of incomprehension for the reader. The error is coming from an
> > historical artefact before the addition of the "4.6 Receive Window
> > sub-TLV" in draft version -01
> >
> > Obviously, the change needs to be replicated in the whole document.
> >
> >
> > In §4.2
> > OLD:  The LSP Transmission Interval sub-TLV advertises the minimum
> > interval, in micro-seconds, between LSPs arrivals which can be received on 
> > this interface, after the maximum number of un-acknowledged LSPs have been 
> > sent.
> > NEW:The LSP Transmission Interval sub-TLV advertises the minimum interval, 
> > in micro-seconds, between LSPs arrivals which can be sustained on this 
> > receiving interface.
> > .
> >
> >
> > In §6.2.1.1
> > OLD:  After having sent a full burst of un-acknowledged LSPs, it MUST send 
> > the subsequent LSPs with an LSP Transmission Interval between LSP 
> > transmissions.
> > NEW: After having sent a full burst of LSPs, it MUST send the subsequent 
> > LSPs with a minimum of LSP Transmission Interval between LSP transmissions..
> >
> > (I would assume that the above text was the main reason for your
> > comment, as indeed " un-acknowledged LSPs " was explicitly stated
> >
> > ---
> > //Acee
> >
> > A bigger issue from that historical artifact is that some text refers
> > to "LSP Burst Window" when they should refer to the "new" (from -01) 
> > "Receive Window sub-TLV". That's a bigger issue as "in letter" this may be 
> > seen as technical change (even if "in spirit" the Flow Control Receive 
> > Window logically refers to the Receive Window sub-TLV) This requires the 
> > following changes in the 6.2.1 "Flow control" section:
>
> I see that the changes are already in place in -06.

[Bruno2] Yes change are in place in -06. Diff are small and easy to see so I 
think it's better to discuss on the real document.

>  Note that I think you should rename “Receive Window” to “LSP Burst Window” 
> for consistency.

[Bruno2] I would assume that you mean renaming “Receive Window” to “LSP Receive 
Window”. If so, I had though the same when doing this -06 but on the other hand 
a longer name is harder to read in sentences. More "consistency" also mean less 
distinction between names and given that I already managed to confuse the two 
names, that may be debatable. So I would welcome more feedback on this.

If you did meant "LSP Burst Window", I don't think that I 

Re: [Lsr] Roman Danyliw's Discuss on draft-ietf-lsr-ospfv3-extended-lsa-yang-28: (with DISCUSS and COMMENT)

[John Scudder]

Hi Acee, Roman, all,

[top posting, hope that’s OK]

After talking with Roman about this today, what I understand his position to be 
is (at least in part), since the document identifies one specific case of a 
type of attack ("The ability to disable OSPFv3 Extended LSA support can result 
in a denial of service”), shouldn’t it also list other cases? What’s special 
about "denial of service” vs. other things such as the ones Roman mentioned? I 
don’t think he was seeking an in-depth exploration of these, just a more 
complete summary list. I also wonder if the concern could equally be satisfied 
by removing the one special case.

I’m sure Roman will chime in if I’ve gotten this wrong.

Thanks,

—John

> On Jan 31, 2024, at 8:50 PM, Acee Lindem  wrote:
> 
> 
> 
>> On Jan 31, 2024, at 20:14, Acee Lindem  wrote:
>> 
>> 
>> 
>>> On Jan 31, 2024, at 19:56, Roman Danyliw via Datatracker  
>>> wrote:
>>> 
>>> Roman Danyliw has entered the following ballot position for
>>> draft-ietf-lsr-ospfv3-extended-lsa-yang-28: Discuss
>>> 
>>> When responding, please keep the subject line intact and reply to all
>>> email addresses included in the To and CC lines. (Feel free to cut this
>>> introductory paragraph, however.)
>>> 
>>> 
>>> Please refer to 
>>> https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/
>>>  
>>> for more information about how to handle DISCUSS and COMMENT positions.
>>> 
>>> 
>>> The document, along with other ballot positions, can be found here:
>>> https://datatracker.ietf.org/doc/draft-ietf-lsr-ospfv3-extended-lsa-yang/
>>> 
>>> 
>>> 
>>> --
>>> DISCUSS:
>>> --
>>> 
>>> ** Section 5.
>>> 
>>>  Write
>>>  operations (e.g., edit-config) to these data nodes without proper
>>>  protection can have a negative effect on network operations.  There
>>>  are the subtrees and data nodes and their sensitivity/vulnerability:
>>> 
>>> /ospf:ospf/extended-lsa-support
>>> /ospf:ospf/ospf:areas/ospf:area/extended-lsa-support
>>> The ability to disable OSPFv3 Extended LSA support can result in a
>>> denial of service.
>>> 
>>> Isn’t it more than just denial of service?  In certain environments wouldn’t
>>> the ability to modify OSPF Extended LSA configurations enable an attacker 
>>> to:
>>> modify network topologies to enable select traffic to avoid inspection or
>>> treatment by security controls; route traffic in a way that it would be 
>>> subject
>>> to inspect/modification by an adversary node; or gain access to otherwise
>>> segregated parts of the network.
>> 
>> Only if they were able to craft extended LSAs on behalf of the original as 
>> well as
>> modify the YANG configuration added by this document. I didn’t think we’d 
>> have to
>> reiterate all the possible protocol attacks for every incremental 
>> enhancement.
> 
> Furthermore, no one is going to use the support of extended LSAs to isolate 
> OSPFv3 domains 
> from one another. The configuration is to control migration to the extended 
> LSA encodings.
> Please see RFC 8362 for more information on OSPFv3 Extended LSAs.  
> 
> Acee
> 
> 
> 
> 
> 
>> 
>> Acee
>> 
>> 
>> 
>>> 
>>> 
>>> --
>>> COMMENT:
>>> --
>>> 
>>> As an editorial note, I would have benefit from some narrative prose on the 
>>> data model.
> 
> ___
> Lsr mailing list
> Lsr@ietf.org
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/lsr__;!!NEt6yMaO-gk!CSaaziWFGrg6dv81sm55-XN-CP5eUEsFoeObIEuQzH8mYmJPURb3VboumvFzwTwOiHyiHP8O67tleiE$

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

Re: [Lsr] AD review of draft-ietf-lsr-isis-fast-flooding-05

[Acee Lindem]

Hi Bruno, 

Thanks for the work on John’s review comments. See inline. 


> On Feb 1, 2024, at 09:38, bruno.decra...@orange.com wrote:
> 
> [+Acee as I'm proposing a change which could be seen as a technical change. 
> Please looks for //Acee ]
> 
> Hi John, 
> 
> Many thanks for your careful review, your comments and your propositions.
> I'll upload -06 within minutes.
> 
> Please see inline [Bruno]
> 
> 
>> From: John Scudder  
>> Sent: Thursday, January 25, 2024 6:52 PM
>> 
>> Hi Authors, WG,
>> 
>> Thanks for this document.
>> 
>> I’ve supplied my questions and comments in the form of an edited copy of the 
>> draft. Minor editorial suggestions I’ve made in place without further 
>> comment, more substantive questions and comments are done in-line and 
>> prefixed with “jgs:”. You can use your favorite diff tool to review them; 
>> I’ve attached the iddiff output for your convenience if you’d like to use 
>> it. I’ve also pasted a traditional diff below in case you want to use it for 
>> in-line reply.
> 
> [Bruno] Ack. Minor editorial comments should be included -06
> 
>> I’ve also requested a TSV early review of the document.
> 
> [Bruno] Thank you.
> 
>> —John
>> 
>> --- draft-ietf-lsr-isis-fast-flooding-05.txt 2024-01-24 19:46:21.0 
>> -0500
>> +++ draft-ietf-lsr-isis-fast-flooding-05-jgs-comments.txt2024-01-25 
>> 12:43:39.0 -0500
>> @@ -285,6 +285,9 @@
>> 4.1.  LSP Burst Window sub-TLV
>> 
>> The LSP Burst Window sub-TLV advertises the maximum number of LSPs
>> +--
>> +jgs: should this say "maximum number of un-acknowledged LSPs"?
> 
> 
> [Bruno] Thinking about this, I don't believe so.
> The receiver is receiving LSPs. It does not matter for the receiver whether 
> they have been acknowledged not.
> Also the number of un-acknowledged LSPs is tracked by the flow control 
> algorithm. The LSP Burst Window is more general and may be used by an 
> implementation not implementing flow control.
> 
> That being said, your comment is logical given some errors in the draft and 
> the use of a sub-optimal name.
> So instead of applying your proposed resolution, we are proposing the 
> following resolution:
> 
> 
> 
> OLD:  4.1 LSP Burst Window sub-TLV
> NEW: 4.1 LSP Burst Size sub-TLV
> Motivation: the term "Window" is being used by the flow control algorithm. 
> Re-using the same term is incorrect in this case and a source of 
> incomprehension for the reader. The error is coming from an historical 
> artefact before the addition of the "4.6 Receive Window sub-TLV" in draft 
> version -01
> 
> Obviously, the change needs to be replicated in the whole document.
> 
> 
> In §4.2
> OLD:  The LSP Transmission Interval sub-TLV advertises the minimum interval, 
> in micro-seconds, between LSPs arrivals which can be received on this 
> interface, 
> after the maximum number of un-acknowledged LSPs have been sent.
> NEW:The LSP Transmission Interval sub-TLV advertises the minimum interval, in 
> micro-seconds, between LSPs arrivals which can be sustained on this receiving 
> interface.
> .
> 
> 
> In §6.2.1.1
> OLD:  After having sent a full burst of un-acknowledged LSPs, it MUST send 
> the subsequent LSPs with an LSP Transmission Interval between LSP 
> transmissions.
> NEW: After having sent a full burst of LSPs, it MUST send the subsequent LSPs 
> with a minimum of LSP Transmission Interval between LSP transmissions..
> 
> (I would assume that the above text was the main reason for your comment, as 
> indeed " un-acknowledged LSPs " was explicitly stated 
> 
> ---
> //Acee
> 
> A bigger issue from that historical artifact is that some text refers to "LSP 
> Burst Window" when they should refer to the "new" (from -01) "Receive Window 
> sub-TLV". That's a bigger issue as "in letter" this may be seen as technical 
> change (even if "in spirit" the Flow Control Receive Window logically refers 
> to the Receive Window sub-TLV)
> This requires the following changes in the 6.2.1 "Flow control" section:

I see that the changes are already in place in -06. Note that I think you 
should rename “Receive Window” to “LSP Burst Window” for consistency.  In 
reading the guidance in section 6.2.1, It seems to me that this should have 
been “LSP Receive Window” all along. We are not changing the semantics of "LSP 
Burst Window" or "LSP Receive Window”. 

I’d be interested in what the other co-authors think (especially Les ).

Thanks,
Acee




> 
> §6.2.1 Flow control
> No change required. The text correctly refers to " Receive Window sub-TLV"
> 
> §6.2.1.1 Operation on a point to point interface
> " By sending the LSP Burst Window sub-TLV, a node advertises to its neighbor 
> its ability to receive that many un-acknowledged LSPs from the neighbor, 
> without an intervening delay. This is akin to a receive window or sliding 
> window in flow control. In some implementations, this value should reflect 
> the IS-IS socket buffer size. Special care must be taken to leave space for 
> CSNP and PSNP (SNP) 

Re: [Lsr] Robert Wilton's Yes on draft-ietf-lsr-ospfv3-extended-lsa-yang-28: (with COMMENT)

[Acee Lindem]

Hi Rob,

> On Feb 1, 2024, at 9:11 AM, Robert Wilton via Datatracker  
> wrote:
> 
> Robert Wilton has entered the following ballot position for
> draft-ietf-lsr-ospfv3-extended-lsa-yang-28: Yes
> 
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
> 
> 
> Please refer to 
> https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ 
> for more information about how to handle DISCUSS and COMMENT positions.
> 
> 
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-lsr-ospfv3-extended-lsa-yang/
> 
> 
> 
> --
> COMMENT:
> --
> 
> Thanks for publishing another YANG model.
> 
> I do have a little sympathy to Roman's comment that having a bit more
> descriptive prose at the beginning of this document might be helpful to 
> readers
> (i.e., I'm thinking in the order of one or two paragraphs).  But at the same
> time, I can also see that repeating (or perhaps summarising) what is already
> written in another RFC isn't necessarily that helpful, and having the details
> in the YANG module itself is arguably the most important and useful place
> because then the tooling can build appropriate GUI help text or user
> documentation.

I honestly don’t know what I’d add. While sometimes the abstract/introduction 
of documents do
not adequately articulate the document purpose and scope, the succinct text 
below is clear (at least to me):


  This document defines a YANG data model augmenting the IETF OSPF
  YANG model to provide support for OSPFv3 Link State Advertisement (LSA) 
Extensibility
  as defined in RFC 8362. OSPFv3 Extended LSAs provide extensible TLV-based 
LSAs for the
  base LSA types defined in RFC 5340.

What is missing here?

One area of confusion that it would be good for you to get the message out, is 
that operational state  is
typically validated prior to being returned and the data is typically not 
validated by the YANG infra-structure
(al though types must still match). As you know, this is being addressed in RFC 
8407BIS. 


Thanks,
Acee


> 
> Regards,
> Rob
> 
> 
> 

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

Re: [Lsr] Murray Kucherawy's No Objection on draft-ietf-lsr-ospfv3-extended-lsa-yang-28: (with COMMENT)

[Acee Lindem]

Hi Murray, 

> On Feb 1, 2024, at 02:49, Murray Kucherawy via Datatracker  
> wrote:
> 
> Murray Kucherawy has entered the following ballot position for
> draft-ietf-lsr-ospfv3-extended-lsa-yang-28: No Objection
> 
> When responding, please keep the subject line intact and reply to all
> email addresses included in the To and CC lines. (Feel free to cut this
> introductory paragraph, however.)
> 
> 
> Please refer to 
> https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ 
> for more information about how to handle DISCUSS and COMMENT positions.
> 
> 
> The document, along with other ballot positions, can be found here:
> https://datatracker.ietf.org/doc/draft-ietf-lsr-ospfv3-extended-lsa-yang/
> 
> 
> 
> --
> COMMENT:
> --
> 
> Forwarding a comment from Orie Steele, incoming ART AD:
> 
> There do not appear to be a lot of normative statements.

Yes - Based on Éric’s comment, I’ve removed the RFC 2119 and RFC 8174 text from 
the document overview and YANG model prologue. I’ve also removed
 the normative references.  


Thanks,
Acee





> 
> 
> 

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

Re: [Lsr] I-D Action: draft-ietf-lsr-isis-fast-flooding-06.txt

[bruno . decraene]

Hi all,

-06 is meant to address the comments from the AD.

AD review: 
https://mailarchive.ietf.org/arch/msg/lsr/76gX3R26Eqy96c4a05HWjj5aosU/
Authors reply: 
https://mailarchive.ietf.org/arch/msg/lsr/8hY__gxAIe5z86o4rFjA3Q9fGtA/


A diff from the previous version is available at:
https://author-tools.ietf.org/iddiff?url2=draft-ietf-lsr-isis-fast-flooding-06

Thanks,
--Bruno on behalf of authors.

-Original Message-
From: Lsr  On Behalf Of internet-dra...@ietf.org
Sent: Thursday, February 1, 2024 3:54 PM
To: i-d-annou...@ietf.org
Cc: lsr@ietf.org
Subject: [Lsr] I-D Action: draft-ietf-lsr-isis-fast-flooding-06.txt

Internet-Draft draft-ietf-lsr-isis-fast-flooding-06.txt is now available. It is 
a work item of the Link State Routing (LSR) WG of the IETF.

   Title:   IS-IS Fast Flooding
   Authors: Bruno Decraene
Les Ginsberg
Tony Li
Guillaume Solignac
Marek Karasek
Gunter Van de Velde
Tony Przygienda
   Name:draft-ietf-lsr-isis-fast-flooding-06.txt
   Pages:   25
   Dates:   2024-02-01

Abstract:

   Current Link State Protocol Data Unit (PDU) flooding rates are much
   slower than what modern networks can support.  The use of IS-IS at
   larger scale requires faster flooding rates to achieve desired
   convergence goals.  This document discusses the need for faster
   flooding, the issues around faster flooding, and some example
   approaches to achieve faster flooding.  It also defines protocol
   extensions relevant to faster flooding.

The IETF datatracker status page for this Internet-Draft is:
https://datatracker.ietf.org/doc/draft-ietf-lsr-isis-fast-flooding/

There is also an HTMLized version available at:
https://datatracker.ietf.org/doc/html/draft-ietf-lsr-isis-fast-flooding-06

A diff from the previous version is available at:
https://author-tools.ietf.org/iddiff?url2=draft-ietf-lsr-isis-fast-flooding-06

Internet-Drafts are also available by rsync at:
rsync.ietf.org::internet-drafts


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

Ce message et ses pieces jointes peuvent contenir des informations 
confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce 
message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages 
electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou 
falsifie. Merci.

This message and its attachments may contain confidential or privileged 
information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete 
this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been 
modified, changed or falsified.
Thank you.

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

[Lsr] I-D Action: draft-ietf-lsr-isis-fast-flooding-06.txt

[internet-drafts]

Internet-Draft draft-ietf-lsr-isis-fast-flooding-06.txt is now available. It
is a work item of the Link State Routing (LSR) WG of the IETF.

   Title:   IS-IS Fast Flooding
   Authors: Bruno Decraene
Les Ginsberg
Tony Li
Guillaume Solignac
Marek Karasek
Gunter Van de Velde
Tony Przygienda
   Name:draft-ietf-lsr-isis-fast-flooding-06.txt
   Pages:   25
   Dates:   2024-02-01

Abstract:

   Current Link State Protocol Data Unit (PDU) flooding rates are much
   slower than what modern networks can support.  The use of IS-IS at
   larger scale requires faster flooding rates to achieve desired
   convergence goals.  This document discusses the need for faster
   flooding, the issues around faster flooding, and some example
   approaches to achieve faster flooding.  It also defines protocol
   extensions relevant to faster flooding.

The IETF datatracker status page for this Internet-Draft is:
https://datatracker.ietf.org/doc/draft-ietf-lsr-isis-fast-flooding/

There is also an HTMLized version available at:
https://datatracker.ietf.org/doc/html/draft-ietf-lsr-isis-fast-flooding-06

A diff from the previous version is available at:
https://author-tools.ietf.org/iddiff?url2=draft-ietf-lsr-isis-fast-flooding-06

Internet-Drafts are also available by rsync at:
rsync.ietf.org::internet-drafts


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

Re: [Lsr] AD review of draft-ietf-lsr-isis-fast-flooding-05

[bruno . decraene]

[+Acee as I'm proposing a change which could be seen as a technical change. 
Please looks for //Acee ]

Hi John, 

Many thanks for your careful review, your comments and your propositions.
I'll upload -06 within minutes.

Please see inline [Bruno]
 
 
> From: John Scudder  
> Sent: Thursday, January 25, 2024 6:52 PM
> 
> Hi Authors, WG,
> 
> Thanks for this document.
> 
> I’ve supplied my questions and comments in the form of an edited copy of the 
> draft. Minor editorial suggestions I’ve made in place without further 
> comment, more substantive questions and comments are done in-line and 
> prefixed with “jgs:”. You can use your favorite diff tool to review them; 
> I’ve attached the iddiff output for your convenience if you’d like to use it. 
> I’ve also pasted a traditional diff below in case you want to use it for 
> in-line reply.

[Bruno] Ack. Minor editorial comments should be included -06
 
> I’ve also requested a TSV early review of the document.

[Bruno] Thank you.
 
> —John
> 
> --- draft-ietf-lsr-isis-fast-flooding-05.txt  2024-01-24 19:46:21.0 
> -0500
> +++ draft-ietf-lsr-isis-fast-flooding-05-jgs-comments.txt 2024-01-25 
> 12:43:39.0 -0500
> @@ -285,6 +285,9 @@
 > 4.1.  LSP Burst Window sub-TLV
>  
> The LSP Burst Window sub-TLV advertises the maximum number of LSPs
> +--
> +jgs: should this say "maximum number of un-acknowledged LSPs"?


[Bruno] Thinking about this, I don't believe so.
The receiver is receiving LSPs. It does not matter for the receiver whether 
they have been acknowledged not.
Also the number of un-acknowledged LSPs is tracked by the flow control 
algorithm. The LSP Burst Window is more general and may be used by an 
implementation not implementing flow control.

That being said, your comment is logical given some errors in the draft and the 
use of a sub-optimal name.
So instead of applying your proposed resolution, we are proposing the following 
resolution:



OLD:  4.1 LSP Burst Window sub-TLV
NEW: 4.1 LSP Burst Size sub-TLV
Motivation: the term "Window" is being used by the flow control algorithm. 
Re-using the same term is incorrect in this case and a source of 
incomprehension for the reader. The error is coming from an historical artefact 
before the addition of the "4.6 Receive Window sub-TLV" in draft version -01

Obviously, the change needs to be replicated in the whole document.


In §4.2
OLD:  The LSP Transmission Interval sub-TLV advertises the minimum interval, in 
micro-seconds, between LSPs arrivals which can be received on this interface, 
after the maximum number of un-acknowledged LSPs have been sent.
NEW:The LSP Transmission Interval sub-TLV advertises the minimum interval, in 
micro-seconds, between LSPs arrivals which can be sustained on this receiving 
interface.
.


In §6.2.1.1
OLD:  After having sent a full burst of un-acknowledged LSPs, it MUST send the 
subsequent LSPs with an LSP Transmission Interval between LSP transmissions.
NEW: After having sent a full burst of LSPs, it MUST send the subsequent LSPs 
with a minimum of LSP Transmission Interval between LSP transmissions..

(I would assume that the above text was the main reason for your comment, as 
indeed " un-acknowledged LSPs " was explicitly stated 

---
//Acee

A bigger issue from that historical artifact is that some text refers to "LSP 
Burst Window" when they should refer to the "new" (from -01) "Receive Window 
sub-TLV". That's a bigger issue as "in letter" this may be seen as technical 
change (even if "in spirit" the Flow Control Receive Window logically refers to 
the Receive Window sub-TLV)
This requires the following changes in the 6.2.1 "Flow control" section:

§6.2.1 Flow control
No change required. The text correctly refers to " Receive Window sub-TLV"

§6.2.1.1 Operation on a point to point interface
" By sending the LSP Burst Window sub-TLV, a node advertises to its neighbor 
its ability to receive that many un-acknowledged LSPs from the neighbor, 
without an intervening delay. This is akin to a receive window or sliding 
window in flow control. In some implementations, this value should reflect the 
IS-IS socket buffer size. Special care must be taken to leave space for CSNP 
and PSNP (SNP) PDUs and IIHs if they share the same input queue. In this case, 
this document suggests advertising an LSP Burst Window corresponding to half 
the size of the IS-IS input queue."

:s/ LSP Burst Window/ Receive Window
(*2)

§6.2.1.2 Operation on a broadcast LAN interface
"In order for the LSP Burst Window to be a useful parameter, an LSP transmitter 
needs to be able to keep track of the number of un-acknowledged LSPs it has 
sent to a given LSP receiver."
:s/ LSP Burst Window/ Receive Window

OLD:  The LSP Burst Window is still very useful for the first burst of LSPs 
sent, especially in the case of a single node failure that requires the 
flooding of a relatively small number of LSPs.
NEW: The Receive Window is still very useful for the first set of LSPs 

[Lsr] Robert Wilton's Yes on draft-ietf-lsr-ospfv3-extended-lsa-yang-28: (with COMMENT)

[Robert Wilton via Datatracker]

Robert Wilton has entered the following ballot position for
draft-ietf-lsr-ospfv3-extended-lsa-yang-28: Yes

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)


Please refer to 
https://www.ietf.org/about/groups/iesg/statements/handling-ballot-positions/ 
for more information about how to handle DISCUSS and COMMENT positions.


The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-lsr-ospfv3-extended-lsa-yang/



--
COMMENT:
--

Thanks for publishing another YANG model.

I do have a little sympathy to Roman's comment that having a bit more
descriptive prose at the beginning of this document might be helpful to readers
(i.e., I'm thinking in the order of one or two paragraphs).  But at the same
time, I can also see that repeating (or perhaps summarising) what is already
written in another RFC isn't necessarily that helpful, and having the details
in the YANG module itself is arguably the most important and useful place
because then the tooling can build appropriate GUI help text or user
documentation.

Regards,
Rob



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

Re: [Lsr] Rtgdir last call review of draft-ietf-lsr-isis-sr-vtn-mt-05

[Daniele Ceccarelli]

I'm fine with the replies.

Thanks!
Daniele

On Tue, Jan 23, 2024 at 8:12 PM Acee Lindem  wrote:

> Hi Daniele,
>
> It seems that your comments have either been addressed or at least
> responded. Please reply if you wish further discussion.
>
> Thanks,
> Acee
>
> > On Dec 1, 2023, at 10:42 AM, Daniele Ceccarelli 
> wrote:
> >
> > Hi Chongfeng,
> >
> > Thanks for addressing my comments.
> > I would just suggest to add some text to the draft to explain the
> comment below
> >
> >
> > [Chongfeng] This is discussed in the scalability considerations section
> of this draft. This mechanism is useful for network scenarios in which the
> required number of VTN/NRP is small, the advantage is no protocol extension
> is required (as reflected by the document type). For network scenarios
> where the number of required VTN/NRP is large, more scalable solution would
> be needed, which may result in further protocol extensions and enhancements.
> >
> >
> > BR
> > Daniele
> >
> > On Wed, Nov 29, 2023 at 1:00 AM Chongfeng Xie 
> wrote:
> >
> > Hi Daniele,
> >
> > Thanks a lot for your careful review and comments. Please see my replies
> inline [Chongfeng]:
> >
> > -Original Message-
> > From: Daniele Ceccarelli via Datatracker [mailto:nore...@ietf.org]
> > Sent: Friday, November 24, 2023 10:21 PM
> > To: rtg-...@ietf.org
> > Cc: draft-ietf-lsr-isis-sr-vtn-mt@ietf.org; last-c...@ietf.org;
> lsr@ietf.org
> > Subject: Rtgdir last call review of draft-ietf-lsr-isis-sr-vtn-mt-05
> >
> > Reviewer: Daniele Ceccarelli
> > Review result: Has Issues
> >
> > - General: The term and concept of Enhanced VPN is being discussed in
> TEAS as part of the WG last call. I suggest to follow that thread and align
> the draft with whatever output will be agreed.
> >
> > [Chongfeng] Yes the terminology in this draft will align with the
> decision on terminology in in TEAS
> > - General: i would suggest to change the title into "Applicability"
> rather than using. Per my understanding this document describes how to use
> existing mechanisms to achieve something new (the status is correctly
> informational)
> >
> > [Chongfeng] Agree, we can make this change in next revision.
> > - Abstract: "enhanced isolation". i checked if it was defined in the
> framework for Enhanced VPNs in TEAS, but i couldn't find a definition there
> nor in this draft. What does it mean?
> >
> > [Chongfeng] We will align this description with the enhanced VPN
> framework draft.
> >
> > - VTN: is this a new term to identify a set of existing items? E.g. an
> ACTN VN, NRP, a set of RSVP-TE tunnel, a topology built with flex
> algo...are they cases of VTN or the VTN is a different thing?
> >
> > [Chongfeng] According to the recent discussion in TEAS, it is agreed to
> replace the term VTN with NRP.
> >
> > - Intro: s/than that can be provided/than the ones that can be provided
> >
> > [Chongfeng] OK.
> >
> > - "Another possible approach is to create a set of point-to-point paths,
> each with a set of network resources reserved along the path, such paths
> are called Virtual Transport Path (VTP)". In what is this different from an
> ACTN VN member? See RFC 8453.
> >
> > [Chongfeng] VN member as defined in RFC 8453 refers to "edge-to-edge
> link" exposed in the management plane, which is formed as end-to-end
> tunnels in the underlying networks. The term VTP refers to point-to-point
> underlay paths with network resource reserved along the path. So VTPs can
> be considered as one specific type of underlay tunnel with resource
> reservation. As we will replace VTN with NRP, we will consider whether the
> term VTP is still needed or not.
> >
> > - Introduction: "In some network scenarios, the required number of VTNs
> could be small, and it is assumed that each VTN is associated with an
> independent topology and has a set of dedicated or shared network
> resources. This document describes a simplified mechanism to build SR based
> VTNs in those scenarios." I don't understand, is there the need for a
> specific mechanisms (different from existing ones) only for particular
> cases in which the number of VTNs is small (smaller than other scenarios)?
> >
> > [Chongfeng] This is discussed in the scalability considerations section
> of this draft. This mechanism is useful for network scenarios in which the
> required number of VTN/NRP is small, the advantage is no protocol extension
> is required (as reflected by the document type). For network scenarios
> where the number of required VTN/NRP is large, more scalable solution would
> be needed, which may result in further protocol extensions and enhancements.
> >
> >  Section 3.1 "The usage of other TE attributes in topology-specific TLVs
> is for further study." The draft is pretty simple and small, can't the
> usage of other TE attributes be described here as well?
> >
> > [Chongfeng] Yes the encoding of TE attributes in topology-specific TLVs
> is simple, while a more important thing is to find valid use case for them.