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

From: The IESG <[email-masked]>
Date: Fri, 01 Jun 2012 11:54:44 -0700

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
[email-masked] mailing lists by 2012-06-15. Exceptionally, comments may be
sent to [email-masked] 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.

The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-idr-rfc4893bis/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-idr-rfc4893bis/ballot/

No IPR declarations have been submitted directly on this I-D.

---

From: Claudio Jeker <[email-masked]>
Date: Sat, 2 Jun 2012 00:00:00 +0200

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

-- 
:wq Claudio

---

From: Stewart Bryant <[email-masked]>
Date: Tue, 12 Jun 2012 11:30:11 +0100

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

Stewart

---

From: Claudio Jeker <[email-masked]>
Date: Tue, 12 Jun 2012 15:54:55 +0200

On Tue, Jun 12, 2012 at 11:30:11AM +0100, Stewart Bryant wrote:
> Since this is in last call, I have to ask whether you have objection
> to the publication

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.
-- 
:wq Claudio

---

From: Stewart Bryant <[email-masked]>
Date: Tue, 12 Jun 2012 15:25:34 +0100

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 <[email-masked]>
To: 	Stewart Bryant <[email-masked]>
CC: 	<[email-masked]>

---

From: Robert Raszuk <[email-masked]>
Date: Tue, 12 Jun 2012 08:38:29 -0700

Hi Claudio,

One clarification question to your comment ...

> It forces bgp implementations that don't have
> is perfectly fine.

Why are you saying that there will be an error in the regular AS_PATH ? 
As far as I can see the above quote refers only to AS4_PATH.

The motivation is that instead of dropping the session or treating as 
withdraw robust BGP speaker can just remove the unexpected bad elements 
from AS4_PATH. In that respect this paragraph seems to add value and 
should be kept.

Rgs,
R.

---

From: Claudio Jeker <[email-masked]>
Date: Tue, 12 Jun 2012 19:14:01 +0200

On Tue, Jun 12, 2012 at 08:38:29AM -0700, Robert Raszuk wrote:
> Why are you saying that there will be an error in the regular
> AS_PATH ? As far as I can see the above quote refers only to
> AS4_PATH.

If an implementation does not support confederations then an AS_PATH with
confederation elements will cause an error. Sure an invalid AS4_PATH as
that does not imply that the AS_PATH will have the same structure.

> The motivation is that instead of dropping the session or treating
> as withdraw robust BGP speaker can just remove the unexpected bad
> elements from AS4_PATH. In that respect this paragraph seems to add
> value and should be kept.

It seems you did not finish reading the draft:

   The AS4_PATH attribute in an UPDATE message SHALL be considered
   malformed under the following conditions:

...

      - the path segment type in the attribute is not one of the
        types defined: AS_SEQUENCE, AS_SET.

   A NEW BGP speaker that receives a malformed AS4_PATH attribute in an
   UPDATE message from an OLD BGP speaker MUST discard the attribute,
   and continue processing the UPDATE message.  The error SHOULD be
   logged locally for analysis.

So there is no dropping of the session and also no treat as withdraw.
It will just remove a malformed AS4_PATH from the received attributes.
Since an AS4_PATH attribute MUST NOT include AS_CONFED_SEQUENCE and
AS_CONFED_SET (or anything else but AS_SEQUENCE and AS_SET) it can be
considered malformed.

What will we gain from having to add complex code for something that
should not happen in the first place instead of using the default of
reverting back to the regular 2-byte AS_PATH attribute because the
AS4_PATH attribute was considered malformed?

-- 
:wq Claudio

---

From: Enke Chen <[email-masked]>
Date: Tue, 12 Jun 2012 10:38:18 -0700

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

---

From: Enke Chen <[email-masked]>
Date: Tue, 12 Jun 2012 11:20:31 -0700

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

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

-- Enke

On 6/12/12 7:25 AM, Stewart Bryant wrote:
> Subject:     Re: [Idr] Last Call: (BGP Support for Four-octet AS 
> Number Space) to Proposed Standard

---

From: John Leslie <[email-masked]>
Date: Thu, 14 Jun 2012 02:26:10 -0400

Enke Chen <[email-masked]> wrote:
>>>>> The IESG has received a request from the Inter-Domain Routing WG
>>>>> (idr) to consider the following document:
>>>>>  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.
>>>>
>>>>  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.

>>> to the publication of the above text, or have any proposed text
>>> changes?
>>

   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.

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

--
John Leslie <[email-masked]>

---

From: Stewart Bryant <[email-masked]>
Date: Fri, 29 Jun 2012 12:06:16 +0100

> other parse error of AS4_PATH.

Claudio,

Thank you for your email.

I see no support for a text change to support this observation,
and several emails explaining that original text addresses an
observed problem.

The IETF process in such circumstances is to declare that the proposed
change is in the rough and proceed with the publication.

I will therefore continue with the publication process for the
document as revised to address the other IETF last call comments.

- Stewart

---

From: Brian Dickson <[email-masked]>
Date: Fri, 29 Jun 2012 08:45:39 -0400

Hi, Caudio,

Comments in-line.

On Tue, Jun 12, 2012 at 9:54 AM, Claudio Jeker <[email-masked]>wrote:

> attribute
If you read the phrase "be carried in" as "be advertised in", does that
help at all?

Regardless of the specific cases (known to have happened), it falls under
the general rule,
"Be liberal in what you receive, and conservative in what you send."

If you merely ignore, without stripping *_CONFED_*, you are being liberal
in what you send -- which is bad.

Feel free to do the stripping on the send side rather than receive, where
you already have
to munge the attributes (e.g. to add your own AS/AS4 to the path).

Does that make it any easier to do?

> errors without any benefit.

The assumption that incoming UPDATE messages are completely well-formed has
proven to be a poor choice historically.

The text above clarifies how to correct a specific error, and avoids the
situation,
"never check for an error condition you don't know how to handle".

By specifying how to handle it, requiring the checking becomes very
reasonable, IMHO.

BTW - I believe it does not apply to OLD BGP speakers at all, who ignore
AS4_PATH. Does that help?

Brian