Re: [Lsr] IGP TE Metric Extensions

2018-06-05 Thread Robert Raszuk
​Muthu,​ > ​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

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

2018-08-24 Thread Robert Raszuk
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 > reason

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

2018-08-27 Thread Robert Raszuk
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

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

2018-08-27 Thread Robert Raszuk
> > > > >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 >

Re: [Lsr] [GROW] FW: New Version Notification for draft-gu-network-mornitoring-protol-00.txt

2018-07-11 Thread Robert Raszuk
Tim, 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.

Re: [Lsr] Fwd: New Version Notification for draft-li-dynamic-flooding-04.txt

2018-04-06 Thread Robert Raszuk
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

Re: [Lsr] Fwd: New Version Notification for draft-li-dynamic-flooding-04.txt

2018-04-07 Thread Robert Raszuk
Les, 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

Re: [Lsr] Fwd: New Version Notification for draft-li-dynamic-flooding-04.txt

2018-04-07 Thread Robert Raszuk
clearly a different flooding > topology from the one IGPs use today is required or we will have > accomplished nothing. > > > >Les > > > > > > *From:* Lsr <lsr-boun...@ietf.org> *On Behalf Of *Robert Raszuk > *Sent:* Saturday, April 07, 2018 10:44 A

Re: [Lsr] Comments on draft-ymbk-lsvr-lsoe-00

2018-03-24 Thread Robert Raszuk
Dear Authors, 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

Re: [Lsr] IS-IS over TCP

2018-11-07 Thread Robert Raszuk
Hi Henk, > - 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

Re: [Lsr] IS-IS over TCP

2018-11-07 Thread Robert Raszuk
All, > 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

Re: [Lsr] LSR: Using DSCP for path/topology selection Q

2018-11-15 Thread Robert Raszuk
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. Thx, R. 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:

Re: [Lsr] LSR: Using DSCP for path/topology selection Q

2018-11-15 Thread Robert Raszuk
Hey Toerless, 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

Re: [Lsr] LSR: Using DSCP for path/topology selection Q

2018-11-15 Thread Robert Raszuk
Jeff, > 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

Re: [Lsr] IS-IS over TCP

2018-11-07 Thread Robert Raszuk
draft-hsmit-lsr-isis-flooding-over-tcp/ .. > > > > Please do not confuse the two. > > > >Les > > > > > > *From:* Robert Raszuk > *Sent:* Wednesday, November 07, 2018 12:39 AM > *To:* Les Ginsberg (ginsberg) > *Cc:* hhws...@xs4all.nl; Tony Li ;

Re: [Lsr] IS-IS over TCP

2018-11-07 Thread Robert Raszuk
Hi Les, > There are existing and successful deployments of an instance with thousands of > neighbors and thousands of nodes in a network and sub-second convergence is supported. While I completely agree with your above observation (and as a matter of fact first person to tell me that was

Re: [Lsr] Teasing us with secrets

2018-11-12 Thread Robert Raszuk
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 sauce". This thread seems to be a good example of that. In BGP there was similar

Re: [Lsr] Open issues with Dynamic Flooding: Including LANs in the Flooding Topology

2019-04-02 Thread Robert Raszuk
For the purpose of this discussion can someone quote the definition of LAN ? Why ? *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 passive interface. *2* In slightly older DCs there are redundant

Re: [Lsr] Open issues with Dynamic Flooding: Including LANs in the Flooding Topology

2019-04-03 Thread Robert Raszuk
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 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

Re: [Lsr] Open issues with Dynamic Flooding: Including LANs in the Flooding Topology

2019-04-03 Thread Robert Raszuk
: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

Re: [Lsr] LANs in IGPs

2019-04-03 Thread Robert Raszuk
> 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

Re: [Lsr] LANs in IGPs

2019-04-03 Thread Robert Raszuk
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

[Lsr] LANs in IGPs

2019-04-03 Thread Robert Raszuk
Hi Les, 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

Re: [Lsr] Open issues with Dynamic Flooding

2019-03-05 Thread Robert Raszuk
> 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

Re: [Lsr] Open issues with Dynamic Flooding

2019-03-05 Thread Robert Raszuk
ely selected* all 4 paths before you manage to distribute new flooding topology you can always flood over 6 :) Best, R. On Tue, Mar 5, 2019 at 9:17 PM Peter Psenak wrote: > Robert, > > On 05/03/2019 20:12 , Robert Raszuk wrote: > > > >> Slow convergence is

