Subject: [Idr] Adoption of draft-chen-ebgp-error-handling-00.txt

From: "Susan Hares" <[email-masked]>
Date: Thu, 11 Nov 2010 02:02:20 -0500

WARNING: contains banned part

Subject: Adoption of draft-chen-ebgp-error-handling-00.txt
From: "Susan Hares" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>, "'John Scudder'" <[email-masked]>
Date: Thu, 11 Nov 2010 02:02:20 -0500

The authors of

draft-chen-ebgp-error-handling-00
<http://tools.ietf.org/id/draft-chen-ebgp-error-handling-00.txt>

Revised Error Handling for BGP Updates from External Neighbors
<http://www.ietf.org/proceedings/79/slides/idr-10.pdf> 

have requested this document to be a working group document, and to be
combined with draft-ietf-idr-optional-transitive-03
<http://datatracker.ietf.org/doc/draft-ietf-idr-optional-transitive/> .

Do you support adoption of this draft's content as IDR work? 

This starts a two week call for feedback on adoption. It will end on
11/25/10.

Sue

---

From: Jeff Tantsura <[email-masked]>
Date: Thu, 11 Nov 2010 06:20:01 -0500

Yes/support

Regards,
Jeff

________________________________
From: Susan Hares [mailto:[email-masked]]
Sent: Wednesday, November 10, 2010 23:02
To: [email-masked]
Cc: [email-masked]; 'John Scudder'
Subject: Adoption of draft-chen-ebgp-error-handling-00.txt

The authors of

draft-chen-ebgp-error-handling-00<http://tools.ietf.org/id/draft-chen-ebgp-error-handling-00.txt>

Revised Error Handling for BGP Updates from External Neighbors<http://www.ietf.org/proceedings/79/slides/idr-10.pdf>

have requested this document to be a working group document, and to be combined with draft-ietf-idr-optional-transitive-03<http://datatracker.ietf.org/doc/draft-ietf-idr-optional-transitive/>.
Do you support adoption of this draft's content as IDR work?
This starts a two week call for feedback on adoption. It will end on 11/25/10.
Sue

---

From: "Henderickx, Wim (Wim)" <[email-masked]>
Date: Thu, 11 Nov 2010 12:20:51 +0100

Yes/support

---

From: Tony Li <[email-masked]>
Date: Thu, 11 Nov 2010 19:26:11 +0800

Support.

T

On Nov 11, 2010, at 3:02 PM, Susan Hares wrote:

> <winmail.dat>

---

From: <[email-masked]>
Date: Thu, 11 Nov 2010 12:44:07 +0100

1) Support

2) However, as mentioned at the mic during the meeting, this proposition has operational impact as a BGP error, which would currently shutdown the ebgp session and at such be reported to the management station e.g. trough SNMP trap and / or SNMP get polling, will not anymore be reported so could be silently ignored. Even thought this ebgp session has an issue which (may) need to be handled.
Therefore, I'd also like to see what is proposed to address this. (Ideally, the management session should see this (e.g. SNMP TRAP, new ebgp session status....). And ideally, both should progress at the same pace (rather than having the MIB postponed)

Thanks,
Regards,
Bruno

________________________________________
From: Susan Hares [mailto:[email-masked]] 
Sent: Thursday, November 11, 2010 8:02 AM
To: [email-masked]
Cc: [email-masked]; 'John Scudder'
Subject: Adoption of draft-chen-ebgp-error-handling-00.txt 

The authors of

have requested this document to be a working group document, and to be combined with draft-ietf-idr-optional-transitive-03.
Do you support adoption of this draft's content as IDR work? 
This starts a two week call for feedback on adoption. It will end on 11/25/10.
Sue

---

From: Pierre Francois <[email-masked]>
Date: Thu, 11 Nov 2010 12:50:01 +0100

+1

On 11/11/10 12:26, Tony Li wrote:
> _______________________________________________
> Idr mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/idr
>

---

From: Claudio Jeker <[email-masked]>
Date: Thu, 11 Nov 2010 14:10:52 +0100

