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

From: [email-masked]
Date: Fri, 13 Jun 2014 11:32:22 -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
                          John G. Scudder
                          Pradosh Mohapatra
                          Keyur Patel
	Filename        : draft-ietf-idr-error-handling-13.txt
	Pages           : 18
	Date            : 2014-06-13

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, 5543, 5701, 6368 and 6790.

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

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

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: Fri, 13 Jun 2014 14:42:10 -0400

This version incorporates Eric, Deniz and Adam's recent comments.

I'd be particularly interested in thoughts as to whether it would be OK to soften the error-handling approach for the TE attribute to "attribute discard". Frankly, I just threw "treat-as-withdraw" in there since it's the default choice.

--John

---

From: Robert Raszuk <[email-masked]>
Date: Fri, 13 Jun 2014 21:15:45 +0200

John, Eric,

I am not too happy with the updated section 7.11. Not that the update
was wrong, but it seems incomplete.

You now precisely provide definition of "valid host address" It says ...

   o  If the Next Hop field contains an IPv4 address (possibly as a sub-
   ...
   o  If the Next Hop field contains an IPv6 address (possibly as a sub-
   ...
   o  If the Next Hop field contains an IPv4-mapped IPv6 address
   ...
   o  If the Next Hop field is some other form of address, it should be
      considered invalid.

However let's observe that we do have RFC5575 where there is no need
to neither carry NEXT HOP ATTRIBUTE nor have it as part of
MP_REACH_NLRI (length 0)

Quote from RFC 5575 section 4:

   Whenever the corresponding application does not require Next-Hop
   information, this shall be encoded as a 0-octet length Next Hop in
   the MP_REACH_NLRI attribute and ignored on receipt.

Therefor if an implementation would take current text of the draft
very serious it may consider all flow-spec MP_REACH_NLRI attributes as
invalid.

I would therefor propose to modify the current section 7.11 accordingly:

   consider what it means for the Next Hop field of the MP_REACH
   attribute to be a "valid host address" unless it is of 0-octet length:

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Regards,
R.

---

From: "Chris Hall" <[email-masked]>
Date: Sat, 14 Jun 2014 15:45:22 +0100

Robert Raszuk wrote (on Fri 13-Jun-2014 at 20:16 +0100):
....
> You now precisely provide definition of "valid host address" It says
....
> very serious it may consider all flow-spec MP_REACH_NLRI attributes
> as invalid.
....

I have a feeling that defining "valid host address" is more trouble
than it is worth.

The draft has, as far as I can see, by stages ended up as:

  "on any error do treat-as-withdraw, unless the error
   affects Parsing of NLRI (do session-reset), or unless
   the error is trivial (do attribute-discard)"

The upshot is that errors can be classified as "venial"
(treat-as-withdraw), "mortal" (session-reset) and "trivial"
(attribute-discard) -- where, unless otherwise specified, an error is
implicitly "venial".

(IMHO anyone contemplating attribute-discard is in a state of sin, and
the whole thing would be made simpler by placing that vanity on the
nearest bonfire.  But that's another story.)  

It really doesn't matter why a given next-hop is invalid or unusable
or nonsense or otherwise no more use than a chocolate teapot: all
next-hop errors are venial errors.  So the draft doesn't, AFAICS, need
to get sucked into defining "valid host address".

(RFC4271 goes some way to distinguish the handling of syntactically
and semantically incorrect NEXT_HOP attribute -- the father of
treat-as-withdraw, perhaps.  But that distinction is rendered
irrelevant by this draft.)

UNLESS, that is, there are next-hop errors which should be deemed
mortal.  The NEXT_HOP attribute can be completely broken without
affecting the Parsing of NLRI.  But for MP_REACH_NLRI:

  (1) noting that (a) the draft treats invalid prefix
      lengths as mortal errors, because they cast doubt 
      on the Parsing of NLRI...

      ...and that (b) in an MP_REACH_NLRI, the start of
      the NLRI is given by the next-hop-length....

      ...is an invalid next-hop-length a mortal error ?  

  (2) some Next-Hop values could be deemed "nonsense",
      meaning that their presence should be considered
      a symptom of a much more serious underlying 
      error, so...

      ...are there any Next-Hop values that should be
      deemed mortal errors ?

Chris

---

From: Jeffrey Haas <[email-masked]>
Date: Mon, 16 Jun 2014 14:47:25 -0400

> I have a feeling that defining "valid host address" is more trouble

I'm also a bit concerned here.

RFC 4271 and earlier went through a lot of wrangling to end up with the idea
syntactically correct vs. semantically correct.

If it's syntactically incorrect, treat as withdraw is quite reasonable.

Semantically incorrect gets heavily tied up into how we're breaking original
rules today in a given spec.  E.g. RFC 5575 zero length.  What happens when
we decide to get clever and end up using a class D/E address in IPv4?  Etc.

For any future Clever Feature, deployment of it will need to be pervasive
enough for the networks using it to make use of it.  This means an island of
semantic correctness for something that didn't used to be that way.

If you're outside of the island, it's semantically incorrect, treat as
withdraw.

It may thus be worthwhile simplifying the section:
"If the next hop field contains a semantically incorrect address within the
context of deployed features and address family, treat as withdraw behavior
should be used."

I'd keep the section on martians.

-- Jeff

---

From: Vitkovský Adam <[email-masked]>
Date: Tue, 17 Jun 2014 14:11:04 +0000

> context of deployed features and address family, treat as withdraw behavior

However I would leave the martians out. 
We should not dictate what addresses may be used as NH in various BGP features - that would be for another document. 

We should focus on the syntactic correctness of the NH 
And I think Chris has some valid questions there: 

> UNLESS, that is, there are next-hop errors which should be deemed mortal.
> The NEXT_HOP attribute can be completely broken without affecting the
> Parsing of NLRI.  But for MP_REACH_NLRI:
> 

adam