Re: [Idr] draft-ietf-idr-error-handling-09.txt

[Deniz Bahadir <[e-mail]>]

Hi there,

while trying to implement this draft I stumbled across a point which 
made me think if I really understood it correctly.


The sentence I stumbled across is in section 3.g. of the draft:

"[...] If any other attribute appears more than once in an UPDATE 
message, then all the occurrences of the attribute other than the first 
one SHALL be discarded and the UPDATE message continue to be processed."

This pretty much says the same as the corresponding sentence from 
section 6.3 of RFC 4271 (except for the action taken):

"If any attribute appears more than once in the UPDATE message, then the 
Error Subcode MUST be set to Malformed Attribute List."


What I am asking myself (and now you) is:
Does this really address *any* attribute which appears more than once, 
or only *recognized* attributes?


Of course, my implementation could realize by the attribute's type-code 
that an unrecognized (most likely optional) attribute appeared more than 
once in an UPDATE-message. But maybe, that could be valid for that 
unrecognized path-attribute?

So, if there is any chance of a (new) path-attribute to be allowed to 
appear more than once in an UPDATE-message, I would recommend to change 
the sentence in question to the following in the next version of this draft:


"[...] If any other recognized attribute appears more than once in an 
UPDATE message, then all the occurrences of the attribute other than the 
first one SHALL be discarded and the UPDATE message continue to be 
processed. Unrecognized attributes are still allowed to appear more than 
once."


If this it not what is intended, then I would recommend to explicitly 
state that this sentence is meant for recognized as well as unrecognized 
attributes, so that nobody might misinterpret it (as I might have done):


"[...] If any other attribute (no matter if recognized or not) appears 
more than once in an UPDATE message, then all the occurrences of the 
attribute other than the first one SHALL be discarded and the UPDATE 
message continue to be processed. (Multiple appearances of even 
unrecognized attributes can be be realized by the attributes' type-codes.)"


(The sentence in parentheses is just for clarification and could be 
removed if it is too obvious.)

Deniz


Am 20.05.2014 09:19, schrieb Deniz Bahadir:
> I have nothing to complain or to add.
> Therefore, I support this draft being the final version and becoming an
> RFC.
>
> Thanks for the good work,
> Deniz
>
>
> Am 19.05.2014 21:51, schrieb John G. Scudder:
>> There are just a few relatively small changes in this version:
>>
>> - Note that when MP-BGP is in use, NEXT_HOP is discretionary.
>> - Better text for NLRI section (thanks to Ondrej).
>> - Fix typos.
>>
>> With luck, we are spiraling in to a final version.
>>
>> Thanks, all.
>>
>> --John
>>
>> On May 19, 2014, at 3:33 PM, [e-mail] wrote:
>>
>>>
>>> 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
>>>                           Juniper Networks
>>>                           Pradosh Mohapatra
>>>                           Keyur Patel
>>>     Filename        : draft-ietf-idr-error-handling-09.txt
>>>     Pages           : 14
>>>     Date            : 2014-05-19
>>>
>>> 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-09
>>>
>>> A diff from the previous version is available at:
>>> http://www.ietf.org/rfcdiff?url2=draft-ietf-idr-error-handling-09
>>>
>>>
>>> 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/
>>
>
> _______________________________________________
> Idr mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/idr