Re: [Lsr] IS-IS over TCP

>BTW, there is another reason for our proposal. With the incoming drafts about flooding-topology-reduction, there is a new problem. >All these proposals have situations where non-flooding adjacencies suddenly change to flooding adjacencies. When that happens, the LSDBs need to

Re: [Lsr] IS-IS over TCP

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] IS-IS over TCP

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

Les Ginsberg (ginsberg) wrote 2018-11-07 17:06: The problem that RFC6213 tries to solve is a case where one of the neighbors is thinking that the other does not support BFD. And thus the lack of BFD is not used as an indication that something is wrong. Right ? [Les:] This is not correct.

Re: [Lsr] IS-IS over TCP

Jeffrey Haas wrote 2018-11-07 20:56: I guess my question to those who live in IGP land is how often is this a problem? In the case of an IGP, the backpressure means you have databases that are out of sync and end up with bad forwarding. As discussed below, if you have multiple flooding

Re: [Lsr] IS-IS over TCP

Henk, On Wed, Nov 07, 2018 at 03:06:45PM +0100, Henk Smit wrote: > Jeffrey Haas wrote on 2018-11-06 05:20: > > >I'm ambivalent of the transport, but agree that TCP shouldn't be > >the default > >answer. > > I picked TCP because every router has a working TCP implementation. Having just done a

Re: [Lsr] IS-IS over TCP

Henk - Thanx for the thoughtful response. I'll do my best to respond in kind. Inline. > -Original Message- > From: Henk Smit > Sent: Wednesday, November 07, 2018 5:26 AM > To: Les Ginsberg (ginsberg) > Cc: tony...@tony.li; lsr@ietf.org > Subject: Re: [Lsr] IS-IS over TCP > > > Hi

Re: [Lsr] IS-IS over TCP

Hi Jeff, Jeffrey Haas wrote on 2018-11-06 05:20: I'm ambivalent of the transport, but agree that TCP shouldn't be the default answer. I picked TCP because every router has a working TCP implementation. And TCP is good enough for BGP. And thus also considered good enough for LSVR. If

Re: [Lsr] IS-IS over TCP

Hi Les, Comments inline. Les Ginsberg (ginsberg) schreef op 2018-11-07 05:09: 1)IS-IS PDUs are sent directly over layer 2 - whereas TCP (or other transport) are sent over Layer3. This means we have a potential fate sharing issue where IIHs (which continue to be sent over Layer 2 in your

Re: [Lsr] Comments on draft-chunduri-lsr-isis-mt-deployment-cons-01

Les, Thanks for your comments. > If we were to proceed with this draft at all, I therefore think we should limit the scope to merely explaining what the requirements for correct operation are using the various modes. Agree and this aspect is baked-in along with some common pitfalls. It

Re: [Lsr] IS-IS over TCP

Hi Les, I am very well aware about different scopes of both drafts. Actually I read them all. But just wanted to make sure your point about ISIS working fine today with 1000s node networks is really a prove that flooding optimisation is still *practically* needed/required. Btw ... Henk has a

Re: [Lsr] IS-IS over TCP

Robert – The comment being discussed here is in regards to the potential benefits of altering IS-IS to use a different way of flooding over an interface. Whether we agree/disagree on this does not have any bearing on the high amount of redundant flooding which occurs in a highly meshed network

Re: [Lsr] IS-IS over TCP

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] IPR Call for "YANG Data Model for OSPF Protocol" - draft-ietf-ospf-yang-17

I’m not aware of any IPR related to this draft. Derek Yeung de...@arrcus.com Main: 408.884.1965 [cid:image001.png@01D4762F.80F88C60] 2077 Gateway Place, Suite 250 San Jose, CA. 95110 The contents of this message, together with any attachments, are intended only for