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

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

On Sat, Jan 24, 2009 at 01:19:08PM -0800, Enke Chen wrote:
> 3. Protocol Extensions
>
> A NEW BGP speaker SHOULD NOT send these path segment
> types 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 MUST discard these path segments,
> adjust the relevant attribute fields accordingly, and continue
> processing the UPDATE message.

Enke,

Thanks for following up on this matter.

I appreciate that stripping the confederation data from AS4_PATH does deal with
the problem of a neighbour resetting sessions due to an invalid optional
transitive attribute, I am not entirely convinced that it is the best way to
handle invalid data in AS4_PATH.

I understand from the current RFC that if we have a broken set of paths where
the AS4_PATH contains a conferation sequence, but this information has been
stripped from the AS_PATH and replaced with the confederation identifier, then
we will retain loop-prevention (due to the fact that the confed ID will be one
of the AS numbers that is prepended to the AS_PATH during AS4_PATH-AS_PATH
reconciliation).  Hence, by not discarding the update, and merely stripping the
invalid data then we do keep the required underlying functionality.

However, this does introduce some complexity into the implementation of this
standard, we must ensure to strip the correct elements from the AS4_PATH. Whilst
this should not be a matter of great importance - some implementors do not
produce standards-compliant behaviour (see the cause of the session resets that
we observed when connecting to the global table). I am interested to hear
whether you envisage problems being caused by incorrect data being stripped from
the AS4_PATH and hence result in routing information (which was present) being
lost? One possibility of this would be in AS_SET and AS_SEQUENCE being stripped
from the AS4_PATH (a feasible bug in an implementation of this new behaviour).

The other concern that I have is that if some BGP neighbour does not implement
the standard correctly, to what extent can the routing information produced by
and propagated through this neighbour be trusted? One of the advantages of the
approach that we suggested on the IDR list, in my eyes, was the fact that when
routing information is 'corrupted' by the insertion of invalid data into an
attribute, the receiver chooses to not use this routing data.  Operationally, I
feel that this behaviour is advantageous, since those paths that contain
incorrect information have a penalty placed against them.

> 6. Error Handling
>
> When a NEW BGP speaker encounters an error (other than the invalid
> confederation path segment types described previously) in parsing the
> AS4_PATH attribute or the AS4_AGGREGATOR attribute of an UPDATE
> message, the speaker MUST discard the attribute in error, and
> continue processing the UPDATE message. The error SHOULD be logged
> locally for analysis.

I appreciate this addition. Given this error, and the possibility for further
problems, there is definitely a requirement for a well defined method of dealing
with errors during the transition to 4-byte AS numbers, where these optional
transitive elements have the possibility to propagate far from the source
without any validation.

I would be very interested in your comments as to why it is felt that stripping
the invalid elements from the AS4_PATH attribute is a better solution than the
alternative we proposed to the IDR list last week.

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
_______________________________________________
Idr mailing list
Idr at ietf.org
https://www.ietf.org/mailman/listinfo/idr