On Thu, Nov 11, 2010 at 02:02:20AM -0500, Susan Hares wrote:
> From: Susan Hares <[email-masked]>
> To: [email-masked]
> Cc: [email-masked], 'John Scudder' <[email-masked]>
> X-Mailer: Microsoft Office Outlook 12.0
> 
> The authors of
> 
>  
> 

I disagree with the current version of this draft.
The idea of a general treat-as-withdraw of all UPDATE errors is to
unspecific. The draft should actually define a specific behaviour for each
and every error case of section 6.3 of rfc4271.
Just as a quick example this draft will turn the enforce neighbor-AS check
useless. This is a side-effect that can not be accepted.

I support the idea of having less fatal notifications and instead
treating soft errors as withdraws. But this draft is a way to big hammer
and will cause network reachability issues because errors are no longer
detected early, instead they will remain undetected until the caused
routing blackhole is big enough to be noticable. But exactly this is what
this draft tries to avoid so in the end there is no benefit from this at
all.

In this current form we will not implement this draft in our BGP
implementation and our project can not support the adoption of this draft.

-- 
:wq Claudio
OpenBGPD developer

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 11 Nov 2010 14:32:54 +0100

Hi Claudio,

 > treating soft errors as withdraws. But this draft is a way to big
 > hammer and will cause network reachability issues because errors are
 > no longer detected early, instead they will remain undetected until
 > the caused routing blackhole is big enough to be noticable.

I think you have misunderstood the intention of this particular proposal.

This draft will detect the errors as is today or even better. And they 
will be noticed and information about them will be propagated to the 
peers sending those errors.

The only difference this draft makes that the errors will not be 
propagated downstream or will not result in session reset. This is very 
different from claiming that the errors will not be detected early.

So if you assume that 90% of updates on the session are malformed I 
think I would agree that it is better to drop the session. But if 1% or 
5% of updates are bad do you want to affect connectivity for all other 
destinations by resetting the entire session triggered by single 
malformed update ?

Perhaps in BGP as we know it today a concept of a long lived tcp session 
is a bad idea to start with .. I personally do believe so and I would 
rather see proposals to address the real issue .. for example making 
each BGP table entry propagation as a database transaction exchange .. 
but I am often at the very minority of those who think outside of the 
box :)).

Cheers,
R.

>> From: Susan Hares<[email-masked]>
>> To: [email-masked]
>> Cc: [email-masked], 'John Scudder'<[email-masked]>

---

From: Enke Chen <[email-masked]>
Date: Thu, 11 Nov 2010 21:34:08 +0800

Hi, Caludio:

When "treat-as-withdraw" is used, a critical / severe error would be 
logged.  True, it may not get as much or immediate attention as a 
session reset.  However, it is no longer acceptable in the field to 
punish the innocent routes (instead of just the bad ones) by resetting a 
session.  I believe that providers do pay attention and react to 
"critical / several" errors logged on a router.

-- Enke

---

From: "iLya" <[email-masked]>
Date: Thu, 11 Nov 2010 14:58:02 +0100

support

/iLya

--------------------------------------------------
From: "Susan Hares" <[email-masked]>
Sent: Thursday, November 11, 2010 8:02 AM
To: <[email-masked]>
Cc: <[email-masked]>; "'John Scudder'" <[email-masked]>
Subject: Adoption of draft-chen-ebgp-error-handling-00.txt

---

From: Tony Li <[email-masked]>
Date: Thu, 11 Nov 2010 21:59:49 +0800

I concur that a trap and inform, as well as appropriate syslog messages, are requirements and should be coupled to this draft.

Tony

---

From: Jie Dong <[email-masked]>
Date: Thu, 11 Nov 2010 22:47:58 +0800

During today's IDR session we do not have enough time to discuss the 
usecases of this one-time selective route refresh. Here I would provide some 
possible usecases for discussion. Normally the usecases can be divided into 
two categories: trouble shooting and route recovery.

1. Retrieve routes which was treated as withdraw before (one case of route 
recovery)

Both draft-ietf-idr-optional-transitive and draft-chen-ebgp-error-handling 
propose to treat routes with some invalid attributes as withdraw instead of 
resetting the BGP session. Normally this can be two cases: fault on sender 
side and fault on receiver side. In both cases the receiver side could 
maintain the information of withdrawn routes.

