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

From: [email-masked]
Date: Wed, 11 Jun 2014 16:07:07 -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-12.txt
	Pages           : 18
	Date            : 2014-06-11

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

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

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, 11 Jun 2014 19:14:47 -0400

Folks,

Changes for -12:

- Expanded NEXT_HOP and MP_REACH_NLRI to talk about what it means to be a “valid IP host address”
- Disclaimed a lot of attributes that are either OK or deprecated
- Added subsections for TE attribute, Entropy Label, ATTR_SET 
- Rearranged Section 7 to be in type code order (sorry for the extra diff)

Still to do:

- Traffic Engineering path attribute is stubbed out. I’ve pinged the authors of RFC 5543 to ask if they’d be willing to contribute text.

Given that there’s a “TBD” section, -12 is obviously not ready for publication, however I hope it addresses all comments other than the TBD.

Thanks,

—John

---

From: Vitkovský Adam <[email-masked]>
Date: Thu, 12 Jun 2014 08:50:17 +0000

Hello
Just a nit picking.

> 7.3. NEXT_HOP
> An implementation MAY provide a means to modify
> the list of invalid host addresses by configuration

I believe SHOULD would be more appropriate here (and in 7.11. MP_REACH_NLRI as well). 
If an implementer decides not to implement this knob and assumes all addresses in the "IANA IPv4 Special-Purpose Address Registry" are false then the implementation will be unusable (actually only a small portion of the list is flat out unusable for next hop). 
Besides every decent implementation should allow on operator to choose what is considered as valid next hop. 

adam

---

From: Deniz Bahadir <[email-masked]>
Date: Thu, 12 Jun 2014 18:30:39 +0200

> Just a nit picking.

And another bit of nit picking.

The last sentence of the abstract should reference all RFCs which will 
be updated by this document and should therefore be changed to:

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

Deniz

---

From: Eric Rosen <[email-masked]>
Date: Thu, 12 Jun 2014 15:51:31 -0400

> Expanded NEXT_HOP and MP_REACH_NLRI to talk about what it means to be a
> "valid IP host address"

With regard to:

      If the Next Hop field is an IPv6 address, it SHOULD be considered
      invalid if it appears in the "IANA IPv6 Special-Purpose Address
      Registry" [IANA-IPV6] and either the "destination" or the
      "forwardable" boolean in that registry is given as "false".

This seems to rule out the use of IPv4-mapped IPv6 addresses in the Next Hop
field.  If so, it is incompatible with RFC 4798 ("6PE"), as RFC 4798
explicitly mandates the use of IPv4-mapped IPv6 addresses under certain
circumstances.

For certain AFI/SAFIs, the Next Hop is in the form of a VPN-IPv4 or VPN-IPv6
address, where the first eight octets are supposed to be zero and the
remaining octets are supposed to be a "syntactically valid" IPv4 or IPv6
address (and in the case of "6vPE" (RFC 4659), the IPv6 part could be an
IPv4-mapped IPv6 address).  Probably there should be some mention of this.

Section 5.4 begins

   "Certain address families, for example MVPN [RFC7117] and EVPN
   [I-D.ietf-l2vpn-evpn] have NLRI that are typed."

I believe the first reference is supposed to be either "MCAST-VPN [RFC6514]"
or "MCAST-VPLS [RFC7117]", or perhaps both.

> - Traffic Engineering path attribute is stubbed out. I've pinged the
> - authors of RFC 5543 to ask if they'd be willing to contribute text. 

> Given that there's a 'TBD' section, -12 is obviously not ready for
> publication,

If information about the TE path attribute is blocking the progress of the
error handling draft, please consider advancing the draft without that
information.

---

From: "John G. Scudder" <[email-masked]>
Date: Thu, 12 Jun 2014 16:12:47 -0400

Eric,

Thanks for your comments.

> explicitly mandates the use of IPv4-mapped IPv6 addresses under certain

I see your point. Do you think it would be sufficient to carve out an exception for this specific case?

> IPv4-mapped IPv6 address).  Probably there should be some mention of this.

Probably. I don't suppose you have text to suggest? It was painful enough to find a way to specify what a "valid IP host address" is, without having to now go spelunking for every case where we've already bent this rule (or "rule"). 

Another alternative, if it gets too hairy to spec this, would be to back the changes out. I don't know how the rest of the WG would feel about that.

> or "MCAST-VPLS [RFC7117]", or perhaps both.

OK, thanks. I'll address this in the next rev.

> error handling draft, please consider advancing the draft without that

While I'd be overjoyed to RFC this thing and move on, off-hand I can't think of a justification for singling the TE path attribute out as not needing to be updated. I'd be pleased to be provided with one, though.

--John

---

