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

From: "David Freedman" <[email-masked]>
Date: Wed, 25 Mar 2009 01:10:00 -0000

>You want the router to write email to "4000" NOCs informing them of
>pending maintenance?  I'm pretty sure there are better tools available
>for that.

Sure, and it doesn't have to contact them all, the idea is to make this
as configurable
as possible such to both send_to and receive_from routers / messages of
interest.

> I like the idea that the same person who logs onto the router
>o find out why a neighbor is down will have information about that
>maintenance available in their log or `show bgp neighbor` output.

You would think, but actually , most networks out there ignore such
events if they are brief
do not directly affect their customers (such as peerings which do not
need to be used)

> * No need to modify BGP protocol (only if at all as an option we
>Unless you want those email addresses to be learnt from the BGP neighbor
>as you suggest.
> * Deployable today via already existing operating systems
>Really?  I didn't know IOS knew how to write and send email.

Sadly yes, it can :(
http://blog.ioshints.info/2008/09/send-e-mail-after-router-reload.html

> * No need to modify and parse anything at the potential 1000s of peers.
>Your email-based solution has an advantage over BGP advisory because of
>message parsing?  Wait, are we going to parse those NOC emails and do
>something useful with them?  If so, we better write a tool for that,
>just like we would need one to parse information from the router syslog
>messages or `show bgp neighbor`.  If not, a human is going to have to
>read those messages.  How does your proposal have an advantage in either
>parsing work or savings in man-hours vs the Scholl plan?

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 :

- You are about to trip my max_prefix for your session (please hassle me
into increasing it)

- You are sending me lots of traffic which is failing some kind of
policy / uRPF check ( you are a DoS source today )

- Our maintenance went wrong , Oops! we will be backing out the changes,
expect session to flap again (saves public shaming)

and countless other examples...

Dave.

------------------------------------------------
David Freedman
Group Network Engineering 
Claranet Limited
http://www.clara.net

---

From: "Neil J. McRae" <[email-masked]>
Date: Wed, 25 Mar 2009 09:41:42 -0000 (GMT)

David,

> the point being there are many operators out there who would like to see

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 09:47:23 -0000

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. 

-----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,

Regards,
Neil

---

From: Richard A Steenbergen <[email-masked]>
Date: Wed, 25 Mar 2009 10:28:34 -0500

> solution in the longer term, history has demonstrated that time and time

It seems like your objection is purely theoretical, with no evidence of
any practical problems at all. Please explain to me, in specific terms,
how sending one extra small message which does not propagate or
replicate inside an already established BGP session "does not scale"?

-- 
Richard A Steenbergen <[email-masked]>       http://www.e-gerbil.net/ras
GPG Key ID: 0xF8B12CBC (7535 7F59 8204 ED1F CC1C 53AF 4C41 5ECA F8B1 2CBC)

---

From: Robert Raszuk <[email-masked]>
Date: Wed, 25 Mar 2009 08:58:15 -0700

Hi Richard,

 > how sending one extra small message

Talking about size ... is 140 bytes good enough ? Why not 150 bytes or 
1500 or max BGP PDU ? Perhaps instead it would be good idea to just send 
a URL pointer in such message which can easily be text retrievable. More 
over if modification to original warning is made it would not need to 
result in next message.

The same for prefix limit threshold ... if I am customer with 10000 
branch locations and you are signaling on some peering points that 
prefix limit is reached how good is this for my low cost branch router 
to get such data as opposed to my head quarter's 24x7 NOC ? Are we back 
to enforcing this to go via the same network from branch to a syslog at 
the NOC ?

Is this one message per day, per hour or per second ? The draft says 
that implementation must limit the rate, but does not say to what value. 
It is just Speed Limit sign on the road without the value :)

In the steady state (well there is never a steady state in BGP but let's 
leave it) perhaps you could get this through just fine. But the same 
tool should be supposedly used also for event driven notifications. 
Those will be likely correlated with increase of routing information. If 
both are over the same BGP session I see no easy way of making sure 
there is no interaction between them.

Another point is why limit it just to your peer ? If I am an AS planning 
for AS number migration I would like to tell all of my AS peers about 
perhaps with AS-PATHLIMIT perimeter of 2. Just in case their NOC would 
be aware about my plans to mess with AS numbers which if not carefully 
planned may result in major traffic pattern shift. I don't think this 
tool will allow you this.

Last .. why just limit to ASCII string no matter in what character 
encoding ?

What happens if tomorrow NASDAQ comes to IDR and says ... I hear you 
guys have a nice global protocol ... We will pay you operators and you 
vendors a lot if you just allow one new message type to send stock info 
globally with it .... we already heard you are using it for sending p2p 
text messages between yourself with it.

Cheers,
R.

---

From: "Neil J. McRae" <[email-masked]>
Date: Wed, 25 Mar 2009 15:58:58 -0000 (GMT)

> replicate inside an already established BGP session "does not scale"?

Richard,
Fair challenge, but in my own view, one of the reasons why BGP works as
well as it does is because we haven't infected it with a lot of other
stuff not directly related to routing information. Even the example given
highlights that its another work around to other bad working practices but
we've done the Max Prefix debate to death already.

However, with such an way of inserting messages and having experienced
many BGP failures owing to different vendor interpretations, I believe
this has the potential to introduce more operational risk (limited yes but
there nonetheless). I also believe that this is the not right direction
for a routing protocol to take. Thin end of the wedge also springs to
mind, but this isn't a massive issue for me, just one that I feel I need
to air.

Regards,
Neil.

---

From: "Neil J. McRae" <[email-masked]>
Date: Wed, 25 Mar 2009 16:14:13 -0000 (GMT)

On Wed, March 25, 2009 15:58, Robert Raszuk wrote:

> Talking about size ... is 140 bytes good enough ?

"$2/Mb PHONE NOW ON 1-800-TRANSIT" !

The more I think about this the more I think its a bad idea.
I like the idea of standard message  codes though.

---

From: Richard A Steenbergen <[email-masked]>
Date: Wed, 25 Mar 2009 11:31:09 -0500

> I like the idea of standard message  codes though.

No one has proposed propagating the messages across the Internet, this 
is purely a point-to-point message between two directly connected 
neighbors. If you don't like the messages your neighbor sends you, vote 
with a shutdown. I have yet to see spam end up in a SONET path trace, 
which is the closest equivalent to the draft being discussed.