If the fault is on sender side, after the problem is solved (without tearing 
down the session), the routes can be recovered by:
a) either the sender side re-advertises its whole-rib-out to peer, OR
b) the receiver side request the re-advertising of routes which was 
treat-as-withdrawn before.

If the fault is on receiver side, after the problem is solved (without 
tearing down the session), the routes can be recovered by:
the receiver side request the re-advertising of routes which was 
treat-as-withdrawn before.

2. Verify peer's ORF processing (one case of trouble shooting)

After sending to peer a set of ORFs (which may be combination of complicated 
rules), operator may need to verify whether the peer could process the ORFs 
correctly. This test can be done by requesting some specific routes being 
re-advertised.

3. Verify whether some specific route can be retrieved or not (trouble 
shooting & fast recovery)

This may happen when some customer are complaining they are having problems 
with accessing some websites, or the operator detects some critical routes 
have disappeared.

Also there can be other usecases of these lightweight maintenance tool. More 
thoughts on the usecases would be appreciated.

Best Regards,
Jie

---

From: Jakob Heitz <[email-masked]>
Date: Thu, 11 Nov 2010 11:36:52 -0500

Your example is simply a message with multiple errors.
The malformed attribute is just one of a multitude of errors.
Typically, we check a message for errors in a specified order
and the first error that is detected determines the response.

Adoption of the draft does not mean its acceptance as an RFC,
it means that the group agrees to work on it.

Once that happens, we can discuss the behaviour in the case
of multiple errors.

--
Jakob Heitz.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Claudio Jeker
Sent: Thursday, November 11, 2010 9:11 PM
To: Susan Hares
Cc: [email-masked]; [email-masked]
Subject: Re: [Idr] Adoption of draft-chen-ebgp-error-handling-00.txt

I disagree with the current version of this draft.
The idea of a general treat-as-withdraw of all UPDATE errors is to unspecific. The draft should actually define a specific behaviour for each and every error case of section 6.3 of rfc4271.
Just as a quick example this draft will turn the enforce neighbor-AS check useless. This is a side-effect that can not be accepted.

I support the idea of having less fatal notifications and instead treating soft errors as withdraws. But this draft is a way to big hammer and will cause network reachability issues because errors are no longer detected early, instead they will remain undetected until the caused routing blackhole is big enough to be noticable. But exactly this is what this draft tries to avoid so in the end there is no benefit from this at all.

In this current form we will not implement this draft in our BGP implementation and our project can not support the adoption of this draft.

---

From: Paul Jakma <[email-masked]>
Date: Thu, 11 Nov 2010 17:21:40 +0000 (GMT)

On Thu, 11 Nov 2010, Claudio Jeker wrote:

> hammer and will cause network reachability issues because errors 
> are no longer detected early, instead they will remain undetected 
> until the caused routing blackhole is big enough to be noticable. 
> But exactly this is what this draft tries to avoid so in the end 
> there is no benefit from this at all.

+1 for adoption of this draft as a WG document.

However, I join Claudio in his concerns that it applies too widely. 
In particular, it might be better to not change the session-reset 
behaviour for well-known attributes. By definition today any 
syntactic error in such attributes can only have originated with the 
neighbouring speaker and almost certainly indicates a serious problem 
with that speaker (though, not per se a frequently occuring one).

Further, in the same vein, I'd be inclined to make the new error 
apply only to attributes with the Optional and Partial bits set, as 
these are the only attributes which could "tunnel" over 
incomprehending BGP speakers. Errors in any other attributes must by 
definition be due to the sending speaker (either it caused it, or 
else it failed in its responsibility of finding the error).

It'd be useful at least to discuss this I think...

(if there's some obvious reason I've missed - then useful to my 
understanding obviously ;) ).

regards,
-- 
Paul Jakma	[email-masked]	Key ID: 64A2FF6A
Fortune:
"One size fits all":
 	Doesn't fit anyone.

---

