draft-ietf-idr-error-handling
<bruno.decraene <at> orange.com>
2012-01-12 14:56:30 GMT
Hi all,
The draft currently does not discuss nor address how to recover from error i.e. for the BGP receiver to get
back all the NLRI / attributes after it has withdrawn/discarded some. IMHO it should as the current
mechanism it is replacing (session reset) address both error handling and error recovery.
In order to initiate discussion on this, may I suggest the following text:
When the approach "treat-as-withdraw" or "attribute discard" has been used on a BGP session, the BGP
receiver has not the full set of attributes or NLRI that the BGP speaker sent. There MUST be a way to latter
recover from this inconsistency.
In some cases, this inconsistency will naturally be resolved. As the error is fixed on the speaker or on an
upstream speaker (possibly the originator of the route), the BGP attribute in error will be updated and a
new UPDATE message will be propagated on downstream BGP routers. If the error has indeed been fixed, the
new BGP UPDATE message will be accepted and the dropped attribute or withdrawn NLRI will be learnt again.
To cover remaining cases, an automatic recovery mechanism SHOULD be implemented. The use of the
ROUTE-REFRESH message is suggested but others non traffic disruptive mechanisms may be used. This
recovery mechanism SHOULD be initiated after a configurable delay. If the mechanism failed to recover
all NLRI or attributes in error, subsequent tentative SHOULD be initiated after a timer. Timer value
SHOULD be carefully defined to allow for both a reasonably quick recovery and a reasonable impact on the
BGP control plane load. The use of a (exponential) backof algorithm may be considered. The maximum value
should be high enough (e.g. days) in order for the mechanism to keep trying the recovery possibly for ever
while having a low impact on the BGP control plane. Timer MAY be on a per BGP session
basis or MAY be global to the BGP speaker.
If an implementation chooses not the implement an automatic recovery mechanism, when or prior to
configure this revised error handling, network operator MUST be made aware that the recovery will
require a manual action (typically a session (soft) reset).
Thanks,
Regards,
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 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.
_______________________________________________
Idr mailing list
Idr <at> ietf.org
https://www.ietf.org/mailman/listinfo/idr
),
and so it has been removed…
A helpful diff is here: 
RSS Feed