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

["Jakob Heitz (jheitz)" <[e-mail]>]

We know better than to ever invent an attribute type that can appear more than once in an UPDATE. An UPDATE with multiple attributes of a single type would never survive a trip through a legacy router. It is not a serious restriction. For example, we can fit many communities into a community attribute.

--
Jakob Heitz.


> On May 28, 2014, at 4:22 AM, "Deniz Bahadir" <[e-mail]> wrote:
> 
> My English seems not to be the best. I should probably replace "realized" with "identified" in my proposed-sentence.
> I replaced it inline further down.
> 
> Deniz
> 
> Am 28.05.2014 13:13, schrieb Deniz Bahadir:
>> 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):
> 
> OLD:
>> "[...] 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.)"
> 
> NEW:
> "[...] 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 identified 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
>> 
>> _______________________________________________
>> Idr mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/idr
> 
> _______________________________________________
> Idr mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/idr