> How is the measurement interval and filter coefficients described in the
> draft related to dissemination?
It is directly related. If you see the title of the section is:
"Announcement Thresholds and Filters"
So measurement interval does not intend to describe how often you
Tonys / Everyone,
> moreover, I observe that IME ISIS is much more robust under such
optimizations since the CSNPs catch (@ a somehow ugly delay cost)
> any corner cases whereas OSPF after IDBE will happily stay out of sync
forever if flooding skips something (that may actually become a
> Introducing centralized feature into IGP will break IGP's distributed
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
> >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
I already suggested use of BGP-LS *as-is* in this thread on Jul 6th.
But I guess we all agree that this is not the best use of BGP protocol to
be now a vehicle of NMS only because it is easy with BGP to establish a TCP
session and to distribute "stuff" in a relatively loop free fashion.
I agree with Rob & Tony.
Converging on single algorithm across zoo of vendors is not going to happen
bearing in mind that every single change to such algorithm will require a
massive 1000s nodes software upgrade each time.
Note that even if IETF converges industry may not and that is a practical
Isn't RIFT effectively a new flooding algorithm - while not strictly
designed to be used within current link state protocols - it has the
potential to achieve what you and Peter are proposing isn't it ?
My personal take here would be to progress dynamic flooding *as is* with
the use of
clearly a different flooding
> topology from the one IGPs use today is required or we will have
> accomplished nothing.
> *From:* Lsr <lsr-boun...@ietf.org> *On Behalf Of *Robert Raszuk
> *Sent:* Saturday, April 07, 2018 10:44 A
Let me just ask one little question
It seems that ISIS protocol already meets a "Link State Over Ethernet"
definition so why to invent anything new here ?
If you don't like flooding properties of ISIS just disable it. Do not
flood. Do not run SPF in ISIS. Use ISIS only for
> - We could make BFD mandatory when flooding over TCP ?
I don't think this would be a good idea.
See especially for p2p fiber links loss of light is a much faster and
better trigger/indicator that your link or adjacent router is down.
Using BFD there which in most cases operates in a
> Again, if people think that LSVR is a good idea, then how can they
> think that ISIS flooding over TCP is not a good idea ? This is
> the base idea for our proposal. A quick look at the LSVR draft
> show people from Cisco, Nokia (and Arrcus). (I'm not sure what
> Juniper or Arista or
le DSCP based mapping into disjointed topologies (of
any form) that solves my issue without any additional state imposed to the
apps or to the network.
On Fri, Nov 16, 2018 at 1:07 AM Toerless Eckert wrote:
> On Fri, Nov 16, 2018 at 12:28:27AM +0100, Robert Raszuk wrote:
Please observe that DSCP based steering may be very useful vehicle for end
hosts/applications influencing how their packets are transported.
So instead of closing that option I recommend we at least take a good look
at what alternative mechanism exists.
And btw I read Peter's note
> What architecture?
> PBR is a form of:
> match DSCP X
> set next-hop Y
> needs no interoperability...
That's pretty narrow view. I could say the worst possible example :) You
would have to either encapsulate or apply your sample config consistently
on every hop. Br.
To me DSCP can
> Please do not confuse the two.
> *From:* Robert Raszuk
> *Sent:* Wednesday, November 07, 2018 12:39 AM
> *To:* Les Ginsberg (ginsberg)
> *Cc:* hhws...@xs4all.nl; Tony Li ;
> There are existing and successful deployments of an instance with
> neighbors and thousands of nodes in a network and sub-second convergence
While I completely agree with your above observation (and as a matter of
fact first person to tell me that was
IETF seems to be doing great job in defining protocols and their
extensions. It doesn't do that great job in defining the dynamics of
protocols and their recommended behavior. That's called a "vendor's secret
This thread seems to be a good example of that.
In BGP there was similar
For the purpose of this discussion can someone quote the definition of LAN
*1* In most modern data centers I do not see any LANs. Even compute nodes
are L3 nodes connected over /31 or /30 to TORs. From fabric IGP this is
*2* In slightly older DCs there are redundant
> The fact that we use them in a point-to-point fashion today is somewhat
orthogonal, as from
> the routing protocol layer, *we cannot tell* whether an interface is
point-to-point or not, and we
> must be explicitly configured to be in point-to-point mode.
Why we cannot tell ? That to
:26 Tony Przygienda wrote:
> On Wed, Apr 3, 2019 at 1:36 AM Robert Raszuk wrote:
>> Hi Tony,
>> > The fact that we use them in a point-to-point fashion today is somewhat
>> orthogonal, as from
>> > the routing protocol layer, *we cannot
> What extension are you proposing?
If you have only two routers on LAN based on IIH multicast discovery you
are still forming an adj between them (you do that anyway as one of them
will be DIS). But for flooding reduction point of view you can treat it as
p2p link (so it must be signaled as
Well imagine I am building DMZ with two gateways and a firewall connected
to L2 switch. I run IGP between them so my iBGP next hops can resolve.
Later I may perhaps add third and fourth gateway.
I can not normally set it as p2p IGP day one, but it could operate fine for
the first few years as
Sorry – but I really think you are taking this thread off topic.
If asking a question which is outside of the box is equal to thread
hijacking then sorry. But you won - subject line changed.
But I really think this isn’t relevant. The use of LANs in the flooding
> topology is only
> Slow convergence is obviously not a good thing
Could you please kindly elaborate why ?
With tons of ECMP in DCs or with number of mechanism for very fast data
plane repairs in WAN (well beyond FRR) IMHO any protocol *fast convergence*
is no longer a necessity. Yet many folks still talk about
ely selected* all 4 paths before
you manage to distribute new flooding topology you can always flood over 6
On Tue, Mar 5, 2019 at 9:17 PM Peter Psenak wrote:
> On 05/03/2019 20:12 , Robert Raszuk wrote:
> >> Slow convergence is
> we want to limit the flooding to minimum, which is 2.
Is that really a common agreement in the WG ? I have a feeling think this
is too restrictive for no valid technical reason.
Lsr mailing list
info goes down flooding graph can be repaired at its own pace while
data plane is not impacted as there are many more L3 paths still available.
That was my point.
On Tue, Mar 5, 2019 at 8:36 PM Tony Przygienda wrote:
> On Tue, Mar 5, 2019 at 11:12 AM Robert Rasz
I have read your proposal of defining topology flooding in BGP with
It seems like a pretty brilliant twist to take pieces defined in other
documents with their original intention for sending IGP information (LSDB
or TED) over BGP extension and now use all of those without IGP
of including those 100s of TORs in constructing
and distributing flooding graph.
But spec seems quite silent on such deployment model hence the post.
On Thu, Mar 7, 2019 at 12:11 PM Peter Psenak wrote:
> Hi Robert,
> On 07/03/2019 12:00 , Robert Raszuk wrote:
> > Hi,
My reading of draft-ietf-lsr-dynamic-flooding indicates that said document
in number of places rather assumes that entire topology (entire instance)
supports dynamic flooding (perhaps other then bootstrap phase).
Let's observe that there can be lots of L3 TORs only dual attached to
On Fri, Mar 8, 2019 at 1:30 PM Acee Lindem (acee) wrote:
> On 3/8/19, 7:22 AM, "Lsr on behalf of Christian Hopps" <
> lsr-boun...@ietf.org on behalf of cho...@chopps.org> wrote:
> tony...@tony.li writes:
> >Robert Raszuk writ
, 2019, at 3:16 AM, Robert Raszuk wrote:
> And precisely to that point I have tried to indicate that if this is by
> design there is no point of including those 100s of TORs in constructing
> and distributing flooding graph.
> And to the point of the alg
Many thx for your comment.
What I had in mind here was use of multi instance (=2) over very reach
physical topologies. So when we construct flooding graph for each such
instance - even in centralized mode - the intention was to avoid flooding
to take common links (just to reduce the
On Mon, Feb 11, 2019 at 11:47 AM Christian Hopps wrote:
> Hi Folks,
> We are starting a 2 week adoption call on draft-li-lsr-dynamic-flooding-02.
> The aim of this document is to describe the problem space and standardize
> a way to signal dynamic flooding information. It
I fully agree and support proceeding with draft-li-dyanmic-flooding and to
include protocol extensions in it for centralized topology propagation as
well as basic hooks like "execute dynamic protocol number X" for
However one may observe that separate distributed
> The former will have all the good parts for the centralized solution, and
the latter will have all the good parts for the distributed solution.
And in your view which draft should contain required protocol extensions to
accommodate both solutions ?
Or are you suggesting that we should have
Sound like best plan fwd.
On Fri, Feb 1, 2019, 13:26 Christian Hopps
> Summary of where we are at with dynamic flooding reduction:
> - We have a well written original work that came first and described the
> problems as well as a TLVs to allow for a centralized solution
IMO what Olivier has indicated is a practical and operational aspect. The
theoretical aspects of protocol operation is what this document is
extending. Those are two different things :) And this is not the first
time where IETF is manufacturing specs without any serious input from folks
It has been pointed out about month ago :)
On Fri, May 31, 2019 at 11:41 PM Paul Mattes wrote:
> I think there is a small issue with
> draft-ietf-lsr-isis-srvr-extensions-00. The title is:
> > Is it more efficient that only one area leader indicates(according to
> the command from NMS) explicitly then the network will be back to normal
> yes and we have that in the draft:
> "When the Area Leader advertises algorithm 0 in its Area Leader Sub-
Isn't the draft's name a bit misleading ?
"IS-IS Extensions to *Support* Routing over IPv6 Dataplane"
I think ISIS supports routing over IPv6 for some time now :) Maybe it would
be better to s/Support/Segment/ ?
In any case I support the adoption.
On Thu, May 9, 2019 at 3:50 PM Acee
One may observe that the draft implicitly also supports already option A
too. If leader advertises full topology wouldn't it effectively disable
dynamic flooding automatically ?
At least no NMS or configuration push is required on all 1000s of nodes to
go back to full flooding say for the purpose
> With respect to your comments on BGP-LS, this is out of scope for LSR.
During last IETF it has been communicated by IDR chairs that there is an
agreement that all IGP extensions in LSR WG will define in the same
document also extensions to BGP-LS so the work is not duplicated and that
Could you provide pointer to comparison of CRH vs SRH ? Do we really need
to standardize both ? Is this going to help any practical deployments ?
Very honestly when I read this draft I needed to check date as I though we
are back in 2002/2003 when CR-LDP was trying to compete with
Sounds great !
Lsr mailing list
> What would you suggest?
How about: draft-ietf-lsr-n-level-isis-00 ?
On Tue, Aug 13, 2019 at 4:42 PM wrote:
> Thank you for your support. What would you suggest?
> On Aug 13, 2019, at 6:40 AM, Robert Raszuk wrote:
S-IS are no different then one
> instance of two different protocols.
> But this is decidedly NOT the intent of the draft.
> *From:* Lsr *On Behalf Of * tony...@tony.li
> *Sent:* Friday, August 16, 2019 11:01 AM
> *To:* Tony Li
> The hierarchical arrangement of the control plane does NOT imply that the
data plane is necessarily hierarchical.
Since Aijun posted his question I was trying to think of such model, but
While it is easy to envision this with DV protocols say BGP - do you have
any pointer to
Ad 1 - Let me observe that constructing hierarchy is not always driven by
number of nodes in a given level can safely support. One could indeed build
a global flat link state network in single level/area if only looking at
number of nodes. But in number of cases benefits from hierarchy
However assuming the draft will reach rough consensus of support I do
recommend to change the title during the conversion to WG document. ISIS is
already hierarchical today as even the abstract of the draft clearly says.
On Mon, Aug 12, 2019 at 11:57 PM Acee Lindem (acee)
Are you working on the assumption that there is no data link layer flow
control already which could signal the OS congestion on the receiving end ?
Are we also working on the assumptions that when ISIS PDUs are send in DCs
(unknown today case when out of the sudden 1000s of LSPs may
> I am assuming that there is no link layer flow control. I can’t recall
> working on a system that supports X.25 since about 1995, so I don’t think
> that’s a common use case today.
I was more thinking along the lines of leveraging IEEE 802.3x or 802.1Qbb
standard not necessarily
Hey Henk & all,
If acks for 1000 LSPs take 16 PSNPs (max 66 per PSNP) or even as long as
Tony mentioned the full flooding as Tony said may take 33 sec - is this
really a problem ?
Remember we are not talking about protocol convergence after link flap or
node going down. We are talking about
r microloops while ISIS synchronizes its LSPDB after a reboot. Just
> like we
> used the overload-bit to solve the problem of slow convergence of BGP
> a reboot, 22 years ago. I have no idea if there are any implementations
> use the overload-bit to alleviate slow conv
*[Les:] At the cost of convergence. Not a good tradeoff.*
Hi Les - why at the cost of convergence ? No one as I see it is proposing
the same rate to every peer. Quite contrary -- per peer rate of flooding.
So if you keep flooding high speed on fast links the convergence will not
be any slower
*> Once advertised in the network using a suitable link state protocol
> (such as OSPF, ISIS or BGP-LS),*
Whow ... never imagined that BGP-LS would be called one day a "link
state protocol" and an equal sign would be made to OSPF and ISIS.
PS. As to the proposal in draft
hy this should be viewed
> as a bottleneck.
> If your concern is that we need to emphasize the importance of sending
> timely ACKs, I think we could look at text that makes that point.
> *From:* Lsr *On Behalf Of *
I agree with you that essentially this is a link property (hence my earlier
hint towards 5029) so it makes it at least two of us recommending direction
towards 5029 now ;)
While we are at this perhaps it would be also useful to be able to
differentiate reachability on stub links vs
> We just want to distinguish the passive interfaces from other normal
> interfaces within ISIS domain. It seems that the “Attribute Flags” that
> described in https://tools.ietf.org/html/rfc7794#section-2.1 is the most
> appropriate place to extend to carry such information.
lace to put
> this information?
> P.S. I changed the thread to reflect the conversion topic.
> Best Regards.
> Aijun Wang
> China Telecom
> *发件人:* lsr-boun...@ietf.org [mailto:lsr-boun...@ietf.org] *代表 *Robert
> > From: Christian Hopps
> > Sent: Thursday, April 02, 2020 5:13 AM
> > To: Robert Raszuk
> > Cc: Christian Hopps ; Les Ginsberg (ginsberg)
> > ; wangyali ; Acee Lindem
> > (acee) ; email@example.com; Tianran Zhou
> > Subject: Re: [Lsr] A new
ght nodes that
> don’t support it transparently, so the real requirement is really to know
> the sink-node (the one that is egress of the telemetry domain and must
> remove all additional encapsulations).
> As to the last point - we already have a kitchen-sink routing protocol ;-
> (besides ability to support particular technology) makes this a clear
> candidate for management plane operations. (Chris’ comment about YANG)
> On Apr 2, 2020, 2:17 PM -0700, Robert Raszuk , wrote:
> > The role of a
l need the demands
> that are coming in to all of those routers, so that you can make global
> decisions sensibly.
> Which is why we use quasi-centralized path computation engines.
> On 4/2/2020 6:16 PM, Robert Raszuk wrote:
> > >
> On Thu, Apr 2, 2020 at 4:03 PM Robert Raszuk wrote:
>> Hi Joel,
>> > Robert, you seem to be asking that we pass full information about the
>> > dynamic network state to all routers
>> No not at all.
>> Only TE headends need
> > If you consider such constrains to provide reachability for applications
> you will likely see value that in-situ telemetry is your friend here.
> Really best friend as without him you can not do the proper end to end path
> exclusion for SPT computations.
> [as wg member] Are you thinking
to collect performance
>> information form each node in the network in order to select a path with
>> bounded delay and packet loss. Would you agree?
>> On Thu, Apr 2, 2020 at 4:03 PM Robert Raszuk wrote:
, at 5:17 PM, Robert Raszuk wrote:
> > Many thx,
> > R.
> > PS. As we are talking LSR here it is strange that joining virtual LSR
> meeting is not for everyone. I was waiting and tried three times today for
> host approval to join which was not granted.
e paths" is not something I propose but is the
> property of on-path telemetry collection method.
> On Thu, Apr 2, 2020 at 4:16 PM Robert Raszuk wrote:
>> > collected only on active paths
>> Here we clearly diverge :)
, Apr 3, 2020 at 12:22 AM Acee Lindem (acee) wrote:
> As host of the meeting, I didn’t see any indication that you were waiting
> in the lobby.
> *From: *Robert Raszuk
> *Date: *Thursday, April 2, 2020 at 6:10 PM
> *To: *Christian Ho
> From: Lsr [mailto:lsr-boun...@ietf.org] On Behalf Of Christian Hopps
> > Sent: Friday, April 3, 2020 12:00 AM
> > To: Robert Raszuk
> > > On Apr 2, 2020, at 5:17 PM, Robert Raszuk wrote:
> > >
> > > Many thx,
> > &g
I think there is still some disconnect - so in an attempt to at least make
sure that we have difference of opinions let me try to restate what I was
IGP would only carry indication if tail can do inband telemetry or not - it
would *not* carry any telemetry data. IGP would
Out of pure curiosity here - how are you going to stop any other traffic
(SR or non SR) to take as much as it likes of any link being part of the
default topology ?
Lsr mailing list
I would like to respectfully disagree with your assessment.
The fact that today's IGP (or for that matter BGP) routing is static from
the perspective of not taking into consideration real performance
measurements from the data plane to me is a bug not a feature.
Building SPT based on
be what is “good enough”. I guess this may depend on
> the size of your network, its topology, and your requirements.
> We also ran tests in labs. I may share some results during my
> presentation. (no names, possibly no KPI, but some high level outcomes).
der the hood :)
On Mon, Apr 27, 2020 at 3:02 PM wrote:
> Hi Acee,
> Please see inline [Bruno2]
> *From:* Acee Lindem (acee) [mailto:a...@cisco.com]
> *Sent:* Monday, April 27, 2020 2:39 PM
> *To:* DECRAENE Bruno TGI/OLN; Robert Raszuk
> You already have a per-interface flooding ‘queue' through the
> implementation of the SRM bit in the LSDB, which must be managed on a
> per-interface basis.
Today from what I see operators (if they even change the default) normally
apply same timer value on all interfaces. If the
> Meanwhile, buffering is finite and control planes really can’t keep up.
> Forwarding is a parallel activity. The control plane is not. This presents
> us with a situation where congestion is pretty much inevitable. We need to
> deal with it.
At least we are lucky that ISIS LSPs are produced
I was under the assumption that flooding reduction is something we will
have sooner then LSP flow control. But maybe this was too optimistic.
- - -
For per peer flow control I do not get how receiver's ISIS process is to
come up with per peer timer if it may never see under congestion
> > Perhaps such flag to "slow down guys" could be send by receiver
> uniformly to all peers when under LSP flooding congestion ?
> That’s effectively what we’re proposing, tho it need not be a binary
> flag. It allows us to do simpler things saying “we’re running out of
> buffer space,
Hi Bruno & all,
[Bruno] On my side, I’ll try once and I think the LSR WG should also try to
improve IS-IS performance. May be if we want to move, we should first
release the brakes.
Well from my observations releasing the breaks means increasing the risks.
Take BGP - breaks are off and see
A side comment but your example shows another - one may say even much more
Assume we have LFA/TI-LFA enabled in the network and precomputed on B which
get's activated and shifts traffic to E when detects that C is down.
Detection is fast .. 10s-100s of milliseconds.
What if in your analysis A-D link metric is 1500 ? Still A will send to B !
See in all of this discussion from my pov it is not really about danger of
making LSDB inconsistent for much longer.
It is however about operator upgrading to new release a router, maybe even
ciency here. How about let's get some of the
> proposals being mulled over actually written, and provide some data, and
> leave all the hand-wringing and theorizing about being too-successful for
> after we've shown we could be? :)
> Both OSPF and IS-IS have area identifiers which are advertised.
> Why would we need to invent another identifier for an area?
> *From:* Robert Raszuk
> *Sent:* Monday, August 03, 2020 10:31 AM
> *To:* Les Gin
*> But currently the draft is defining a SID which is NOT associated with a
> *But if the proposal is to use a SID associated with a prefix then I see
no need to invent a new SID advertisement.*
How about we first define an "Area Prefix" (IP address being a property of
e add (if there is any) of an Area SID is that I don’t have to
> assign an anycast address to all nodes. I can associate the SID with an
> identifier that is already shared and known by all nodes in the area.
> If you don’t see that as worthwhile, fine, let’s abandon the Area SID i
If I am not mistaken that additional overhead would only need to happen on
participating in this game ABRs. If so I think this is worthwhile.
> Well, that becomes an anycast tunnel endpoint
Endpoint ? Not midpoint ? Or better sort of ski lift transit point with
embedded direction in
> [WAJ] Such information is for underlay link state and should be flooded
> via IGP? The ambiguity arises from IGP summary behavior and should be
> solved by itself?
Well if we look at this problem from a distance while on surface it seems
like an IGP issue (not to mention some which use BGP
> or black-holing on aggregates since we cannot "back-off" generic LPM
packet forwarding when we
> realize we're @ a dead end due to aggregation.
I hope you are not stating that aggregation is a bad thing here and all we
should be distributing are host routes :)
But to your point - IGP
To: Robert Raszuk
Cc: Mark Tinka , na...@nanog.org ,
On Thu, 18 Jun 2020 at 13:28, Robert Raszuk wrote:
> To your IGP point let me observe that OSPF runs over IP and ISIS does
not. That is first fundamental difference. There are customers using both
all over the wo
> It’s very clear that this is inadequate.
Doesn't this really depend how you architect multiple levels ? Sure you
have some physical topology - but it seems to me that the trick is in
properly laying out levels on top of them and between them.
To my original question - how many levels
On Thu, Jun 4, 2020 at 6:42 PM wrote:
> Dear Gentlebeings,
> I would like to formally request working group adoption of “Area Proxy for
> IS-IS” (https://tools.ietf.org/html/draft-li-lsr-isis-area-proxy-03).
> The goal of this work is to improve scalability of IS-IS when
On Wed, Jun 10, 2020 at 9:28 PM Christian Hopps wrote:
> This begins a 2 week WG adoption call for the following draft:
> The draft would be adopted on the Experimental track.
> Please indicate your
I would like to question your assessment that signalling unreachable routes
Imagine hierarchical network with areas. Under no failures area 1
advertises to area 0 summary LSA with 220.127.116.11/24. That block covers PE's
loopbacks which within the area are /32s. Those
cannot detect the reachability of 18.104.22.168/32.
> Zhibo Hu
> *From:* Robert Raszuk [mailto:rob...@raszuk.net]
> *Sent:* Tuesday, July 28, 2020 5:18 PM
> *To:* Acee Lindem (acee)
> *Cc:* Aijun Wang ; firstname.lastname@example.org; Huzhibo <
> 胡志波 Hu Zhibo
> Mobile: +86-18618192287
> Email: huzh...@huawei.com
> *发件人：*Acee Lindem (acee)
> *收件人：*Peter Psenak ;Robert Raszuk <
> *抄 送：*Aijun Wang ;Xiaoyaqun
> ;Aijun Wang ;lsr <
> *时 间：*202
specific when it is still active BGP path and you too quickly remove
info about unreachability.
On Thu, Jul 30, 2020 at 4:21 PM Peter Psenak wrote:
> On 30/07/2020 16:14, Robert Raszuk wrote:
> > > 2：For bgp example，when the pe node down，the bgp peer must down
> > 2：For bgp example，when the pe node down，the bgp peer must down within
> > 30 mintus，It will not get it up via cancle advertise pua.
> for the above it is sufficient to advertise the unreachability for few
> seconds from each ABR independently. That would be a much more solid
Hi Tony & WG,
The changes which went into sections 4.3.2 & 4.4.13 do address my
suggestions made earlier to the list. So I do support the current version.
With the option of having a configurable area prefix this delivers quite a
Also the current text says:
"Other uses of
1 - 100 of 120 matches
Mail list logo