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

From: David Freedman <[email-masked]>
Date: Tue, 10 Mar 2009 14:28:17 +0000

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

---

From: Andy Davidson <[email-masked]>
Date: Tue, 10 Mar 2009 14:45:38 +0000

On 10 Mar 2009, at 14:28, David Freedman wrote:

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

In my opinion, it is much more preferable to drop a prefix than to  
have to deal with learning the prefix in several differently broken  
ways.  Partial and unpredictable routing for the originator will be  
harder to debug than what seems to be no connectivity.  Please, let's  
adopt Rob's original, simple, clean suggestion :

  - discard new prefixes which have broken AS4_PATH properties.
  - treat existing prefixes which subsequently break as a withdraw.
  - Log in any case.

Kind regards,
Andy Davidson

---

From: "Neil J. McRae" <[email-masked]>
Date: Tue, 10 Mar 2009 15:33:45 -0000 (GMT)

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

I strongly agree with you Dave.

> screwed up than risk having broken reachability and loops.

Or broken routing costing you an arm and a leg. This behaviour could be
abused easily.

--
Neil J. McRae -- Alive and Kicking.
[email-masked]

---

From: Rob Shakir <[email-masked]>
Date: Tue, 10 Mar 2009 20:23:11 +0000

> 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                      <[email-masked]>
Network Development Engineer    GX Networks/Vialtus Solutions
ddi: +44208 587 6077            mob: +44797 155 4098
pgp: 0xc07e6deb                 nic-hdl: RJS-RIPE

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