Subject: Re: [Idr] [Technical Errata Reported] RFC4271 (4493)

From: "Alvaro Retana (aretana)" <[email-masked]>
Date: Wed, 17 Feb 2016 15:08:48 +0000

Idr WG:

Please take a look at the Errata below.  I need your opinion on it.

I'm leaning towards rejecting it because I interpret "Unspecific" not as
the name of the subcode, but as just an indication that the error is not
specific.  The IANA registry [1] lists the value 0 as "Reserved", which I
think is ok according to the definition in RFC5226:

      Reserved:  Not to be assigned.  Reserved values are held for
            special uses, such as to extend the namespace when it become
            exhausted.  Reserved values are not available for general
            assignment.

In this case the "special use" is when the error is not specific.

Any thoughts?  Other opinions?

Thanks!

Alvaro. 

[1] 
http://www.iana.org/assignments/bgp-parameters/bgp-parameters.xhtml#bgp-par
ameters-4

On 10/6/15, 4:10 AM, "RFC Errata System" <[email-masked]> wrote:

>The following errata report has been submitted for RFC4271,
>"A Border Gateway Protocol 4 (BGP-4)".
>
>--------------------------------------
>You may review the report below and at:
>http://www.rfc-editor.org/errata_search.php?rfc=4271&eid=4493
>
>--------------------------------------
>Type: Technical
>Reported by: Bruno Decraene <[email-masked]>
>
>Section: 4.5
>
>Original Text
>-------------
>§\\"4.5 NOTIFICATION Message Format\\" says:
>
>      Message Header Error subcodes:
>
>               1 - Connection Not Synchronized.
>               2 - Bad Message Length.
>               3 - Bad Message Type.
>
>      OPEN Message Error subcodes:
>
>               1 - Unsupported Version Number.
>               2 - Bad Peer AS.
>               3 - Bad BGP Identifier.
>               4 - Unsupported Optional Parameter.
>               5 - [Deprecated - see Appendix A].
>               6 - Unacceptable Hold Time.
>
>      UPDATE Message Error subcodes:
>
>               1 - Malformed Attribute List.
>               2 - Unrecognized Well-known Attribute.
>               3 - Missing Well-known Attribute.
>               4 - Attribute Flags Error.
>               5 - Attribute Length Error.
>               6 - Invalid ORIGIN Attribute.
>               7 - [Deprecated - see Appendix A].
>               8 - Invalid NEXT_HOP Attribute.
>               9 - Optional Attribute Error.
>              10 - Invalid Network Field.
>              11 - Malformed AS_PATH.
>
>Corrected Text
>--------------
>      Message Header Error subcodes:
>
>               0 - Unspecific.
>               1 - Connection Not Synchronized.
>               2 - Bad Message Length.
>               3 - Bad Message Type.
>
>      OPEN Message Error subcodes:
>
>               0 - Unspecific.
>               1 - Unsupported Version Number.
>               2 - Bad Peer AS.
>               3 - Bad BGP Identifier.
>               4 - Unsupported Optional Parameter.
>               5 - [Deprecated - see Appendix A].
>               6 - Unacceptable Hold Time.
>
>      UPDATE Message Error subcodes:
>
>               0 - Unspecific.
>               1 - Malformed Attribute List.
>               2 - Unrecognized Well-known Attribute.
>               3 - Missing Well-known Attribute.
>               4 - Attribute Flags Error.
>               5 - Attribute Length Error.
>               6 - Invalid ORIGIN Attribute.
>               7 - [Deprecated - see Appendix A].
>               8 - Invalid NEXT_HOP Attribute.
>               9 - Optional Attribute Error.
>              10 - Invalid Network Field.
>              11 - Malformed AS_PATH.
>
>Notes
>-----
>RFC 4271 defines a use and a name for Error subcode 0:
>- §4.5 (any error code):
>         If no appropriate Error Subcode is defined, then a zero
>         (Unspecific) value is used for the Error Subcode field.
>
>- §6.2 (OPEN error code):
>   If one of the Optional Parameters in the OPEN message is recognized,
>   but is malformed, then the Error Subcode MUST be set to 0
>   (Unspecific).
>
>If verified, the \\"IANA Considerations\\" section and the IANA registry
>would also need to be updated accordingly (currently says \\"0
>Reserved\\")
>http://www.iana.org/assignments/bgp-parameters/bgp-parameters.xhtml#bgp-pa
>rameters-4
>
>Instructions:
>-------------
>This erratum is currently posted as "Reported". If necessary, please
>use "Reply All" to discuss whether it should be verified or
>rejected. When a decision is reached, the verifying party (IESG)
>can log in to change the status and edit the report, if necessary.
>
>--------------------------------------
>RFC4271 (draft-ietf-idr-bgp4-26)
>--------------------------------------
>Title               : A Border Gateway Protocol 4 (BGP-4)
>Publication Date    : January 2006
>Author(s)           : Y. Rekhter, Ed., T. Li, Ed., S. Hares, Ed.
>Category            : DRAFT STANDARD
>Source              : Inter-Domain Routing
>Area                : Routing
>Stream              : IETF
>Verifying Party     : IESG
>

---

From: Jeffrey Haas <[email-masked]>
Date: Wed, 17 Feb 2016 10:19:25 -0500

Updating the registry to Unspecific would reflect common implementation practice.  For years, 0 has basically meant "this doesn't fit into anything else".  

The existing value of reserved in the registry was likely an oversight as part of registry maintenance over the long life of BGP.  Even RFC 1771 section 6 covers the 0 as an appropriate value, yet it's not listed in the enumerations of the different code types.

FWIW, Junos uses the word "unspecified" in several of the debugging outputs rather than "unspecific".  I would lean toward unspecified. :-)

