Re: [Idr] [Fwd: I-D Action:draft-chen-rfc4893bis-02.txt]

[David Freedman <david.freedman at uk.clara.net>]

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

Quoth Rob:

> From my interpretation of the RFCs, the precedent that has been set is that when
> a neighbour hands us invalid attributes, we will send a NOTIFICATION. The root
> of the problems with rfc4893 are that we implemented this behaviour to an OLD
> speaker that, from its perspective, was propagating completely valid attributes.
> I would appreciate some feedback on whether rfc4893 should introduce
> 'permissive' behaviour, where invalid attributes are discarded, and we attempt
> to workaround the lack of them -- or whether we should still penalise the
> invalid attribute by treating this UPDATE as WITHDRAW.

I'm still of the opinion that we should discard/withdraw the update as
appropriate, I'm still not comfortable about discarding attributes like
this, especially where we see a mix of people both doing and not doing
this during transition to the (eventual) standard.

Is there nobody else who thinks this is a bad thing (tm) ?

I'd much rather not have reachability to a prefix because somebody
screwed up than risk having broken reachability and loops.


Dave.