[Lsr] [Editorial Errata Reported] RFC7810 (5486)

[RFC Errata System]

The following errata report has been submitted for RFC7810,
"IS-IS Traffic Engineering (TE) Metric Extensions".

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

--
Type: Editorial
Reported by: Teresa 

Section: 4.6

Original Text
-
Available Bandwidth: This field carries the available bandwidth on a
   link, forwarding adjacency, or bundled link in IEEE floating-point
   format with units of bytes per second.  For a link or forwarding
   adjacency, available bandwidth is defined to be residual bandwidth
   (see Section 4.5) minus the measured bandwidth used for the actual
   forwarding of non-RSVP-TE label switched path packets.  For a bundled
   link, available bandwidth is defined to be the sum of the component
   link available bandwidths minus the measured bandwidth used for the
   actual forwarding of non-RSVP-TE label switched path packets.  For a
   bundled link, available bandwidth is defined to be the sum of the
   component link available bandwidths.

Corrected Text
--
Available Bandwidth: This field carries the available bandwidth on a
   link, forwarding adjacency, or bundled link in IEEE floating-point
   format with units of bytes per second.  For a link or forwarding
   adjacency, available bandwidth is defined to be residual bandwidth
   (see Section 4.5) minus the measured bandwidth used for the actual
   forwarding of non-RSVP-TE label switched path packets.  For a bundled
   link, available bandwidth is defined to be the sum of the component
   link (residual) bandwidths minus the measured bandwidth used for the
   actual forwarding of non-RSVP-TE label switched path packets.For a
   bundled link, available bandwidth is defined to be the sum of the
   component link available bandwidths.

Notes
-
Two sentences to explain 'available bandwidth' on a bundled link, but one says 
"sum of component available bandwidth minus xxx", the other says "sum of 
component available bandwidth", is conflicting. need to change the first 
sentence to 'sum of component residual bandwidth minus xxx'

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. 

--
RFC7810 (draft-ietf-isis-te-metric-extensions-11)
--
Title   : IS-IS Traffic Engineering (TE) Metric Extensions
Publication Date: May 2016
Author(s)   : S. Previdi, Ed., S. Giacalone, D. Ward, J. Drake, Q. Wu
Category: PROPOSED STANDARD
Source  : IS-IS for IP Internets
Area: Routing
Stream  : IETF
Verifying Party : IESG

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

Re: [Lsr] LSR Flooding Reduction Drafts - Moving Forward

[John E Drake]

Hi,

I have reviewed both of the flood reduction drafts and the draft referenced 
below, draft-cc-ospf-flooding-reduction-02, seems to me to be a derivative 
document inferior in quality to the draft, draft-li-dynamic-flooding-05, from 
which it is derived.  For example, the referenced draft fails to include a 
description of the message used to deliver the flooding topology when using 
centralized mode, it neglects to include any analysis of error conditions, and 
it neglects to include any description of the interactions with down-level 
nodes.

Yours Irrespectively,

John

From: Lsr  On Behalf Of Huaimo Chen
Sent: Thursday, August 30, 2018 11:01 AM
To: Robert Raszuk 
Cc: tony...@tony.li; Acee Lindem (acee) ; 
lsr@ietf.org; Jeff Tantsura ; Tony Przygienda 
; Peter Psenak 
Subject: Re: [Lsr] LSR Flooding Reduction Drafts - Moving Forward

Hi Robert,

>> draft-cc-ospf-flooding-reduction-02 allows operators to select distributed 
>> mode, centralized one or static one smoothly.
>Aside from static approach can you summarize in purely technical points 
>advantages your draft proposes over draft-li-dynamic-flooding-05 ?
Initially, our draft focused on distributed solution for flooding reduction, 
and Tony’s on centralized way. This should be one advantage. Distributed 
solution is more practical.
In addition, we proposed the followings during the progress of our draft:

1) A method to allow flooding topology to be lean and to allow multiple 
failures in an area;

