Subject: Re: [Idr] draft-scholl-idr-advisory-00

From: "Neil J. McRae" <[email-masked]>
Date: Wed, 25 Mar 2009 11:15:46 +0000

Im sure its that useful  Dave but BGP is a routing protocol and I think by bending it into this shape we just put most risk into routing infrastructure. Personally I'd prefer not to do that.

-----Original Message-----
From: David Freedman <[email-masked]>
Sent: 25 March 2009 09:47
To: [email-masked]
Cc: [email-masked]
Subject: RE: [Idr] draft-scholl-idr-advisory-00

I'm not seeing the point of this as replacing any operational
 process at all, it is simply a tool to assist a human operator
 who has access to their own routers (either directly or via NMS syslog/traps)
 
 I quite like the analogy of the path-trace buffer, if a human is looking at it,
 it can cut down on troubleshooting time significantly.
 
 Dave.
 
 ------------------------------------------------
 David Freedman
 Group Network Engineering
 Claranet Limited
 http://www.clara.net

 -----Original Message-----
 From: Neil J. McRae [mailto:[email-masked]]
 Sent: Wed 3/25/2009 09:41
 To: David Freedman
 Cc: [email-masked]
 Subject: Re: [Idr] draft-scholl-idr-advisory-00
 
 David,
 
 > Look, the purpose of this is to provide information in-band with the
 > session, if we want all communication to occur via email then fine,
 > don't originate or accept any ADVISORY messages,
 > the point being there are many operators out there who would like to see
 > messages such as :
 
 It looks like we are trying to work around poor operational process by
 messing around with routing protocols. I can't see that being a scalable
 solution in the longer term, history has demonstrated that time and time
 again.
 
 Regards,
 Neil
 --
 Neil J. McRae -- Alive and Kicking.
 [email-masked]

---

From: David Freedman <[email-masked]>
Date: Wed, 25 Mar 2009 11:24:28 +0000

>Dave but BGP is a routing protocol and I think by bending it into this shape we 

But what is our alternative here, propose that NOTIFICATION no longer be
terminal in all cases? The recent case of the transitive attributes has
highlighted that we need a multi-pronged approach here , and whilst
creating a type of non-terminal NOTIFICATION message (which would
require significant code change and is counter-productive) , is not an
option, ADVISORY seems like the next best thing.

I'm happy with it, it is short and it is simple.

If you don't want to send ADVISORY messages to me or allow me to send
them to you, just don't negotiate the ADVISORY capability, which can be
the vendor default position.

Dave.

---

From: Rob Shakir <[email-masked]>
Date: Wed, 25 Mar 2009 11:30:52 +0000

On Wed, Mar 25, 2009 at 11:15:46AM +0000, Neil J. McRae wrote:
> Im sure its that useful  Dave but BGP is a routing protocol and I think by
> bending it into this shape we just put most risk into routing infrastructure.
> Personally I'd prefer not to do that.

I agree that there is some scope for potential issues with the implementation of
this idea, but I do not agree that a suggestion like this is putting 'most risk
into routing infrastructure' - how is the risk that is added by implementing
this capability any different to the risk imposed by adding any other new
capability?

I've discussed this with a number of operators, and feel that this extension
would be extremely useful. As Dave says, this is not going to replace other
communications between NOCs, but there are definitely a variety of deployments
where this would be useful.

If this protocol is adopted, I would urge against the RFC defining a set of
standardised messages -- and rather leave this open to implementation. This then
leaves some flexibility with operators and implementors to utilise this
capability as required.

I'd like to add my support to Tom's draft.

Kind regards,
Rob

--
Rob Shakir                      <[email-masked]>
Network Development Engineer    GX Networks/Vialtus Solutions
ddi: +44208 587 6077            mob: +44797 155 4098
pgp: 0xc07e6deb                 nic-hdl: RJS-RIPE

This email is subject to: http//www.vialtus.com/disclaimer.html