Subject: [Idr] I-D Action: draft-ietf-idr-error-handling-07.txt

From: [email-masked]
Date: Wed, 07 May 2014 11:08:46 -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
        Authors         : Enke Chen
                          Juniper Networks
                          Pradosh Mohapatra
                          Keyur Patel
	Filename        : draft-ietf-idr-error-handling-07.txt
	Pages           : 13
	Date            : 2014-05-07

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 a number of existing attributes.

   This document updates error handling for RFCs 1997, 4271, 4360, 4456,
   4760, and 5701.

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

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-idr-error-handling-07

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: "John G. Scudder" <[email-masked]>
Date: Wed, 7 May 2014 14:17:23 -0400

Folks,

Compared to -06, this version lists a couple more NLRI (in)correctness criteria in S. 3.2 as discussed at the last IETF meeting, adds S. 3.3 on the handling of typed NLRI (such as for MVPN and EVPN), makes an editorial clarification regarding when a session must be reset, and removes Appendix A. The deletion of Appendix A was because it was there for purposes of explanation in the early versions of the draft, but at this point everyone seems to get the point and there doesn't seem to be any need to clutter up the eventual RFC with it. 

With this revision the authors think the document is ready for working group last call.

Thanks,

--John

On May 7, 2014, at 2:08 PM, [email-masked] wrote:

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

---

From: Vitkovský Adam <[email-masked]>
Date: Mon, 12 May 2014 20:22:08 +0000

Hello Authors,

I believe that in sections:

5.11.  ORIGINATOR_ID
And
5.12.  CLUSTER_LIST

Concerning error handling 
If these attributes are received from an external neighbor, it SHALL actually be handled using the approach of "treat-as-withdraw.

The current "attribute discard" approach can lead to severe Inter-AS loops e.g. in RFC4364 Opt. 10.C implementations. 

adam

> -----Original Message-----
> From: Idr [mailto:[email-masked]] On Behalf Of internet-
> [email-masked]
> Sent: Wednesday, May 07, 2014 8:09 PM
> To: [email-masked]
> Cc: [email-masked]
> Subject: [Idr] I-D Action: draft-ietf-idr-error-handling-07.txt
> 
>

---

From: "John G. Scudder" <[email-masked]>
Date: Mon, 12 May 2014 19:32:53 -0700

Can you elaborate how these Inter-AS loops would form, maybe with an example? To my understanding, Option C uses EBGP and thus the regular AS_PATH would suppress loops.

Thanks,

--John

---

From: Vitkovský Adam <[email-masked]>
Date: Tue, 13 May 2014 11:03:03 +0000

> From: John G. Scudder [mailto:[email-masked]]
> Sent: Tuesday, May 13, 2014 4:33 AM
> 
> Can you elaborate how these Inter-AS loops would form, maybe with an
> example? To my understanding, Option C uses EBGP and thus the regular
> AS_PATH would suppress loops.
> 
> Thanks,
> 
> --John

Hello John,
Sorry for the bad choice of words I thought that the updates might start looping in remote ASes. 
However now I see that the ORIGINATOR_ID and CLUSTER_LIST attributes, even if deleted on ingress from an eBGP session, are going to be recreated by the RRs(clusters) in the remote AS when the update is propagated further so no loops can occur in the remote ASes. 
However I'm not sure how the ORIGINATOR_ID should be recreated (local router id or the eBGP peer ip address)

So actually the worst that can happen is asymmetric routing or sub-optimal path selection if one relies on originator ID or the cluster list length for best path selection. 

Example:
AS-D receives an update for X via AS-B and AS-C. 
AS-B is a big AS so the update made it through several clusters when propagated across. 
AS-C is a small AS so the update crossed only one cluster on its way to AS-D. 
Now let's assume the CLUSTER_LIST attribute is deleted on ingress to AS-D on a malformed update from AS-B. 
For PEs in AS-D the path via AS-C now appears to be less preferred because it has a longer CLUSTER_LIST. 

adam

---

From: "John G. Scudder" <[email-masked]>
Date: Tue, 13 May 2014 09:32:25 -0700

[removed internet-drafts and i-d-announce from cc]

Adam,

Thanks for your reply.

On May 13, 2014, at 4:03 AM, Vitkovský Adam <[email-masked]> wrote:
...
> However now I see that the ORIGINATOR_ID and CLUSTER_LIST attributes, even if deleted on ingress from an eBGP session, are going to be recreated by the RRs(clusters) in the remote AS when the updat…

Great -- this means draft-ietf-idr-error-handling-07 is OK.

> For PEs in AS-D the path via AS-C now appears to be less preferred because it has a longer CLUSTER_LIST. 

I don't think so -- in either case, any CLUSTER_LIST received over an EBGP session MUST be removed, so both AS-C and AS-B's routes will be considered in AS-D to have no CLUSTER_LIST.

I actually wrote a draft that relates to this some time ago but didn't progress it, draft-scudder-idr-ebgp-rr-02, http://www.ietf.org/proceedings/85/slides/slides-85-idr-4.pdf. I'd be willing to resurrect it if the WG thinks it would be useful. I don't think it needs a lot more work (possibly no more work).

Regards,

--John

---

From: "Chris Hall" <[email-masked]>
Date: Tue, 13 May 2014 18:08:03 +0100

I note that Section 4, Operational Considerations, discusses the issue
of the potential dangers of "attribute-discard", and states that:

  "if the attribute in question has or may have an effect
   on route selection or installation, the presumption is
   that discarding it is unsafe"

Earlier, in Section 2, where repeat instances of attributes are
considered:

  "all occurrences other than the first one SHALL be discarded"

Faced with two versions of, say, AS_PATH, choosing one over the other
may affect route selection.

Is there an inconsistency here ?  It doesn't seem to me that a blanket
"attribute-discard" is a Good Thing.

[On the balance of probabilities, I'd say that a second AS_PATH is
most likely to be a symptom of some deeper issue with the message.
Similarly with other "well-known" attributes.  But that's not entirely
the point here.]

Chris