Re: [Lsr] Open issues with Dynamic Flooding

2019-03-05 Thread Robert Raszuk
> 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. r. ___ Lsr mailing list Lsr@ietf.org

Re: [Lsr] Open issues with Dynamic Flooding

2019-03-05 Thread Robert Raszuk
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. Thx, r. On Tue, Mar 5, 2019 at 8:36 PM Tony Przygienda wrote: > > > On Tue, Mar 5, 2019 at 11:12 AM Robert Rasz

[Lsr] draft-ketant-idr-bgp-ls-bgp-only-fabric

2019-03-10 Thread Robert Raszuk
Hi Ketan, I have read your proposal of defining topology flooding in BGP with interest. 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

Re: [Lsr] Clarification on co-existance of dynamic flooding aware and not aware nodes

2019-03-07 Thread Robert Raszuk
of including those 100s of TORs in constructing and distributing flooding graph. But spec seems quite silent on such deployment model hence the post. Thx, R. On Thu, Mar 7, 2019 at 12:11 PM Peter Psenak wrote: > Hi Robert, > > On 07/03/2019 12:00 , Robert Raszuk wrote: > > Hi, >

[Lsr] Clarification on co-existance of dynamic flooding aware and not aware nodes

2019-03-07 Thread Robert Raszuk
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 access

Re: [Lsr] IS-IS lite (an aside)..

2019-03-08 Thread Robert Raszuk
. 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

Re: [Lsr] Clarification on co-existance of dynamic flooding aware and not aware nodes

2019-03-07 Thread Robert Raszuk
, 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

Re: [Lsr] Moving Forward [Re: Flooding Reduction Draft Redux]

2019-02-06 Thread Robert Raszuk
Hi Peter, 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

Re: [Lsr] WG Adoption Call for draft-li-lsr-dynamic-flooding-02 + IPR poll.

2019-02-11 Thread Robert Raszuk
Support. r. 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

Re: [Lsr] Moving Forward [Re: Flooding Reduction Draft Redux]

2019-02-03 Thread Robert Raszuk
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 distributed calculations. However one may observe that separate distributed

Re: [Lsr] Moving Forward [Re: Flooding Reduction Draft Redux]

2019-02-03 Thread Robert Raszuk
> 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

Re: [Lsr] Moving Forward [Re: Flooding Reduction Draft Redux]

2019-02-02 Thread Robert Raszuk
Sound like best plan fwd. Thx, R. 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 >

Re: [Lsr] Working Group Last Call for "OSPF Link Traffic Engineering (TE) Attribute Reuse" - draft-ietf-ospf-te-link-attr-reuse-07.txt

2019-04-15 Thread Robert Raszuk
Peter, 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

Re: [Lsr] draft-ietf-lsr-isis-srv6-extensions-00

2019-05-31 Thread Robert Raszuk
Hi Paul, It has been pointed out about month ago :) Ref: https://mailarchive.ietf.org/arch/msg/lsr/hbmJqgpnfjcsxiD40AGaTMA2tic Best, R. 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: > > > >

Re: [Lsr] 答复: 答复: Option B from "Migration between normal flooding and flooding reduction"

2019-05-29 Thread Robert Raszuk
Hey Peter, > > 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 > flooding? > > yes and we have that in the draft: > > "When the Area Leader advertises algorithm 0 in its Area Leader Sub- > TLV

Re: [Lsr] Working Group Adoption Call for "IS-IS Extensions to Support Routing over IPv6 Dataplane" - draft-bashandy-isis-srv6-extensions-05.txt

2019-05-09 Thread Robert Raszuk
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. Thx, R. On Thu, May 9, 2019 at 3:50 PM Acee

Re: [Lsr] Migration between normal flooding and flooding reduction

2019-05-22 Thread Robert Raszuk
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

Re: [Lsr] Summary of WGLC discussion about draft-ietf-isis-te-app-06.txt and draft-ietf-ospf-te-link-attr-reuse-07.txt

2019-05-24 Thread Robert Raszuk
> 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 IDR will

Re: [Lsr] FW: New Version Notification for draft-bonica-lsr-crh-isis-extensions-00.txt

2019-05-14 Thread Robert Raszuk
Hi Ron, 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

Re: [Lsr] LSR Working Group Adoption Call for "Hierarchical IS-IS" - draft-li-lsr-isis-hierarchical-isis-01

2019-08-13 Thread Robert Raszuk
> lsr-isis-extended-hierarchy Sounds great ! ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] LSR Working Group Adoption Call for "Hierarchical IS-IS" - draft-li-lsr-isis-hierarchical-isis-01