From: Eric Rosen <[email-masked]>
Date: Fri, 13 Jun 2014 12:03:21 -0400

I wonder if the first two bullet items of Section 7.11 should be slightly
revised (and perhaps expanded to three items), as follows:

   o If the Next Hop field contains an IPv4 address (possibly as a
     sub-field), the field SHOULD be considered invalid if the IPv4 address
     appears in the "IANA IPv4 Special-Purpose Address Registry" [IANA-IPV4]
     and either the "destination" or the "forwardable" boolean in that
     registry is given as "false".

   o If the Next Hop field contains an IPv6 address (possibly as a
     sub-field), the field SHOULD be considered invalid if the IPv6 address
     appears in the "IANA IPv6 Special-Purpose Address Registry"
     [IANA-IPV6], the address is not an IPv4-mapped IPv6 address, and either
     the "destination" or the "forwardable" boolean in that registry is
     given as "false".

   o If the Next Hop field contains an IPv4-mapped IPv6 address (possibly as
     a sub-field), the field SHOULD be considered invalid unless the use of
     such addresses has been explicitly allowed for the particular AFI/SAFI
     that occurs in this MP_REACH_NLRI attribute.  (E.g., see RFC 4659 and
     RFC 4798.)

This would cover the 6PE and 6vPE cases, and would also cover the cases
where the next hop field contains an RD followed by an IP address.     

John> Another alternative, if it gets too hairy to spec this, would be to
John> back the changes out. I don't know how the rest of the WG would feel
John> about that.

That's also a possibility.  The IANA special-purpose address registries
really seem to be focused on the use of addresses in the data plane rather
than the control plane; it's not obvious that the content of those
registries should affect the control plane.  Are we sure that there are no
deployments (other than 6PE and 6vPE deployments) that use IP
special-purpose addresses as (part of) the Next Hop field?

Eric> If information about the TE path attribute is blocking the progress of
Eric> the error handling draft, please consider advancing the draft without
Eric> that information.

John> While I'd be overjoyed to RFC this thing and move on, off-hand I can't
John> think of a justification for singling the TE path attribute out as not
John> needing to be updated. I'd be pleased to be provided with one,
John> though.

Well, let me quote from some previous messages regarding this draft:

      "Of course we could continue error-handling as a seemingly eternal
      draft, but I think there is some value in saying "close enough" and
      graduating it to RFC, especially for implementors that are less
      steeped in the WG and don't necessarily have the background to
      distinguish between Internet Drafts that are really *drafts* and those
      that are de-facto standards."

      "The draft does try to strike a balance between prudence and avoidance
      of ever-mounting complexity of error-detection heuristics to attempt
      to detect ever less-likely problems."

These sentiments seem very wise, and I think the draft has been around long
enough for use to say that anything not incorporated yet is "out of scope"
and will have to be covered in future documents.

---

From: "John G. Scudder" <[email-masked]>
Date: Fri, 13 Jun 2014 13:03:55 -0400

Eric,

> where the next hop field contains an RD followed by an IP address.     

Thanks. This looks good. Barring further discussion, I'll plan to incorporate your text into -13.

> special-purpose addresses as (part of) the Next Hop field?

No, I'm not sure, although the reasoning in citing the registry was that if the address is non-forwardable, how do you expect to use it as a next hop? You're right that this seems like an perversion of the registry's original purpose. However the options I could see came down to:

- Cite the registries as I've done,
- Find a better citation -- I looked and didn't find anything,
- Define "invalid IP host address" from the ground up -- seemed like a terrible idea to do in this document, or
- Ignore the issue as in earlier versions of the draft.

Of these, citing the registries seemed less terrible than the alternatives. I'm certainly open to proposals on how to improve. I guess we could explicitly acknowledge that it's underspecified and invite interested parties to write a spec to properly define "invalid IP host address", without trying to actually fix it in this document. The question comes down to whether the current text helps more than it hurts. I'm inclined to think that it does, but then I would, wouldn't I?

> and will have to be covered in future documents.

Well-played.

I'm OK with that approach. I'd like to invite anyone who feels we MUST have coverage of the TE path attribute before publishing error-handing, to propose text. Otherwise, I'll replace the section with something like:

7.13.  Traffic Engineering path attribute

   We note that [RFC5543] does not detail what constitutes
   "malformation" for the Traffic Engineering path attribute.  A future
   update to that specification may provide more guidance.  In the
   interim, an implementation that determines (for whatever reason) that
   an UPDATE message contains a malformed Traffic Engineering path
   attribute MUST handle it using the approach of "treat-as-withdraw".

One final point to discuss is whether the proper approach is "treat-as-withdraw" or if "attribute discard" would be OK in this case.

Thanks,

--John