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 imp

Re: [Lsr] IS-IS over TCP

On Tue, Nov 06, 2018 at 10:51:33AM +0700, tony...@tony.li wrote: > > Per the WG meeting, discussing on the list: > > This is good work and I support it. Ditto. > I would remind folks that TCP is NOT the only transport protocol available > and that perhaps we should be considering QUIC while

Re: [Lsr] AD Review for draft-ietf-ospf-yang-21

On Thu, Jun 27, 2019 at 03:11:21PM +, Les Ginsberg (ginsberg) wrote: > I am firmly on the side of Acee on this one – and I think more attention > needs to be paid to his initial answer: “B-F-D”. > > The implications of this are that we do not expect control plane to have > finer granularity

Re: [Lsr] [Idr] draft-merciaz-idr-bgp-bfd-strict-mode

Les, On Sun, Jul 28, 2019 at 12:23:05AM +, Les Ginsberg (ginsberg) wrote: > I have a related question: > > In the case where the BGP neighbor is multiple hops away, what benefit does > BFD dampening provide? > (Note that I am assuming that there likely would be single hop BFD sessions >

Re: [Lsr] Working Group Last Call for "OSPF Strict-Mode for BFD" - draft-ietf-lsr-ospf-bfd-strict-mode-04

Les, > On Jan 31, 2022, at 2:47 PM, Les Ginsberg (ginsberg) > wrote: > I have not asked for BFD extensions. > I have stated that “IF” additional functionality is required from BFD that > the proper place to discuss that is in the BFD WG – and such discussions are > definitely not in scope of

[Lsr] YANG requirements for IDR drafts (was Re: [Idr] draft-head-idr-bgp-ls-isis-fr-01 - WG adoption call (6/6 to 6/20))

Robert, > On Jun 30, 2022, at 6:56 PM, Robert Raszuk wrote: > > Isn't the YANG section a requirement for all protocol extension documents > before they are sent for publications these days ? > We're not yet to the point where extensions to YANG modules are part of base IETF work, but

Re: [Lsr] [Idr] IGP Monitoring Protocol

Jeff, > On Jul 10, 2022, at 5:14 PM, Jeff Tantsura wrote: > > Thanks Sue! > > We don’t have to always reinvent the wheel (at least not every time ) > I’m aware of at least 1 implementation streaming LSDB for TE consumers (gRPC) > There are most probably some other vendor specific

Re: [Lsr] [Idr] [GROW] IGP Monitoring Protocol

Robert, > On Jul 11, 2022, at 12:16 PM, Robert Raszuk wrote: > On Mon, Jul 11, 2022 at 6:09 PM Jeffrey Haas <mailto:jh...@pfrc.org>> wrote: > Tianran, > > Please note that nothing prohibits BGP-LS from being distributed over BMP > today aside from implementation

Re: [Lsr] [Idr] [GROW] IGP Monitoring Protocol

Tianran, Please note that nothing prohibits BGP-LS from being distributed over BMP today aside from implementation support. It's just another AFI/SAFI. -- Jeff > On Jul 11, 2022, at 10:02 AM, Tianran Zhou > wrote: > > Hi Robert, > > I see this name very similar to BMP bgp monitoring

Re: [Lsr] [Idr] [GROW] IGP Monitoring Protocol

Tianran, On Jul 11, 2022, at 10:42 PM, Tianran Zhou wrote: > > Hi Jeff, > > Our work is not to propose a new protocol. > https://datatracker.ietf.org/doc/html/draft-gu-opsawg-network-monitoring-igp-01 > > >

Re: [Lsr] [Idr] IGP Monitoring Protocol

Chris, > On Jul 16, 2022, at 6:19 PM, Christian Hopps wrote: > > > Robert Raszuk writes: > >> Btw this independent attempt by two WG groups to normalize link state >> data is a clear proof that the YANG model has failed here. > > I'm not sure which "YANG model" you are referring to here