From: Paul Jakma <[email-masked]>
Date: Thu, 11 Nov 2010 18:01:00 +0000 (GMT)

> (if there's some obvious reason I've missed - then useful to my understanding 
> obviously ;) ).

The obvious bit is that I'd overlooked the referenced 
draft-ietf-idr-optional-transitive which answers my comment.

Given its existence, I change my vote above to -1.

regards,
-- 
Paul Jakma	[email-masked]	Key ID: 64A2FF6A
Fortune:
If God is One, what is bad?
 		-- Charles Manson

---

From: Chandrashekhar Appanna <[email-masked]>
Date: Thu, 11 Nov 2010 10:36:54 -0800

+1.

I feel this is a good extension that helps in the specific
cases where a session reset can be avoided without using very
broad brush strokes to just not reset the session overall.

Regards,
Chandra.

---

From: "Shyam Sethuram (shsethur)" <[email-masked]>
Date: Thu, 11 Nov 2010 10:42:20 -0800

+1

thanks--shyam

>Sent: Wednesday, November 10, 2010 11:02 PM
>To: [email-masked]
<http://tools.ietf.org/id/draft-chen-ebgp-error-handling-
>00.txt>
combined with
>draft-ietf-idr-optional-transitive-03
<http://datatracker.ietf.org/doc/draft-ietf-idr-optional-
>transitive/> .
11/25/10.

---

From: Amir Cohen <[email-masked]>
Date: Fri, 12 Nov 2010 08:02:00 +0200

[I'm kinda new to the list so please bear with me if the below has been addressed before or irrelevant]
eBGP neighbor may receive multiple malformed updates within a specific time window, theoretically it may result in treat-as-withdraw the complete prefix list in the adj-rib-in within a very short time window.
Could be an implementation specific, but wouldn't it make sense to have a configurable bound to this one,  since I assume it may make sense in some extreme cases to shut the session down, or set relevant notification (differ from the single prefix malformed update notification)
If make sense, it may be nice to include some text in the draft with recommendation how to bound the number of malformed updates and the involved actions.
Thanks,
Amir Cohen

From: Susan Hares [mailto:[email-masked]]
Sent: Thursday, November 11, 2010 3:02 PM
To: [email-masked]
Cc: [email-masked]; 'John Scudder'
Subject: Adoption of draft-chen-ebgp-error-handling-00.txt

The authors of

---

From: Tony Li <[email-masked]>
Date: Fri, 12 Nov 2010 14:08:51 +0800

Hi Amir,

> [I’m kinda new to the list so please bear with me if the below has been addressed before or irrelevant]

Welcome.

> eBGP neighbor may receive multiple malformed updates within a specific time window, theoretically it may result in treat-as-withdraw the complete prefix list in the adj-rib-in within a very short t…

Agreed.

> Could be an implementation specific, but wouldn’t it make sense to have a configurable bound to this one,  since I assume it may make sense in some extreme cases to shut the session down, or set relevant notification (differ from the single prefix malformed update notification) 

While a knob to describe this isn't unthinkable, I'm hopeful that it wouldn't ever prove necessary or beneficial.  If we do this properly, the first error should set off all types of alarms within the receiving router's NOC.  Hopefully the operations staff would then immediately investigate, and unconfigure the offending neighbor or reset the session manually.

In any case, as this is only a local behavior, this is completely within the implementation's discretion.

Tony

---

From: Mach Chen <[email-masked]>
Date: Fri, 12 Nov 2010 14:16:41 +0800

Support!

Best regards,
Mach

---

From: Amir Cohen <[email-masked]>
Date: Fri, 12 Nov 2010 08:58:34 +0200

Make sense. I'm also hopeful that such knob wouldn't ever prove necessary. 
I tend to believe that such knob is applicable only for extreme cases where large number of malformed updates received in a very short time. 

Anyhow, the general concept in this draft makes perfect sense to me. 

Amir

---

From: john heasley <[email-masked]>
Date: Fri, 12 Nov 2010 18:56:26 +0000

Fri, Nov 12, 2010 at 02:08:51PM +0800, Tony Li:
> > Could be an implementation specific, but wouldn?t it make sense to have a configurable bound to this one,  since I assume it may make sense in some extreme cases to shut the session down, or set relevant notification (differ from the single prefix malformed update notification) 

i think that is a poor assumption, tli.

---

From: Tony Li <[email-masked]>
Date: Sat, 13 Nov 2010 05:12:51 +0800

> i think that is a poor assumption, tli.

Hi Heas,

So you'd want the knob?  Or, you disagree with the draft and prefer the session reset?  Or you're just giving me grief?  ;-)

