Re: [Lsr] Opsdir last call review of draft-ietf-ospf-te-link-attr-reuse-12

2020-05-27 Thread Acee Lindem (acee) 
Hi Scott, 

On 5/27/20, 11:17 AM, "Scott Bradner via Datatracker"  wrote:

Reviewer: Scott Bradner
Review result: Not Ready

This is an OPS-DIR review of OSPF Link Traffic Engineering Attribute Reuse
(draft-ietf-ospf-te-link-attr-reuse)

This ID describes application-specific attribute advertisements for use in 
OSPF.

I found this ID hard to read and recommend that it be reviewed for 
readability.

I have a basic question about this proposal – the ID describes specific
advertisements to be used when particular applications want to make use of
specific link attributes and says that other applications should not make of
the information in the advertisement without saying why such use would be a
problem.  I can imagine some reasons but it seems to me that it would be 
good
if this document just explained the problem it is trying to solve.

We had a lengthy discussion of the requirements in the working group and I'm 
not sure why you are asking what problem this is solving when it is clearly 
stated in the abstract and further elaborated in the "Introduction".  A side 
benefit is that we will not have to advertise the OSPF TE LSAs which would need 
to be correlated with the LSAs for applications. Perhaps that should also be 
stated. See one more inline below. 

Some specific issues in the document

Page 6 – the text says “Standard Application Identifier Bit Mask: Optional 
set
of bits, where each bit represents a single standard application.  Bits are
defined in [I-D.ietf-isis-te-app].”  - it seems to me that this should be 
in an
IANA registry for extensibility but it does not seem to be in the 
referenced ID
but I could not actually tell

Page 6 – text says “The bits are repeated here for informational purpose” 
maybe point to a IANA registry or say “current assignments”

Page 6 – text says “If the link attribute advertisement is limited to be 
used
by a specific set of applications”  - maybe say “intended” rather than
“limited” since I do not see a way to actually limit a future application 
from
eavesdropping on the advertisement

Page 7 – the text says “If the SABM or UDABM length is other than 0, 4, or 
8,
the ASLA sub-TLV MUST be ignored by the receiver.”  - it would seem to be
useful operations-wise to say that an indication of an error should be 
recorded
somewhere

Page 7 – a “User Defined Application Identifier” is introduced but never
described – what uses it and what is it used for

Section 11 – I found this discussion of the relationship between the 
existence
of a particular advertisement and the possible existence of an application 
to
use that advertisement to be quite confusing – if the existence of a 
particular
advertisement does not indicate that any application is listening why not 
just
say that?

Section 12.1 – it would help to say what problem is trying to be solved – 
why
is the use of RSVP-TE LSA advertisements a problem?

Perhaps the LSR WG COULD have solved the problem with the existing RSVP-TE 
LSAs. However, this was not the consensus of the WG and the, IMO, the resultant 
encodings would have been sub-optimal. The resultant information would have 
been spread over more LSAs and you would have more chicken and egg situations 
with the correlation of LSAs. Now, with OSPFv3 Extended LSAs, all the required 
information is advertised in a single LSAs. 

Thanks,
Acee

Section 12.3.3 – I could not tell if this section is saying that the
application specific attribute advertisements could not be used if there is
even a single legacy router present of if the presence of such a router 
means
that the application specific attribute advertisements can be used but the 
old
advertisements must also be used Section 14 – it might help to say how new
Sub-TLV types can be added to the registry




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

Re: [Lsr] Flooding Topology Computation Algorithm - draft-cc-lsr-flooding-reduction-08 Working Group Adoption Call

2020-05-27 Thread tony . li 

Les,


> We are contemplating submitting a draft for this algorithm to the WG.


We would welcome that.  

Does your algorithm have any relationship to 
https://tools.ietf.org/html/draft-allan-lsr-flooding-algorithm-00? 



> [Les:] As I understand it, draft-chen only supports centralized mode – which 
> is why it is Informational track and does not have interoperability concerns.
> Sarah/Tony - do you have plans to extend this to support distributed mode and 
> then standardize it?


