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

[<[e-mail]>]

Hi Robert,

>From: Robert Raszuk [mailto:[e-mail]]>Sent: Monday, December 19, 2011 3:25 PM
>
>Hi Bruno,
>
>> You are assuming a local error with your neighbor. Chances are that
>> errors have been trigger by a specific state and that all backup
>> paths also got that state. Hence you can't assume that there would be
>> a backup path if you choose to shut down the session.
>
>Reasonable networks have many neighbors. The like hood that due to
>mandatory BGP attribute error we will experience an outage from all
>neighbors is rather quite unlikely IMHO.

Please refer to my previous example: I'm the first AS (on the path) to implement draft-ietf-idr-as0. AS_X originates route Z/z with an AS 0 in the AS_PATH.
The number of neighbors is of little relevance as from all neighbors advertising Z/z, I will receive an invalid AS_PATH.
For a tier-1 like AS, the more neighbor ASes advertising a path to Z/z, the more sessions will go done.
For a lower tier AS, typically less BGP session will go done but each session would carry more NLRI (e.g. the whole Internet as advertised by its upstream transit).

And that's a single example. I'm sure reality will be much more creative.

BTW, I agree with you that this is quite unlikely. However when this happen, how do we want to react?

>
>However I am not opposing recommendations of
>draft-ietf-idr-error-handling. What I am not quite comfortable with is
>to assume that this should be the new default behaviour.
>
>You say that "we don't like it" what is happening today. One may argue
>that "some do not like it some do". 

Sure. But again, that's a discussion for draft-ietf-grow-ops-reqs-for-bgp-error-handling-02

>Those who do not like it do they
>really use already available tools like multisession deployed in
>production to limit one SAFI impacting other SAFIs ? 

Bringing down a whole AFI/SAFI is already too much. E.g. 1/1 (Internet) or 128/1 (L3 VPN) especially on an iBGP session with your BGP Route Reflector.

>Could they just not
>use validating layer before the BGP update hits RP ?

Sorry, I don't see what you are refering to.

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

I agree. I already brought that point both during the meeting and on the mailing list: http://www.ietf.org/mail-archive/web/idr/current/msg04710.html

Ideally _current_ operations teams/tools should have a chance to learn about the issue (degraded behavior) even if they have not been "upgraded". Something using the same news channel that when BGP sessions are reported down. (e.g. a new "bgp4V2PeerState" value "established-UPDATES in error (7)" which would probably also trigger "bgp4V2BackwardTransitionNotification NOTIFICATION-TYPE", but I'm not really into the MIB stuff so I would prefer that some else do the job).

Could authors of draft-ietf-idr-error-handling consider addressing the above point? Many thanks.


>--
>
>Also note that if this is hacker on the CE trying to mess with his EBGP
>session towards PE to perhaps destroy other VPNs on such PE keeping the
>session up is only helping him to better attack the PE. Is this the
>aspect of "improvement" you have all considered ?

IMHO, having the ability to trigger a BGP session down further in the network is a bigger attack vector.

>--
>
>Last is I think the point that Ilya brought. While we are at the topic
>let's address the flapping session problem (assume that non of
>conditions in the new draft apply) and that session is getting resetted.
>It seems valid to me to accumulate penalty on such consecutive resets
>and keep the session shut when such penalty reaches some value. While
>some may say that this is implementation thing some may also see
>reasonable to define what the behaviour should be.

Would DampPeerOscillations (§8.1.1. of RFC 4271) do the job or are you thinking about something else?

Best regards,
Bruno
>Best regards,
>R.

_________________________________________________________________________________________________________________________

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.