Note that the BGP MIBs do not provide any related enumerations so there is no support one way or the other in existing standardized items beyond the normative text in the RFCs that value 0 is to be used.

-- Jeff

> On Feb 17, 2016, at 10:08 AM, Alvaro Retana (aretana) <[email-masked]> wrote:
> 
> Idr WG:
> 
> _______________________________________________
> Idr mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/idr

---

From: <[email-masked]>
Date: Wed, 17 Feb 2016 15:39:44 +0000

Thanks for the follow up.
My 2 cents inline

> From: Alvaro Retana (aretana) [mailto:[email-masked]] > Sent: Wednesday, February 17, 2016 4:09 PM
> 
> Idr WG:
> 
> specific.  The IANA registry [1] lists the value 0 as "Reserved",

And where does this comes from?
In theory, this should come from RFC 4271.

> which I

My point was that this value is not unallocated/unused. i.e. it can't (must not) be used for a new purpose as RFC 4271 already specifies when this value is sent. You can't change its meaning. My reading is that this value is assigned and means Unspecific/Other error. One could not defined another use for this value, without first deprecating this usage.

That being said, I don't feel that this is a real problem (e.g. given the space of available code point) so I won't argue anymore ;-)

Thanks
-- Bruno
 
> >http://www.iana.org/assignments/bgp-parameters/bgp-

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

---

From: t.petch <[email-masked]>
Date: Wed, 17 Feb 2016 17:15:14 +0000

----- Original Message -----
From: "Alvaro Retana (aretana)" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Sent: Wednesday, February 17, 2016 3:08 PM

Idr WG:

I'm leaning towards rejecting it because I interpret "Unspecific" not as
the name of the subcode, but as just an indication that the error is not
specific.  The IANA registry [1] lists the value 0 as "Reserved", which
I
think is ok according to the definition in RFC5226:

<tp>

Reject.

s.6.2 specifies a specific(!) instance of using 0(Unspecific) (so I
think that IANA is in error here).  Arguably, you could raise an erratum
to add 0(Unspecific) for the OPEN Message Error subcodes list but I
think that it would be a technical change to add it for the other
messages.  As currently defined, it could be seen as an implementation
error were subcode 0 be used for the other messages (an interpretation
which I have no problem with).

If there are errors that cannot be reported using the subcodes in
RC4271, then that is a separate issue that could be worth investigating.

Tom Petch

Thanks!

Alvaro.

[1]
http://www.iana.org/assignments/bgp-parameters/bgp-parameters.xhtml#bgp-
par
ameters-4

---

From: t.petch <[email-masked]>
Date: Wed, 17 Feb 2016 20:38:09 +0000

----- Original Message -----
From: "Jeffrey Haas" <[email-masked]>
To: "Alvaro Retana (aretana)" <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>
Sent: Wednesday, February 17, 2016 3:19 PM

Updating the registry to Unspecific would reflect common implementation
practice.  For years, 0 has basically meant "this doesn't fit into
anything else".

The existing value of reserved in the registry was likely an oversight
as part of registry maintenance over the long life of BGP.  Even RFC
1771 section 6 covers the 0 as an appropriate value, yet it's not listed
in the enumerations of the different code types.

FWIW, Junos uses the word "unspecified" in several of the debugging
outputs rather than "unspecific".  I would lean toward unspecified. :-)

Note that the BGP MIBs do not provide any related enumerations so there
is no support one way or the other in existing standardized items beyond
the normative text in the RFCs that value 0 is to be used.

<tp>

Jeff

Two more reasons to reject this Erratum

First, from RFC4276

s.3.19.98.  Recognized but Malformed Optional Parameters

       Functionality/Description: The Error Subcode MUST be set to 0
       (Unspecific)

       RFC2119: MUST

       Alcatel Y/N/O/Comments: Y
       Cisco   Y/N/O/Comments: N
       Laurel  Y/N/O/Comments: Y
       NextHop Y/N/O/Comments: Y