Tony

---

From: Rob Shakir <[email-masked]>
Date: Mon, 15 Nov 2010 00:14:41 +0000

On 11 Nov 2010, at 07:02, Susan Hares wrote:

> [...]

Support for adoption.

Thanks,
Rob

---

From: john heasley <[email-masked]>
Date: Tue, 16 Nov 2010 00:44:04 +0000

> So you'd want the knob?  Or, you disagree with the draft and prefer the session reset?  Or you're just giving me grief?  ;-)

hi!  i don't think its safe to assume that any network's noc or their
tools are sophisticated enough to catch the notifications.  but, session
resets are less likely to go unnoticed until someone realizes that some
prefix is inaccessible.

a maximum-prefix-like knob would be useful, though i'm not sure how to
apply it.  some number of prefixes withdrawn?  number in an interval?

of course, i also like to give you grief.

---

From: Tony Li <[email-masked]>
Date: Tue, 16 Nov 2010 09:45:45 +0900

> of course, i also like to give you grief.

Grief duly noted.  ;-)

Ok, so having a knob to enable this is not terribly problematic.  Sufficient?

Tony

---

From: john heasley <[email-masked]>
Date: Tue, 16 Nov 2010 01:00:02 +0000

> Ok, so having a knob to enable this is not terribly problematic.  Sufficient?

probably; off by default.

---

From: John Leslie <[email-masked]>
Date: Mon, 15 Nov 2010 20:29:22 -0500

Tony Li <[email-masked]> wrote:
> 
> Ok, so having a knob to enable this is not terribly problematic.

   I'll feel a lot better about this with a knob...

   People _will_ turn it on -- I know that; but I simply don't believe
the logs will be examined regularly and sufficiently to  debug the
problems. With an option to turn it off again, I believe it can retain
mind-share.

   The knob, IMHO, should be per-peer -- to be turned on when you
start seeing the NOTIFICATIONs, but always subject to being turned
off again.

   Without that, I would expect "random" NLRIs to "disappear" and be
totally impractical to debug.

   (YMMV, of course...)

--
John Leslie <[email-masked]>

---

From: Jake Khuon <[email-masked]>
Date: Tue, 16 Nov 2010 02:53:44 -0800

On Tue, 2010-11-16 at 09:45 +0900, Tony Li wrote:

> Sufficient?

I support a knob as well.  Although error handling is local processing,
it effects the behaviour of the session.  As such, I would also like to
see that relaxed error handling be signalled in capability negotiations.

If R1 and R2 both can handle relaxed handling then signal that in
capability and enable it by default.

If only R1 can do relaxed handling then disable by default but provide
R1 with a knob to force it if so desired.

-- 
/*=================[ Jake Khuon <[email-masked]> ]=================+
 | Packet Plumber, Network Engineers     /| / [~ [~ |) | | -------- |
 | for Effective Bandwidth Utilisation  / |/  [_ [_ |) |_| NETWORKS |   
 +==================================================================*/

---

From: john heasley <[email-masked]>
Date: Tue, 16 Nov 2010 15:39:31 +0000

> R1 with a knob to force it if so desired.

no, please.  no enabling by default/no surprises.  its a local option,
like policy, and its not necessary for both peers to support it.

though i appreciate knowing my neighbor's capabilities, its not enough to
know if they support it if there is a knob to disable it.  if a problem
is discovered (ie: prefixes are being dropped), the ASes will end-up
talking on the phone.

---

From: Robert Raszuk <[email-masked]>
Date: Tue, 16 Nov 2010 16:55:58 +0100

Hi John,

> no, please.  no enabling by default/no surprises.

100% agree.

