Subject: Re: [Idr] I-D Action: draft-ietf-idr-error-handling-01.txt

From: Paul Jakma <[email-masked]>
Date: Wed, 4 Jan 2012 11:56:45 +0000 (GMT)

On Mon, 19 Dec 2011, Robert Raszuk wrote:

> You say that "we don't like it" what is happening today. One may argue 
> that "some do not like it some do".

> The fact that draft-ietf-idr-error-handling seems to be targetting to 
> update 4271 means that when I boot router with new software the 
> behaviour will change and now all of the operations teams worldwide need 
> to develop new syslog parsing scripts to catch the new error categories. 
> Today they see it easily as session is going down.

2nd this. "Treat-as-withdraw" should be an option, but possibly shouldn't 
be the default for core message parsing. To use "treat-as-withdraw" safely 
will require operational-best-practice of carefully checking logs to 
detect when a "treat-as-withdraw" will occur.

If implementations switch to "treat-as-withdraw" as default for core 
messages then software problems change from quite obvious (to both sides) 
session resets; into problems that potentially affect just a tiny % of 
routes, for paths whose sources have no relationship with either speaker 
involved in the route-drop (be it the problem speaker or the dropping 
one). It turns problems that are obvious to the ASes involved in the BGP 
errors, into ones that may only be obvious to remote ASes who may find it 
very hard to get their routing problems fixed.

Some care needs to be taken before vendors roll out general 
"treat-as-withdraw" as the default behaviour to potentially unsuspecting 
and/or unprepared operators.

regards,
-- 
Paul Jakma  [email-masked]  twitter: @pjakma  PGP: 64A2FF6A
Fortune:
I know on which side my bread is buttered.
 		-- John Heywood

---

From: Jeffrey Haas <[email-masked]>
Date: Wed, 4 Jan 2012 20:29:20 -0500

On Tue, Dec 27, 2011 at 03:52:27PM +0100, [email-masked] wrote:
> Alcatel/Cisco were not supporting DampPeerOscillations when the survey was done. Maybe it changed, maybe not (RFC is old ...).
> No feedback about Juniper.

Like many things in the updated FSM in RFC 4271, you could say JunOS
supports DampPeerOscillations if you squint at it a little.  

-- Jeff

---

From: <[email-masked]>
Date: Thu, 5 Jan 2012 09:41:28 +0100

Hi Jeff,

I had a feedback from our Juniper SE that said that support is only "partial" but without details ... So don't know what is behind ...

Regards,

Stephane

-----Message d'origine-----
De : Jeffrey Haas [mailto:[email-masked]] 
Envoyé : jeudi 5 janvier 2012 02:29
À : LITKOWSKI Stephane DTF/DERX
Cc : Ilya Varlashkin; [email-masked]; DECRAENE Bruno RD-CORE; [email-masked]
Objet : Re: [Idr] I-D Action: draft-ietf-idr-error-handling-01.txt

> No feedback about Juniper.

Like many things in the updated FSM in RFC 4271, you could say JunOS supports DampPeerOscillations if you squint at it a little.  

-- Jeff

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
France Telecom - Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorization.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, France Telecom - Orange shall not be liable if this message was modified, changed or falsified.
Thank you.

---

From: Jeffrey Haas <[email-masked]>
Date: Thu, 5 Jan 2012 09:58:50 -0500

One last followup here since it's apropos to the implementation report, but
I suggest further followups on Juniper specific details off-list.

> I had a feedback from our Juniper SE that said that support is only "partial" but without details ... So don't know what is behind ...

Upon a connection failing, the implementation will have a backoff for three
exponentially increasing intervals.  This has been in the implementation for
quite some time.  This happens to preserve the spirit of the
DampPeerOscillations feature.

What is likely not 100% compliant is all of the FSM transition logic
surrounding the backoff.

Speaking as an individual contributor, I believe IDR was pushed into having
an excessively complicated FSM where many of the details are not relevant to
on-the-wire behavior.  I doubt you'll find a 100% compliant with all of the
optional knobs implementation that's more than a few years old.  

(And, if someone was doing a fresh implementation, we should have seen
errata filed against the FSM - I was aware of at least two minor issues with
it, but this was prior to the errata system going online and those notes are
gone.)

-- Jeff