Mmmmm, shame about that 'N'

Meanwhile from the archives,

Date: Mon, 29 Oct 2001 12:01:24 -0500
From: Jeffrey Haas <[email-masked]>
To: Yakov Rekhter <[email-masked]>
Cc: [email-masked]
Subject: Re: draft-14 misc. comments
<snip>

> > : 6.2 OPEN message error handling.
> >
> > [...]
> >
> > :    If one of the Optional Parameters in the OPEN message is not
> > :    recognized, then the Error Subcode is set to Unsupported
Optional
> > :    Parameters.
> >
> > What about when optional parameters items are malformed?
>
> The same - Unsupported Optional Parameters.

I would suggest otherwise.  "Unsupported" argues that we do not support
it.  If it is supported and is malformed, I would argue 0 (unspecific)
is more appropriate in the absence of a new error subcode.

Should the draft, draft-chen-bgp-cease-subcode-00.txt, be made a
generic BGP error code cleanup document if accepted as a WG item?

If so, this would argue adding a new subcode to open:

7 - Malformed Optional Attribute(s)
Data - contains the malformed optional attributes.

In the case where the field lenghts are malformed, 0 (unspecific) is
still probably appropriate.

--
Jeff Haas
NextHop Technologies

<end of extract from the archives>

The change was incorporated in the I-D by Yakov 31 October 2001

Tom Petch

-- Jeff

which I
pa

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Wed, 17 Feb 2016 21:42:24 +0000

On 2/17/16, 4:38 PM, "Idr on behalf of t.petch" <[email-masked] on

>outputs rather than "unspecific".  I would lean toward unspecified. :-)

If this errata is approved (and I don’t feel strongly either way), I would
vote emphatically to use “Unspecified”.

Acee

---

From: <[email-masked]>
Date: Thu, 18 Feb 2016 09:08:26 +0000

Hi Tom,

Please see inline

> From: t.petch [mailto:[email-masked]] > Sent: Wednesday, February 17, 2016 6:15 PM
> 
> to add 0(Unspecific) for the OPEN Message Error subcodes list 

Agreed.

> but I

I don't think you can call "implementation error" a behavior which is specified in the RFC:
"If no appropriate Error Subcode is defined, then a zero (Unspecific) value is used for the Error Subcode field."
https://tools.ietf.org/html/rfc4271#section-4.5

This sentence is generic and applies to all error codes.

Accepting the errata or not is a different story.

-- Bruno

> >http://www.iana.org/assignments/bgp-parameters/bgp-
> parameters.xhtml#bgp
> -pa
> >rameters-4
> >
> >Instructions:
> >-------------

---

From: "John G. Scudder" <[email-masked]>
Date: Mon, 22 Feb 2016 17:06:06 -0500

> This sentence is generic and applies to all error codes.

I find this argument compelling.

IMpersonalO the erratum should be accepted and the registry updated as others have suggested. N.b. I also prefer "Unspecified" to "Unspecific" in the registry.

Thanks,

--John

---

From: t.petch <[email-masked]>
Date: Tue, 23 Feb 2016 11:46:47 +0000

<inline>
Tom Petch

----- Original Message -----
From: <[email-masked]>
To: "t.petch" <[email-masked]>; "Alvaro Retana (aretana)"
<[email-masked]>; <[email-masked]>
Sent: Thursday, February 18, 2016 9:08

Hi Tom,

Please see inline

> specific.  The IANA registry [1] lists the value 0 as "Reserved",
which

Agreed.

> which I have no problem with).

I don't think you can call "implementation error" a behavior which is
specified in the RFC:
"If no appropriate Error Subcode is defined, then a zero (Unspecific)
value is used for the Error Subcode field."
https://tools.ietf.org/html/rfc4271#section-4.5

<tp>

Ah yes, my mistake.

On balance, I would still support an Erratum that updates "OPEN Message
Error subcodes:" but would see updating all the lists of subcodes as
going too far.

A zero subcode for any other message is not something that the IDR WG
could think of a reason for, unlike the case of OPEN, so while calling
it an error is wrong, it remains something unusual, unexpected.  Adding
it to all the lists of subcodes would seem to go beyond what the IDR WG
consented to when it produced RFC4271.

Tom Petch

-- Bruno

> parameters.xhtml#bgp-

________________________________________________________________________
_________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations
confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez
recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages
electroniques etant susceptibles d'alteration,
Orange decline toute responsabilite si ce message a ete altere, deforme
ou falsifie. Merci.

This message and its attachments may contain confidential or privileged
information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and
delete this message and its attachments.
As emails may be altered, Orange is not liable for messages that have
been modified, changed or falsified.
Thank you.