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

[John Leslie <[e-mail]>]

Enke Chen <[e-mail]> wrote:
> On 6/12/12 7:25 AM, Stewart Bryant wrote:
> From:     Claudio Jeker <[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
>>>>>
>>>>> 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

   That would make the OpenBSD implementation non-compliant with 4893bis.

>>> 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?

   Enke explains why this is called for in 4893bis.

   It may help to recall the IETF mantra: "We believe in rough consensus
and running code."

   At the time 4893 was designed, it was a strict requirement in IDR
that nothing could get to Proposed Standard without demonstrating
multiple implementations. In practice, this meant we only documented
something after multiple vendors had it deployed.

   Thus, 4893 went out with bugs (though I was in the rough, explaining
in general terms some weaknesses).

   One bug in particular turned out to be _very_ serious. Patching in
the AS4_PATH produced some AS_CONFED stuff very much out of context.
A fix was desperately needed, and several vendors quickly patched it.
4893bis, as I understood it, documented this fix. I'm still in the rough,
but I saw no point in objecting to documenting actual practice.

   If in fact, OpenBSD has no intention of patching for this bug, _they_
need to be considered "in the rough" (as well as non-compliant).

   If, OTOH, they wish to propose a different fix, it's possible the
IESG might ask IDR to consider it. (I can certainly imagine better ways
to resolve the problem.)

   But any fix (IMHO) _must_ dispose of out-of-context AS_CONFED stuff
that still may be in the wild.

>> 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.

   (I cannot endorse that proposal. It's too likely there's legacy
equipment that allows AS_CONFED stuff to be placed in AS4_PATH.)

> 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

--
John Leslie <[e-mail]>