> its a local option, like policy, and its not
 > necessary for both peers to support it.

I do not think this is comparable to policy. With policy you can see via 
numerous looking glasses if your nets are being advertised or not by 
your peer.

With this out of the sudden your nets are dropped. And you have no idea 
about such fact.

> is discovered (ie: prefixes are being dropped), the ASes will end-up

What would trigger such verbal conversation ?

I have proposed to send a diagnostic message to inform BGP peer about 
such fact. Do you think this is a decent way to notify the peer ?

Otherwise you can be receiving routes just fine while your routes are 
being dropped. Quite a departure from today's case of loosing the 
session and neither you can reach the world nor world can reach you.

Many thx,
R.

---

From: john heasley <[email-masked]>
Date: Tue, 16 Nov 2010 16:41:06 +0000

> numerous looking glasses if your nets are being advertised or not by  

though less revealing because you do not know why, you can also see that
they aren't advertised.  i mentioned policy because policy is a local
configuration that is not communicated to your peer over the protocol.
maybe a passive peer (in junos configuration grammar) would have been a
better analogy.

> What would trigger such verbal conversation ?

syslogs, snmp traps, flapping session, routing failure (ie: unexpected or
poor path or unreachable - likely noticed by customer complaint).

> such fact. Do you think this is a decent way to notify the peer ?

if it is/can be rate limited, sure.

> session and neither you can reach the world nor world can reach you.

i don't particularly like this draft nor its parent draft, but i can see
the utility.

---

From: Robert Raszuk <[email-masked]>
Date: Tue, 16 Nov 2010 17:49:22 +0100

> they aren't advertised.

The only point is when are you going to notice :)

> poor path or unreachable - likely noticed by customer complaint).

BGP sessions are not going to flap. Not sure why you have listed this. 
Also your syslog/trap logs will be empty.

> if it is/can be rate limited, sure.

Ah I have not included rate limiting into the original draft as I 
thought this would be to the implementation, but as this is still pretty 
much open idea I welcome any input.

If you are suggesting that adding rate limiting as MUST have knob to 
implementations supporting this new BGP message would be required I have 
no problem adding it to next -01 version. Let's talk offline to make 
sure we are in sync reg your suggestion.

Many thx,
R.

---

From: john heasley <[email-masked]>
Date: Tue, 16 Nov 2010 21:49:16 +0000

> Also your syslog/trap logs will be empty.

because if there is a knob as i've susgested, these 'ignore malformed
attributes' features would be disabled (or allow for threshold) and
presumably act according to rfc4271, ie: notification and session reset.

---

From: Florian Weimer <[email-masked]>
Date: Wed, 17 Nov 2010 10:19:12 +0000

* Paul Jakma:

> Further, in the same vein, I'd be inclined to make the new error apply
> only to attributes with the Optional and Partial bits set, as these
> are the only attributes which could "tunnel" over incomprehending BGP
> speakers.

BGP speakers sometimes disagree in the strictness of checks they
apply.

(By the way, treat-as-withdrawal with the Partial flag seems still a
significant change.  The vendors I tested ignored the Partial flag
during error checking.  As I side effect, this forces a certain set of
mandatory features upon core routers and IXP route servers which are
not at all apparent from the RFCs.)

> Errors in any other attributes must by definition be due to the
> sending speaker (either it caused it, or else it failed in its
> responsibility of finding the error).

I'm not sure if the path attribute specifications are sufficiently
precise to avoid interpretation conflicts.

-- 
Florian Weimer                <[email-masked]>
BFK edv-consulting GmbH       http://www.bfk.de/
Kriegsstraße 100              tel: +49-721-96201-1
D-76133 Karlsruhe             fax: +49-721-96201-99

---

From: Florian Weimer <[email-masked]>
Date: Wed, 17 Nov 2010 12:37:53 +0000

> resets are less likely to go unnoticed until someone realizes that some

The UPDATE report suggests to me that flapping as a notification
mechanism is insufficient.  It is also rather inconvenient for
operators who receive such notification and cannot do anything about
it because they (or their peers) cannot deploy code on their routers
to address the root cause.