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

["Acee Lindem (acee)" <[e-mail]>]

On 2/17/16, 4:38 PM, "Idr on behalf of t.petch" <[e-mail] on
behalf of [e-mail]> wrote:

>----- Original Message -----
>From: "Jeffrey Haas" <[e-mail]>
>To: "Alvaro Retana (aretana)" <[e-mail]>
>Cc: <[e-mail]>; <[e-mail]>
>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. :-)

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

Acee 


>
>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 <[e-mail]>
>To: Yakov Rekhter <[e-mail]>
>Cc: [e-mail]
>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
>
>
>> On Feb 17, 2016, at 10:08 AM, Alvaro Retana (aretana)
><[e-mail]> wrote:
>>
>> 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" <[e-mail]>
>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 <[e-mail]>
>>>
>>> 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
>>>
>>
>> _______________________________________________
>> Idr mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/idr
>
>_______________________________________________
>Idr mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/idr
>
>_______________________________________________
>Idr mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/idr