2) A procedure for establishing a new adjacency between a (new) node and  
an existing node supporting flooding reduction;

3) A way in which one touch (or command) to enable flooding reduction in a 
whole area within a short time;

4) A way in which one touch (or command) to rollback flooding reduction to 
normal flooding in a whole area smoothly;

5) A TLV for distributing the priority of a node to become a leader;

6) Three algorithms for building a flooding topology.
Distributed solution for flooding reduction is stable after we resolve the 
issues raised by other experts during the last few IETFs.
BTW, as a service provider, which mode/solution (distributed or centralized) 
will you select to use in an operational network?

Best Regards,
Huaimo
>Many thx,
>R.



On Mon, Aug 27, 2018 at 6:41 PM, Huaimo Chen 
mailto:huaimo.c...@huawei.com>> wrote:
Hi Robert,

>Leader election happens automatically and procedures for that are to be vastly 
>similar to today's DR or DIS election. So with this in mind one may observe 
>that both OSPF and ISIS are pretty centralized on multiaccess networks today :)

Today’s DR or DIS election is local to a special interface/network such as a 
broadcast interface. Leader election in a network is global. Every node in the 
network depends on it (its flooding topology). These two seems different.

>Btw I don't think there is any problem here ... The text added to -05 version 
>allows very seamless choice of centralized vs distributed topology computation 
>by signalling either zero or non zero value in the added to version -05 area 
>leader sub-tlv.
>
>In other words I don't see any problem or room for debate .. adopting and 
>implementing -05 allows use of centralized or distributed optimal flooding 
>computation at the operator's discretion.

draft-cc-ospf-flooding-reduction-02 allows operators to select distributed 
mode, centralized one or static one smoothly.

Best Regards,
Huaimo

From: Robert Raszuk [mailto:rob...@raszuk.net]
Sent: Monday, August 27, 2018 11:31 AM
To: Huaimo Chen mailto:huaimo.c...@huawei.com>>
Cc: tony...@tony.li; lsr@ietf.org; 
Jeff Tantsura mailto:jefftant.i...@gmail.com>>; Acee 
Lindem (acee) 
mailto:40cisco@dmarc.ietf.org>>; Peter 
Psenak mailto:ppse...@cisco.com>>; Tony Przygienda 
mailto:tonysi...@gmail.com>>
Subject: Re: [Lsr] LSR Flooding Reduction Drafts - Moving Forward

Hi Huaimo,

> Introducing centralized feature into IGP will break IGP's distributed nature

That clearly proves that word "centralized" has been significantly overloaded 
here.  To many indeed "centralized" means a controller (like OpenFlow or SDN) 
and that such device added to a network is to push information - typically 1RU 
linux blade -  here optimized flooding graph. But this never was the plan with 
this proposal from its start ie. -00 version.

Centralized means that optimized flooding graph comes from single redundant 
node.

Leader election happens automatically and procedures for that are to be vastly 
similar to today's DR or DIS election. So with this in mind one may observe 
that both OSPF and ISIS are pretty centralized on multiaccess networks today :)

To your point of multi-vendor networks true - and that is precisely why upgrade 
network wide to a release containing consistent algorithm from more then a 
single vendor (and even for single vendor) is practically a very time consuming 
and difficult 

Re: [Lsr] LSR Flooding Reduction Drafts - Moving Forward

[Huaimo Chen]

Hi Robert,

>> draft-cc-ospf-flooding-reduction-02 allows operators to select distributed 
>> mode, centralized one or static one smoothly.
>Aside from static approach can you summarize in purely technical points 
>advantages your draft proposes over draft-li-dynamic-flooding-05 ?
Initially, our draft focused on distributed solution for flooding reduction, 
and Tony’s on centralized way. This should be one advantage. Distributed 
solution is more practical.
In addition, we proposed the followings during the progress of our draft:

1)A method to allow flooding topology to be lean and to allow multiple 
failures in an area;

2)A procedure for establishing a new adjacency between a (new) node and  an 
existing node supporting flooding reduction;