Not at this time.  As we said during our presentation, we found debugging this 
already ‘challenging’ and morphing it to be distributed and deterministic in 
distributed mode doesn’t pass our sense of a beneficial cost/benefit ratio.

We have no objections if others want to take this on.  Centralized mode Just 
Works.


> And the point of allowing multiple standardized algorithms to be defined was 
> in the expectation that more than one might be proven useful.


Interoperability might also prove useful. :-)

Tony


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

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

2020-05-27 Thread Les Ginsberg (ginsberg) 
FYI -

This versions corrects the codepoint registration policy for the new "IGP 
Algorithm Type For  Computing Flooding Topology".

Les

> -Original Message-
> From: Lsr  On Behalf Of internet-dra...@ietf.org
> Sent: Wednesday, May 27, 2020 10:35 AM
> To: i-d-annou...@ietf.org
> Cc: lsr@ietf.org
> Subject: [Lsr] I-D Action: draft-ietf-lsr-dynamic-flooding-06.txt
> 
> 
> A New Internet-Draft is available from the on-line Internet-Drafts 
> directories.
> This draft is a work item of the Link State Routing WG of the IETF.
> 
> Title   : Dynamic Flooding on Dense Graphs
> Authors : Tony Li
>   Peter Psenak
>   Les Ginsberg
>   Huaimo Chen
>   Tony Przygienda
>   Dave Cooper
>   Luay Jalil
>   Srinath Dontula
>   Filename: draft-ietf-lsr-dynamic-flooding-06.txt
>   Pages   : 47
>   Date: 2020-05-27
> 
> Abstract:
>Routing with link state protocols in dense network topologies can
>result in sub-optimal convergence times due to the overhead
>associated with flooding.  This can be addressed by decreasing the
>flooding topology so that it is less dense.
> 
>This document discusses the problem in some depth and an
>architectural solution.  Specific protocol changes for IS-IS, OSPFv2,
>and OSPFv3 are described in this document.
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-ietf-lsr-dynamic-flooding/
> 
> There are also htmlized versions available at:
> https://tools.ietf.org/html/draft-ietf-lsr-dynamic-flooding-06
> https://datatracker.ietf.org/doc/html/draft-ietf-lsr-dynamic-flooding-06
> 
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-ietf-lsr-dynamic-flooding-06
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> 
> ___
> 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] Flooding Topology Computation Algorithm - draft-cc-lsr-flooding-reduction-08 Working Group Adoption Call

2020-05-27 Thread Les Ginsberg (ginsberg) 
Tony/Gyan -

Please find my replies inline.

From: Lsr  On Behalf Of tony...@tony.li
Sent: Wednesday, May 20, 2020 8:48 AM
To: Gyan Mishra 
Cc: lsr@ietf.org; Huaimo Chen ; Acee Lindem (acee) 

Subject: Re: [Lsr] Flooding Topology Computation Algorithm - 
draft-cc-lsr-flooding-reduction-08 Working Group Adoption Call


Hi Gyan,



This is a much needed feature that operators have been needing for densely 
meshed topologies that commonly exist in data centers to accommodate very high 
bandwidth E-W traffic.

Thank you.


Please look at the feature description and it does seem to be exactly the same 
as this draft.  Please confirm.


It would appear to be a different, proprietary, and unpublished algorithm.

[Les:] Yes, this is a different algorithm than either 
https://datatracker.ietf.org/doc/draft-chen-lsr-dynamic-flooding-algorithm/ or  
https://datatracker.ietf.org/doc/draft-cc-lsr-flooding-reduction/

We are contemplating submitting a draft for this algorithm to the WG.



