Re: [Idr] Fwd: New Version Notification for draft-scudder-idr-optional-transitive-00

[Rob Shakir <rjs at eng.gxn.net>]

On Tue, Mar 03, 2009 at 09:00:15AM -0500, John G. Scudder wrote:
> I'd be interested in feedback from the WG regarding the question of  
> withdrawing the routes (what the draft proposes) vs. dropping the  
> session (current behavior).  Especially feedback from network operators.

John,

Thanks very much for the work on this draft by Enke and yourself.

From my perspective (and I think a number of other operators that I have spoken
with), the approach of treating the invalid update as a withdraw of the routes
within it is the best way to handle this problem -- as I posted to the list
earlier in the year.

Whilst I think that there is perhaps scope for comments on this draft that ask
for this behaviour to be extended to all optional transitive attributes, rather
than just those with the partial bit set, I do not think that this is the best
way forward on this matter. The major operational problem with tunneled
attributes (as well as the security implications), is that the operator does not
have a direct relationship with the party that has caused the session to be torn
down -- any errors in a direct neighbour's BGP implementation can generally be
addressed by existing communication channels with the neighbouring AS, and hence
a comparitively easier to resolve.

With regards to the question posed earlier in this thread as to whether it is
preferable to see session teardown, or 99% of the prefixes on this session
withdrawn, I would definitely lean towards the prefixes being withdrawn. The
reasoning is even clearer when taking the opposite extreme -- a single prefix
tearing down a session carrying the global table. In this case, the impact to
the network that receives this update is that we lose visibility of the global
BGP table  (by one of our paths at least), rather than just 'punishing' a single
prefix with unreachability.

Operationally -- I think that any 'harmful' implications of this issue are
well-handled by section 3 -- the requirement to provide debugging features
should allow operators to easily identify why this prefix has been withdrawn. It
is also worth considering the number of scenarios in which the prefix will
become completely unreachable from a multi-homed network -- I believe that this
will be rare in practice.

Once again -- thanks for the work on this.

Kind regards,
Rob

--
Rob Shakir                      <rjs at eng.gxn.net>
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