2019-08-13 Thread Robert Raszuk
> What would you suggest? How about: draft-ietf-lsr-n-level-isis-00 ? r. On Tue, Aug 13, 2019 at 4:42 PM wrote: > > Robert, > > Thank you for your support. What would you suggest? > > Tony > > > On Aug 13, 2019, at 6:40 AM, Robert Raszuk wrote: > > Sup

Re: [Lsr] LSR Working Group Adoption Call for "Hierarchical IS-IS" - draft-li-lsr-isis-hierarchical-isis-01

2019-08-16 Thread Robert Raszuk
S-IS are no different then one > instance of two different protocols. > > But this is decidedly NOT the intent of the draft. > > > >Les > > > > > > *From:* Lsr *On Behalf Of * tony...@tony.li > *Sent:* Friday, August 16, 2019 11:01 AM > *To:* Tony Li

Re: [Lsr] 答复: LSR Working Group Adoption Call for "Hierarchical IS-IS" - draft-li-lsr-isis-hierarchical-isis-01

2019-08-15 Thread Robert Raszuk
Hi Tony, > 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 failed. While it is easy to envision this with DV protocols say BGP - do you have any pointer to

Re: [Lsr] LSR Working Group Adoption Call for "Hierarchical IS-IS" - draft-li-lsr-isis-hierarchical-isis-01

2019-08-19 Thread Robert Raszuk
Hi Huaimo, 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

Re: [Lsr] LSR Working Group Adoption Call for "Hierarchical IS-IS" - draft-li-lsr-isis-hierarchical-isis-01

2019-08-13 Thread Robert Raszuk
Support. 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. Thx, R. On Mon, Aug 12, 2019 at 11:57 PM Acee Lindem (acee)

Re: [Lsr] Dynamic flow control for flooding

2019-07-23 Thread Robert Raszuk
Hi Tony, 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

Re: [Lsr] Dynamic flow control for flooding

2019-07-24 Thread Robert Raszuk
Hi Tony, > 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

Re: [Lsr] Dynamic flow control for flooding

2019-07-24 Thread Robert Raszuk
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

Re: [Lsr] Dynamic flow control for flooding

2019-07-24 Thread Robert Raszuk
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 > after > a reboot, 22 years ago. I have no idea if there are any implementations > that > use the overload-bit to alleviate slow conv

Re: [Lsr] Dynamic flow control for flooding

