>From: Jakob Heitz [mailto:jakob.he...@ericsson.com] Sent: Wednesday, May 09,
>2012 12:42 PM
>
>The loop occurs because of an error in the update message:
>The AS path was missing.
Well your original text was not that specific. I understood that the AS PATH
attribute was present but its length was 0. So no error in the UPDATE received.
>The receiving router "handled"
>the error and propagated it.
>
>I just gave you an example of how slippery the error
>handling slope can be.
>
>Please don't lose perspective.
>
>Error handling should be simple.
>
>I don't want to trust anything from a buggy router.
I've heard that argument a few times in the discussion
draft-ietf-idr-error-handling vs RFC 4271 (current error handling). IMHO it is
not a valid one:
A) Note that what you want is not even the current RFC 4271 behavior which do
accept and do try to correct some error from a buggy router. Including for well
know attributes:
e.g. RFC 4271 ยง5.1.5 LOCAL_PREF
"A BGP speaker MUST NOT include this attribute in UPDATE messages it
sends to external peers, except in the case of BGP Confederations
[RFC3065]. If it is contained in an UPDATE message that is received
from an external peer, then this attribute MUST be ignored by the
receiving speaker, except in the case of BGP Confederations
[RFC3065]."
And idem in RFC 1771:
" A BGP speaker shall not include this attribute in UPDATE messages
that it sends to BGP speakers located in a neighboring autonomous
system. If it is contained in an UPDATE message that is received from
a BGP speaker which is not located in the same autonomous system as
the receiving speaker, then this attribute shall be ignored by the
receiving speaker."
B) See also RFC 1122:
1.2.2 Robustness Principle
At every layer of the protocols, there is a general rule whose
application can lead to enormous benefits in robustness and
interoperability [IP:1]:
"Be liberal in what you accept, and
conservative in what you send"
>However, it has been shown that dropping everything from
>a router because of a small bug is too severe.
>
>Therefore, I'm prepared to accept the additional rule:
>If an error can be isolated to a set of prefixes,
>withdraw only the prefixes
That would be fine for me. So I don't think we are in real significant
disagreement.
> and send an operational message.
Do you mean that the support of operational message on your BGP peers would be
MUST/prerequisite for draft-ietf-idr-error-handling? If so I would disagree. I
want to limit the impact of errors regardless of the capabilities of my peers
(regardless if my peer is in a different AS or not)
>Nothing more.
That would be ok for me, at least as a first step until we get operational
experience on the new error handling.
But to come back to the original point, IMHO Jeff proposal seems valid and you
have not succeeded in proving otherwise.
Thanks,
Regards,
Bruno
>On Wednesday, May 09, 2012 3:12 AM, bruno.decra...@orange.com
><mailto:bruno.decra...@orange.com> wrote:
>
>> Jakob,
>>
>> Thanks for your example.
>>
>> For sure, if a router (partially) erase the AS PATH, we can have
>> loops. So far, I don't see how this is related to BGP error handling,
>> not to mention to Jeff proposition.
>>
>> In more details, is B configured to enforce first AS?
>> - if so, it should detect the error and react. As per
>> draft-ietf-idr-error-handling I guess it should treat as withdraw. I
>> don't see the issue. Or are you considering a case of two different
>> bugs in two consecutive routers (A & B)?
>> - if not, well, the loop is the current BGP behavior. Not specific
>> to BGP error handling as no router see an error.
>>
>>
>> Or eventually, we have a different reading of Jeff proposal. I
>> understood that the proposition is to use as last resort the routes
>> received _before_ the BGP error (i.e. valid routes received through a
>> valid BGP UPDATE but which would be implicitly withdrawn with the BGP
>> notification). Not route from the invalid BGP UPDATE.
>>
>> Regards,
>> Bruno
>>
>>> From: Jakob Heitz [mailto:jakob.he...@ericsson.com] Sent: Wednesday,
>>> May 09, 2012 10:10 AM
>>>
>>> A has a route learnt from C.
>>> A configures a long AS path prepend, but because of a bug activated
>>> by
>>> a too long AS path, it sends no AS path. B receives it,
>>> but does not withdraw the route. It announces the route to C.
>>> C had a better route before, but due to policy did not
>>> announce it to B. C starts sending traffic to B.
>>> B send to A. A sends to C. loop.
>>>
>>> Here is the way:
>>> If you can isolate an error to a set of routes withdraw them.
>>> If not, drop the session and withdraw all routes from it.
>>> RFD takes care of flapping sessions.
>>>
>>> On Wednesday, May 09, 2012 12:37 AM, bruno.decra...@orange.com
>>> <mailto:bruno.decra...@orange.com> wrote:
>>>
>>>> From: grow Jakob Heitz Sent: Wednesday, May 09, 2012 3:08 AM
>>>>> On Monday, May 07, 2012 10:58 AM, Jeffrey Haas <> wrote:
>>>>>
>>>>>> On Fri, Apr 13, 2012 at 07:27:36PM +0100, Rob Shakir wrote:
>>>>>>> I'd like to ask the WG their collective opinion on a couple of
>>>>>>> matters in this draft, which come from some discussions at IETF83
>>>>>>> (in particular with John Scudder and Adam Simpson) about how the
>>>>>>> requirements are currently written regarding repeated errors.
>>>>>>
>>>>>> In reviewing this thread, there's another possible tool we could
>>>>>> leverage. The consensus seems to be trending toward "if the
>>>>>> session is bad enough, take it down. Potentially hold it down if
>>>>>> it continues to be bad."
>>>>>>
>>>>>> An alternative before you get to such a stage is to perform BGP
>>>>>> graceful shutdown procedures on the session's routes. This
>>>>>> permits the routes to be routes of last resort until the issue is
>>>>>> dealt with.
>>>>>
>>>>> That raises the possibility that the routes are actually used.
>>>>> That may cause loops.
>>>>
>>>> Would you mind sharing an example of such loops following an eBGP
>>>> session failure? That would help me. (Hopefully some others).
>>>>
>>>> Thanks,
>>>> Bruno
>>>>
>>>>
>>>>
>>>
>_______________________________________________________________________________
>>> __________________________________________
>>>>
>>>> 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
>>>> authorisation. 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 is not liable for
>>>> messages that have been modified, changed or falsified. Thank you.
>>>
>>>
>>>
>>> --
>>> Jakob Heitz.
_________________________________________________________________________________________________________________________
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 authorisation.
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 is not liable for messages
that have been modified, changed or falsified.
Thank you.
_______________________________________________
GROW mailing list
GROW@ietf.org
https://www.ietf.org/mailman/listinfo/grow