3)A way in which one touch (or command) to enable flooding reduction in a 
whole area within a short time;

4)A way in which one touch (or command) to rollback flooding reduction to 
normal flooding in a whole area smoothly;

5)A TLV for distributing the priority of a node to become a leader;

6)Three algorithms for building a flooding topology.
Distributed solution for flooding reduction is stable after we resolve the 
issues raised by other experts during the last few IETFs.
BTW, as a service provider, which mode/solution (distributed or centralized) 
will you select to use in an operational network?

Best Regards,
Huaimo
>Many thx,
>R.



On Mon, Aug 27, 2018 at 6:41 PM, Huaimo Chen 
mailto:huaimo.c...@huawei.com>> wrote:
Hi Robert,

>Leader election happens automatically and procedures for that are to be vastly 
>similar to today's DR or DIS election. So with this in mind one may observe 
>that both OSPF and ISIS are pretty centralized on multiaccess networks today :)

Today’s DR or DIS election is local to a special interface/network such as a 
broadcast interface. Leader election in a network is global. Every node in the 
network depends on it (its flooding topology). These two seems different.

>Btw I don't think there is any problem here ... The text added to -05 version 
>allows very seamless choice of centralized vs distributed topology computation 
>by signalling either zero or non zero value in the added to version -05 area 
>leader sub-tlv.
>
>In other words I don't see any problem or room for debate .. adopting and 
>implementing -05 allows use of centralized or distributed optimal flooding 
>computation at the operator's discretion.

draft-cc-ospf-flooding-reduction-02 allows operators to select distributed 
mode, centralized one or static one smoothly.

Best Regards,
Huaimo

From: Robert Raszuk [mailto:rob...@raszuk.net]
Sent: Monday, August 27, 2018 11:31 AM
To: Huaimo Chen mailto:huaimo.c...@huawei.com>>
Cc: tony...@tony.li; lsr@ietf.org; 
Jeff Tantsura mailto:jefftant.i...@gmail.com>>; Acee 
Lindem (acee) 
mailto:40cisco@dmarc.ietf.org>>; Peter 
Psenak mailto:ppse...@cisco.com>>; Tony Przygienda 
mailto:tonysi...@gmail.com>>
Subject: Re: [Lsr] LSR Flooding Reduction Drafts - Moving Forward

Hi Huaimo,

> Introducing centralized feature into IGP will break IGP's distributed nature

That clearly proves that word "centralized" has been significantly overloaded 
here.  To many indeed "centralized" means a controller (like OpenFlow or SDN) 
and that such device added to a network is to push information - typically 1RU 
linux blade -  here optimized flooding graph. But this never was the plan with 
this proposal from its start ie. -00 version.

Centralized means that optimized flooding graph comes from single redundant 
node.

Leader election happens automatically and procedures for that are to be vastly 
similar to today's DR or DIS election. So with this in mind one may observe 
that both OSPF and ISIS are pretty centralized on multiaccess networks today :)

To your point of multi-vendor networks true - and that is precisely why upgrade 
network wide to a release containing consistent algorithm from more then a 
single vendor (and even for single vendor) is practically a very time consuming 
and difficult process.

Btw I don't think there is any problem here ... The text added to -05 version 
allows very seamless choice of centralized vs distributed topology computation 
by signalling either zero or non zero value in the added to version -05 area 
leader sub-tlv.

In other words I don't see any problem or room for debate .. adopting and 
implementing -05 allows use of centralized or distributed optimal flooding 
computation at the operator's discretion.

Thx,
R.

On Mon, Aug 27, 2018 at 5:10 PM, Huaimo Chen 
mailto:huaimo.c...@huawei.com>> wrote:
>> I think distributed is more practical too.
>I would appreciate more detailed insights as to why you (and others) feel this 
>way.  It is not at all obvious to me.
IGP is distributed in nature. The distributed computation of flooding topology 
like distributed SPF will keep IGP still distributed in nature.