2019-07-24 Thread Robert Raszuk
*[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

Re: [Lsr] [spring] IETF 106 - SPRING agenda

2019-11-07 Thread Robert Raszuk
*> 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. Best, Robert. PS. As to the proposal in draft

Re: [Lsr] Flow Control Discussion for IS-IS Flooding Speed

2020-02-19 Thread Robert Raszuk
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. > > > >Les > > > > > > *From:* Lsr *On Behalf Of *

Re: [Lsr] Methods to label the passive interfaces within ISIS

2020-01-10 Thread Robert Raszuk
Hi Tony, 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

Re: [Lsr] 答复: Is it necessary to expand the IS-IS level to 8?

2020-01-06 Thread Robert Raszuk
Aijun, > 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. > Really ?

Re: [Lsr] Methods to label the passive interfaces within ISIS

2020-01-07 Thread Robert Raszuk
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 >

Re: [Lsr] A new version of I-D, draft-liu-lsr-isis-ifit-node-capability-02

2020-04-02 Thread Robert Raszuk
Message- > > From: Christian Hopps > > Sent: Thursday, April 02, 2020 5:13 AM > > To: Robert Raszuk > > Cc: Christian Hopps ; Les Ginsberg (ginsberg) > > ; wangyali ; Acee Lindem > > (acee) ; lsr@ietf.org; Tianran Zhou > > > > Subject: Re: [Lsr] A new

Re: [Lsr] A new version of I-D, draft-liu-lsr-isis-ifit-node-capability-02

2020-04-02 Thread Robert Raszuk
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 ;-

Re: [Lsr] A new version of I-D, draft-liu-lsr-isis-ifit-node-capability-02

2020-04-02 Thread Robert Raszuk
configuration > (besides ability to support particular technology) makes this a clear > candidate for management plane operations. (Chris’ comment about YANG) > > Cheers, > Jeff > On Apr 2, 2020, 2:17 PM -0700, Robert Raszuk , wrote: > > Jeff. > > > The role of a

Re: [Lsr] A new version of I-D, draft-liu-lsr-isis-ifit-node-capability-02

2020-04-02 Thread Robert Raszuk
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. > > Yours, > Joel > > On 4/2/2020 6:16 PM, Robert Raszuk wrote: > > > > >

Re: [Lsr] A new version of I-D, draft-liu-lsr-isis-ifit-node-capability-02

2020-04-02 Thread Robert Raszuk
t; > 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

Re: [Lsr] A new version of I-D, draft-liu-lsr-isis-ifit-node-capability-02

2020-04-02 Thread Robert Raszuk
> > 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

Re: [Lsr] A new version of I-D, draft-liu-lsr-isis-ifit-node-capability-02

2020-04-02 Thread Robert Raszuk
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? >> >> Regards, >> Greg >> >> On Thu, Apr 2, 2020 at 4:03 PM Robert Raszuk wrote: >> >>&g

Re: [Lsr] problem joining interim [Re: A new version of I-D, draft-liu-lsr-isis-ifit-node-capability-02]

2020-04-02 Thread Robert Raszuk
, 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.

Re: [Lsr] A new version of I-D, draft-liu-lsr-isis-ifit-node-capability-02

2020-04-02 Thread Robert Raszuk
e paths" is not something I propose but is the > property of on-path telemetry collection method. > > Regards, > Greg > > On Thu, Apr 2, 2020 at 4:16 PM Robert Raszuk wrote: > >> > collected only on active paths >> >> Here we clearly diverge :) >> >

Re: [Lsr] problem joining interim [Re: A new version of I-D, draft-liu-lsr-isis-ifit-node-capability-02]

2020-04-02 Thread Robert Raszuk
, 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. > > Thanks, > > Acee > > > > *From: *Robert Raszuk > *Date: *Thursday, April 2, 2020 at 6:10 PM > *To: *Christian Ho

Re: [Lsr] problem joining interim [Re: A new version of I-D, draft-liu-lsr-isis-ifit-node-capability-02]

2020-04-03 Thread Robert Raszuk
> 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

Re: [Lsr] A new version of I-D, draft-liu-lsr-isis-ifit-node-capability-02

2020-04-03 Thread Robert Raszuk
Hi Tony, 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 suggesting. IGP would only carry indication if tail can do inband telemetry or not - it would *not* carry any telemetry data. IGP would

Re: [Lsr] Using IS-IS Multi-Topology (MT) for Segment Routing basedVirtual Transport Network

2020-03-30 Thread Robert Raszuk
Hi, 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 ? Thx, R. ___ Lsr mailing list Lsr@ietf.org https://www.ietf.org/mailman/listinfo/lsr

Re: [Lsr] A new version of I-D, draft-liu-lsr-isis-ifit-node-capability-02

2020-04-02 Thread Robert Raszuk
Hi Les, 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

Re: [Lsr] Flow Control Discussion for IS-IS Flooding Speed

2020-04-27 Thread Robert Raszuk
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). > > > >

Re: [Lsr] Flow Control Discussion for IS-IS Flooding Speed

2020-04-27 Thread Robert Raszuk
der the hood :) Cheers, R. 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

Re: [Lsr] Flow Control Discussion for IS-IS Flooding Speed

2020-04-27 Thread Robert Raszuk
Hi Tony, > 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

Re: [Lsr] Flow Control Discussion for IS-IS Flooding Speed

2020-04-27 Thread Robert Raszuk
> 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

Re: [Lsr] Flow Control Discussion for IS-IS Flooding Speed

2020-04-27 Thread Robert Raszuk
Ahh ok. 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

Re: [Lsr] Flow Control Discussion for IS-IS Flooding Speed

2020-04-27 Thread Robert Raszuk
> > > 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,

Re: [Lsr] Flow Control Discussion for IS-IS Flooding Speed

2020-04-24 Thread Robert Raszuk
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

Re: [Lsr] Flooding across a network

2020-05-05 Thread Robert Raszuk
Hi Les, A side comment but your example shows another - one may say even much more serious issue. 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. Now

Re: [Lsr] Flooding across a network

2020-05-07 Thread Robert Raszuk
Hey Jeff, 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 reading release

Re: [Lsr] Flooding across a network

2020-05-06 Thread Robert Raszuk
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? :) > > Thanks, > Chris. > > > &

Re: [Lsr] New Version Notification for draft-ietf-lsr-isis-area-proxy-02.txt

