[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Idr] [Fwd: I-D Action:draft-chen-rfc4893bis-00.txt]
Hi, Rob:
Please see my comments inlined.
Rob Shakir wrote:
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).
Stripping the confed path segments is pretty straightforward. IMO an
implementation that can deal with the merge of AS_PATH and AS4_PATH
should have no difficult in implementing the stripping.
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.
This seems to be a perfect case to follow the time-tested principle "Be
liberal in what you accept". It is a recoverable, non-fatal error.
There is no need to use any disruptive procedures.
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.
Thanks. That is exactly the objective of the new section.
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.
Here is an excerpt of your proposal posted to the IDR mailing list last
week:
-----------------------------------
There are two cases to consider when an invalid AS4_PATH is received:
(1) A path to the prefix is not already known from that neighbour.
(2) A path to the prefix has already been learnt from that neighbour;
In case (1) we recommend that the BGP speaker should discard the UPDATE and log
the fact. The log entry should include the received AS_PATH and
AS4_PATH to aid in debugging.
In case (2) we recommend that the BGP speaker should treat the UPDATE as a
withdrawal of existing path to the prefix. As per case (1) a log entry should be
raised to indicate that this has occurred.
------------------------------------
The proposal for (1) is incorrect from the protocol aspect. As BGP
update is incremental, we can not just hold on to the old info and
discard the new info.
The proposal for (2) is ok from the *pure* protocol aspect, but it would
cause unnecessary disruption (i.e., loss of connectivity) for this
recoverable, non-fatal error.
Thanks. -- Enke
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