Re: [Idr] Fwd: Re: Last Call: <draft-ietf-idr-rfc4893bis-06.txt> (BGP Support for Four-octet AS Number Space) to Proposed Standard

[Enke Chen <[e-mail]>]

Here is my reply to Claudio on the IDR list.  Copying the IETF list.

------------------------------------------------------
Hi, Claudio:

Not sure if you are aware of the large scale outage that occurred a few 
years ago from the leak of the confed related segments by one 
implementation. At the time quite a few implementations were resetting 
the sessions when receiving such updates.

While discarding the whole AS4_PATH would be simpler and less disruptive 
(than session resetting), it would still lose the vital as-path info 
contained in the AS4_PATH which can otherwise be recovered by 
"repairing" the attribute.  That is why the approach specified in the 
rfc4893bis is adopted, and it has been implemented widely.

-- Enke


On 6/12/12 7:25 AM, Stewart Bryant wrote:
> FYI
>
> Copying to IETF list as this is an IETF LC
>
> Stewart
>
> -------- Original Message --------
> Subject:     Re: [Idr] Last Call: (BGP Support for Four-octet AS 
> Number Space) to Proposed Standard
> Date:     Tue, 12 Jun 2012 15:54:55 +0200
> From:     Claudio Jeker <[e-mail]>
> To:     Stewart Bryant <[e-mail]>
> CC: <[e-mail]>
>
>
>
> On Tue, Jun 12, 2012 at 11:30:11AM +0100, Stewart Bryant wrote:
>> On 01/06/2012 23:00, Claudio Jeker wrote:
>> >On Fri, Jun 01, 2012 at 11:54:44AM -0700, The IESG wrote:
>> >>The IESG has received a request from the Inter-Domain Routing WG 
>> (idr) to
>> >>consider the following document:
>> >>- 'BGP Support for Four-octet AS Number Space'
>> >> <draft-ietf-idr-rfc4893bis-06.txt> as Proposed Standard
>> >>
>> >>The IESG plans to make a decision in the next few weeks, and solicits
>> >>final comments on this action. Please send substantive comments to the
>> >>[e-mail] mailing lists by 2012-06-15. Exceptionally, comments 
>> may be
>> >>sent to [e-mail] instead. In either case, please retain the
>> >>beginning of the Subject line to allow automated sorting.
>> >>
>> >>Abstract
>> >>
>> >>
>> >>    The Autonomous System (AS) number is encoded as a two-octet 
>> entity in
>> >>    the base BGP specification. This document describes extensions 
>> to BGP
>> >>    to carry the Autonomous System numbers as four-octet entities.  
>> This
>> >>    document obsoletes RFC 4893.
>> >>
>> >Just for the sake of clarity, OpenBGPD will not do the following:
>> >
>> >    In addition, the path segment types AS_CONFED_SEQUENCE and
>> >    AS_CONFED_SET [RFC5065] MUST NOT be carried in the AS4_PATH 
>> attribute
>> >    of an UPDATE message.  A NEW BGP speaker that receives these path
>> >    segment types in the AS4_PATH attribute of an UPDATE message 
>> from an
>> >    OLD BGP speaker MUST discard these path segments, adjust the 
>> relevant
>> >    attribute fields accordingly, and continue processing the UPDATE
>> >    message.  This case SHOULD be logged locally for analysis.
>> >
>> >There is no point to do this fiddeling instead we will treat this 
>> like any
>> >other parse error of AS4_PATH.
>> >
>> Claudio
>>
>> Since this is in last call, I have to ask whether you have objection
>> to the publication
>> of the above text, or have any proposed text changes?
>
> I see no reason to enforce AS_CONFED_SEQUENCE and AS_CONFED_SET stripping
> on all AS4 implementations. It forces bgp implementations that don't have
> confederation support to strip out something that will cause an error in
> the regular path and for those systems ignoring the AS4_PATH attribute
> is perfectly fine. I do not understand how a workaround needs to be a
> MUST for something that is a MUST NOT at the same time? Why MUST we
> workaround something that MUST NOT appear? Why do we need to add extra
> code that is hard to test and maybe cause for further errors because it
> modifies attributes in very uncommon way?
>
> I propose to remove that paragraph entierly since it does only add
> complexity to the protocol for no reason and therefor is only a source of
> errors without any benefit.