2020-08-03 Thread Robert Raszuk
ert – > > > > Both OSPF and IS-IS have area identifiers which are advertised. > > Why would we need to invent another identifier for an area? > > > > Les > > > > > > *From:* Robert Raszuk > *Sent:* Monday, August 03, 2020 10:31 AM > *To:* Les Gin

Re: [Lsr] New Version Notification for draft-ietf-lsr-isis-area-proxy-02.txt

2020-08-03 Thread Robert Raszuk
*Les,* *> But currently the draft is defining a SID which is NOT associated with a prefix.* + > *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 an area)

Re: [Lsr] New Version Notification for draft-ietf-lsr-isis-area-proxy-02.txt

2020-08-03 Thread Robert Raszuk
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

Re: [Lsr] New Version Notification for draft-ietf-lsr-isis-area-proxy-02.txt

2020-08-03 Thread Robert Raszuk
Hi Tony, 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

Re: [Lsr] New Version Notification for draft-wang-lsr-prefix-unreachable-annoucement-03.txt

2020-07-31 Thread Robert Raszuk
> > [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

Re: [Lsr] WG adoption call for draft-li-lsr-isis-area-proxy-06

2020-06-15 Thread Robert Raszuk
Tony P, > 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

[Lsr] Fwd: Devil's Advocate - Segment Routing, Why?

2020-06-18 Thread Robert Raszuk
, Why? To: Robert Raszuk Cc: Mark Tinka , na...@nanog.org , cisco-nsp NSP 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

Re: [Lsr] WG adoption call for draft-li-lsr-isis-area-proxy-06

2020-06-15 Thread Robert Raszuk
Hi Tony, > 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

Re: [Lsr] Request for Working Group Adoption: Area Proxy

2020-06-04 Thread Robert Raszuk
Support. Rgs, R. 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

Re: [Lsr] WG adoption call for draft-li-lsr-isis-area-proxy-06

2020-06-11 Thread Robert Raszuk
Support. Thx, R. On Wed, Jun 10, 2020 at 9:28 PM Christian Hopps wrote: > This begins a 2 week WG adoption call for the following draft: > > https://datatracker.ietf.org/doc/draft-li-lsr-isis-area-proxy/ > > The draft would be adopted on the Experimental track. > > Please indicate your

Re: [Lsr] New Version Notification for draft-wang-lsr-prefix-unreachable-annoucement-03.txt

2020-07-28 Thread Robert Raszuk
Hello Acee, I would like to question your assessment that signalling unreachable routes is unnecessary. Imagine hierarchical network with areas. Under no failures area 1 advertises to area 0 summary LSA with 1.1.1.0/24. That block covers PE's loopbacks which within the area are /32s. Those

Re: [Lsr] New Version Notification for draft-wang-lsr-prefix-unreachable-annoucement-03.txt

2020-07-29 Thread Robert Raszuk
cannot detect the reachability of 1.1.1.1/32. > > > > Thanks > > > > Zhibo Hu > > *From:* Robert Raszuk [mailto:rob...@raszuk.net] > *Sent:* Tuesday, July 28, 2020 5:18 PM > *To:* Acee Lindem (acee) > *Cc:* Aijun Wang ; lsr@ietf.org; Huzhibo < > huz

Re: [Lsr] New Version Notification for draft-wang-lsr-prefix-unreachable-annoucement-03.txt

2020-07-30 Thread Robert Raszuk
- > 胡志波 Hu Zhibo > Mobile: +86-18618192287 > Email: huzh...@huawei.com > *发件人:*Acee Lindem (acee) > *收件人:*Peter Psenak ;Robert Raszuk < > rob...@raszuk.net> > *抄 送:*Aijun Wang ;Xiaoyaqun > ;Huzhibo > ;Aijun Wang ;lsr < > lsr@ietf.org> > *时 间:*202

Re: [Lsr] New Version Notification for draft-wang-lsr-prefix-unreachable-annoucement-03.txt

2020-07-30 Thread Robert Raszuk
specific when it is still active BGP path and you too quickly remove info about unreachability. Thx R. 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 &g

Re: [Lsr] New Version Notification for draft-wang-lsr-prefix-unreachable-annoucement-03.txt

2020-07-30 Thread Robert Raszuk
> > 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 > proposal.

Re: [Lsr] Fwd: I-D Action: draft-ietf-lsr-isis-area-proxy-03.txt

2020-08-25 Thread Robert Raszuk
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 powerful extension. Also the current text says: "Other uses of

  1   2   >