Subject: I-D Action: draft-ietf-idr-error-handling-02.txt

From: [email-masked]
Date: Sun, 17 Jun 2012 13:44:51 -0700

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/

---

From: "UTTARO, JAMES" <[email-masked]>
Date: Mon, 18 Jun 2012 00:29:16 +0000

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: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Sunday, June 17, 2012 4:45 PM
To: [email-masked]
Cc: [email-masked]
Subject: [Idr] I-D Action: draft-ietf-idr-error-handling-02.txt

Abstract:

_______________________________________________
Idr mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/idr