I took a read on this ( I will read more thoroughly) but one section jumped out at me. "Operational Considerations". Although the "treat-as-withdraw" error-handling behavior defined in Section 2 makes every effort to preserve BGP's correctness, we note that if an UPDATE received on an IBGP session is subjected to this treatment, inconsistent routing within the affected Autonomous System may result. The consequences of inconsistent routing can include long-lived forwarding loops and black holes. While lamentable, this issue is expected to be rare in practice, and more importantly is seen as less problematic than the session-reset behavior it replaces. " When a malformed attribute is indeed detected over an IBGP session, we RECOMMEND that routes with the malformed attribute be identified and traced back to the ingress router in the network where the routes were sourced or received externally, and then a filter be applied on the ingress router to prevent the routes from being sourced or received. This will help maintain routing consistency in the network." I don't think the terminology "lamentable" to describe Long lived forwarding loops and black holes is appropriate as it would probably be more than regrettable. Could you expand on the conditions and how BGP would eventually recover. That would be a good addition. I am a bit confused, how does this type of error handling which restarts GR ( As of my last read ) and which BGP persistence lives through change the paradigm of these solutions? There is a notion of treat as withdraw for some attrs, but don't tear down session?? How many malformed updates before the session is torn down? Ever? According to the next paragraph ( See below ) there is an expectation that the offending ingress router should be identified, and then a filter should be applied for those paths in a given updated with the malformed attrs :) What is the recommendation for doing this? Will there be a draft whereby the detecting router somehow figures out the offending ingress router, builds routing policy and then sends it there to dynamically create the filter. This seems non-trivial, I guess Flowspec like technology may be used not sure.. Is the ingress router assumed to be in the same AS domain as the detecting router? Administrative domain may span multiple AS domains.. Jim Uttaro -----Original Message----- From: idr-bounces@ietf.org [mailto:idr-bounces@ietf.org] On Behalf Of internet-drafts@ietf.org Sent: Sunday, June 17, 2012 4:45 PM To: i-d-announce@ietf.org Cc: idr@ietf.org Subject: [Idr] I-D Action: draft-ietf-idr-error-handling-02.txt A New Internet-Draft is available from the on-line Internet-Drafts directories. This draft is a work item of the Inter-Domain Routing Working Group of the IETF. Title : Revised Error Handling for BGP UPDATE Messages Author(s) : John G. Scudder Enke Chen Pradosh Mohapatra Keyur Patel Filename : draft-ietf-idr-error-handling-02.txt Pages : 10 Date : 2012-06-17 Abstract: According to the base BGP specification, a BGP speaker that receives an UPDATE message containing a malformed attribute is required to reset the session over which the offending attribute was received. This behavior is undesirable as a session reset would impact not only routes with the offending attribute, but also other valid routes exchanged over the session. This document partially revises the error handling for UPDATE messages, and provides guidelines for the authors of documents defining new attributes. Finally, it revises the error handling procedures for several existing attributes. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-idr-error-handling There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-idr-error-handling-02 A diff from previous version is available at: http://tools.ietf.org/rfcdiff?url2=draft-ietf-idr-error-handling-02 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ _______________________________________________ Idr mailing list Idr@ietf.org https://www.ietf.org/mailman/listinfo/idr _______________________________________________ I-D-Announce mailing list I-D-Announce@ietf.org https://www.ietf.org/mailman/listinfo/i-d-announce Internet-Draft directories: http://www.ietf.org/shadow.html or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
