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

From: [email-masked]
Date: Thu, 29 May 2014 16:49:24 -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-10.txt
	Pages           : 15
	Date            : 2014-05-29

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

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

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, 30 May 2014 09:03:44 -0400

As reading the rfcdiff will tell you :-) this version:

- Calls out AFI/SAFI disable distinctly.
- Corrects the ambiguity about attribute flags that conflict.
- Removes some redundancy in 3(j).
- Reworks the “Parsing of NLRI” section quite a bit, including:
  - Extract the attribute length stuff to its own section, it didn’t make sense where it was.
  - Puts back the “MP_ must go first” rule.
  - Adds a subsection on “Missing NLRI”.

Thanks for all the discussion.

Regards,

—John

On May 29, 2014, at 7:49 PM, <[email-masked]> <[email-masked]> wrote:

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

---

From: Deniz Bahadir <[email-masked]>
Date: Fri, 30 May 2014 17:06:44 +0200

Hi guys,

I have some more (minor) comments (or one might call it nit-picking) 
concerning the current draft:

1.
It occurs to me that the title of section 7 ("Error Handling Procedures 
for Existing Attributes") implies to address *all* existing attributes. 
The first sentence, however, seems to mitigate that by saying the 
following subsections "elaborate on the conditions for error-checking 
*various* path attributes".
Nevertheless, for sake of completeness, I would recommend to mention all 
(non-deprecated) path attributes (as can be found here: 
http://www.iana.org/assignments/bgp-parameters/bgp-parameters.xhtml) in 
the following subsections.

2.
To be honest, I do not know all these path-attributes myself. However, I 
know AS4_PATH and AS4_AGGREGATOR, and would at least recommend to add 
them to the subsections of section 7. Especially, as the information 
given in the subsections for AS_PATH and AS_AGGREGATOR pretty much 
resembles the information for AS4_PATH and AS4_AGGREGATOR in section 6 
of RFC 6793 (except maybe for the action taken).

3.
I would also recommend to repeat (and explain) the definition of 
"syntactical incorrectness" for NEXT_HOP in subsection 7.3. (This seems 
to be the only subsection which just refers to another RFC and does not 
repeat the important part.)

Some more nit-picking:

4.
Likewise, I was always wondering, what exactly is meant by saying, 
"Syntactic correctness means that the NEXT_HOP attribute represents a 
valid IP host address." [RFC 4271, page 32]?
  * Does it mean, the NEXT_HOP value must be a machine that should be up 
and running as well as reachable (and one must explicitly check for 
that)? -- Probably not.
  * Does it mean, the NEXT_HOP must be a unicast address (neither 
0.0.0.0 nor greater than 223.255.255.255)? -- Maybe.
  * Does it mean, the NEXT_HOP value must be a unicast address but not 
127.0.0.1 or some other special IP? -- Possibly.
  * ...

5.
Similar, I briefly looked through RFC 4760 but could not find a section 
telling me, if and when the value of the Next Hop field of MP_REACH_NLRI 
is considered (syntactically) incorrect. (At least for AFI/SAFI of 
IPv4/Unicast I would have expected it.)
Is suppose, the current draft should address this question.
(Or it shouls at least mention that MP_REACH_NLRI's Next Hop value need 
not be checked for (syntactical) correctness... although this does not 
sound right.)

6.
I appreciate the ambiguity about attribute flags being addressed. Just 
one question: Shouldn't a well-known attribute also be considered to 
have conflicting flags if the partial bit is set?

Thanks,
Deniz