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

[Brian Dickson <[e-mail]>]

Hi, Caudio,

Comments in-line.

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

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


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

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