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

[Rob Shakir <[e-mail]>]

On Tue, Mar 10, 2009 at 02:28:17PM +0000, David Freedman wrote:
> 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.

Whilst I appreciate that I am effectively agreeing with myself by proxy here --
the other issue that I feel that we should bear in mind is the fact that Enke
and John have proposed the withdraw solution in
draft-scudder-idr-optional-transitive. I cannot see how one can reconcile the
behaviour that is suggested in this draft with the proposed rfc4893 draft. I
think the question we have to ask is why, if there is some other draft that
proposes it is reasonable to withdraw the prefix for /other/ broken attributes,
it is not reasonable to standardise the behaviour here?

I think that with the new draft in mind, there is no precedent for dropping the
update, and we should standardise not being permissive to a BGP speaker who is
broken. The key thing to remember here, as I see it, is that the speaker does
not comply with the original RFC -- the only BGP speakers that we are penalising
are broken by a standard that has already reached RFC.

Kind regards,
Rob

-- 
Rob Shakir                      <[e-mail]>
Network Development Engineer    GX Networks/Vialtus Solutions
ddi: [phone]            mob: [phone]
pgp: 0xc07e6deb                 nic-hdl: RJS-RIPE

This email is subject to: http//www.vialtus.com/disclaimer.html