This will give us three different implementations, using three different 
algorithms, none of which will inter-operate.  Whee!!! :-(


[Les:] As I understand it, draft-chen only supports centralized mode - which is 
why it is Informational track and does not have interoperability concerns.
Sarah/Tony - do you have plans to extend this to support distributed mode and 
then standardize it?

At present there are no standard algorithm candidates which have achieved WG 
status - though that likely will change very soon.
And the point of allowing multiple standardized algorithms to be defined was in 
the expectation that more than one might be proven useful.



There maybe other vendors due to industry demand have to get the feature 
deployed before it reaches standards vendor consensus with the IETF.


Our implementation shipped last year.

[Les:] As did Cisco's.


We are testing this feature and planning to deploy but wanted to ensure that 
this is the same as the draft on the standards track.


It does not appear to be, but someone from Cisco should confirm.

[Les:] Confirmed.

   Les

Tony

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

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

2020-05-27 Thread internet-drafts 


A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Link State Routing WG of the IETF.

Title   : Dynamic Flooding on Dense Graphs
Authors : Tony Li
  Peter Psenak
  Les Ginsberg
  Huaimo Chen
  Tony Przygienda
  Dave Cooper
  Luay Jalil
  Srinath Dontula
Filename: draft-ietf-lsr-dynamic-flooding-06.txt
Pages   : 47
Date: 2020-05-27

Abstract:
   Routing with link state protocols in dense network topologies can
   result in sub-optimal convergence times due to the overhead
   associated with flooding.  This can be addressed by decreasing the
   flooding topology so that it is less dense.

   This document discusses the problem in some depth and an
   architectural solution.  Specific protocol changes for IS-IS, OSPFv2,
   and OSPFv3 are described in this document.


The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-lsr-dynamic-flooding/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-lsr-dynamic-flooding-06
https://datatracker.ietf.org/doc/html/draft-ietf-lsr-dynamic-flooding-06

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-lsr-dynamic-flooding-06


Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/


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

[Lsr] Opsdir last call review of draft-ietf-ospf-te-link-attr-reuse-12

2020-05-27 Thread Scott Bradner via Datatracker 
Reviewer: Scott Bradner
Review result: Not Ready

This is an OPS-DIR review of OSPF Link Traffic Engineering Attribute Reuse
(draft-ietf-ospf-te-link-attr-reuse)

This ID describes application-specific attribute advertisements for use in OSPF.

I found this ID hard to read and recommend that it be reviewed for readability.

I have a basic question about this proposal – the ID describes specific
advertisements to be used when particular applications want to make use of
specific link attributes and says that other applications should not make of
the information in the advertisement without saying why such use would be a
problem.  I can imagine some reasons but it seems to me that it would be good
if this document just explained the problem it is trying to solve.

Some specific issues in the document

Page 6 – the text says “Standard Application Identifier Bit Mask: Optional set
of bits, where each bit represents a single standard application.  Bits are
defined in [I-D.ietf-isis-te-app].”  - it seems to me that this should be in an
IANA registry for extensibility but it does not seem to be in the referenced ID
but I could not actually tell

Page 6 – text says “The bits are repeated here for informational purpose” 
maybe point to a IANA registry or say “current assignments”

Page 6 – text says “If the link attribute advertisement is limited to be used
by a specific set of applications”  - maybe say “intended” rather than
“limited” since I do not see a way to actually limit a future application from
eavesdropping on the advertisement

Page 7 – the text says “If the SABM or UDABM length is other than 0, 4, or 8,
the ASLA sub-TLV MUST be ignored by the receiver.”  - it would seem to be
useful operations-wise to say that an indication of an error should be recorded
somewhere

Page 7 – a “User Defined Application Identifier” is introduced but never
described – what uses it and what is it used for

Section 11 – I found this discussion of the relationship between the existence
of a particular advertisement and the possible existence of an application to
use that advertisement to be quite confusing – if the existence of a particular
advertisement does not indicate that any application is listening why not just
say that?

Section 12.1 – it would help to say what problem is trying to be solved – why
is the use of RSVP-TE LSA advertisements a problem?

Section 12.3.3 – I could not tell if this section is saying that the
application specific attribute advertisements could not be used if there is
even a single legacy router present of if the presence of such a router means
that the application specific attribute advertisements can be used but the old
advertisements must also be used Section 14 – it might help to say how new
Sub-TLV types can be added to the registry



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