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

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

On Mon, Jan 26, 2009 at 05:08:01PM -0800, Enke Chen wrote:
> The particular error involves "over supply of information" which can be  
> repaired by removing the unnecessary information. At the risk of  
> repeating myself, this is a recoverable, non-fatal error. The  
> time-tested principle of "be liberal in what you accept" is precisely  
> for dealing with this kind of non-fatal errors in protocol design.

We do not agree with your statement that this is "over supply of 
information" as an AS_CONFED_SET/SEQUENCE is garbage data outside of the 
network making use of confederations, and infact it could be considered 
harmful misinformation if the neighbouring network also makes use of 
confederations.

We do, however, agree that your suggested method for handling the 
presence of an AS_CONFED_SET/SEQUENCE is suitable for dealing with this 
specific bug, and comparatively easy to implement. Fom an operational 
perspective, this is also probably the best way to deal with the 
specific case since there are a large number of JunOS devices deployed 
that may to continue to insert AS_CONFED_SET/SEQUENCE into AS4_PATH in 
the future.

We therefore accept the new handling of this specific error condition as 
being a necessary evil.

Section 6 of the new draft defines handling for a general error case 
with behaviour that we do not believe is safe. Considering that the 
AS4_PATH is mechanism for transporting unsupported AS_PATH information 
through a number of AS4-unaware devices we must bear in mind that there 
is a reconciliation process with AS_PATH. Given the role of AS_PATH in 
loop prevention we feel that general lax treatment of AS4_PATH may have 
harmful concequences in the future.

We feel that the general behaviour on an error should be the withdrawal 
of the path, as discarding the attribute is equivalent in effect to 
discarding part of the AS_PATH and may cause loops. Take for example the 
case when an BGP speaker in a 32bit AS receiving an invalid AS4_PATH 
attribute. With the AS4_PATH unreadable and therefore discarded the BGP 
speaker cannot know if its AS number was in the path. The only loop free 
options are:
(a) treat it as a withdrawal
(b) treat any AS_TRANS in the AS_PATH as the local AS
(c) drop the session.

Option c is the behaviour that has led us to needing a change to the 
RFC, so is obviously unacceptable.
Option a and b are equivalent since the AS4_PATH attribute would not be 
present if there wasn't an AS_TRANS in the AS_PATH.

While your "be liberal in what you accept" approach is commendable, and 
often an excellent idea, a line does need to be drawn. We cannot and 
should not extend the standards with special cases every time someone 
makes an implementation error or we risk creating an RFC that's almost 
impossible to implement without making further silly mistakes.

Kind regards,
	Jonathan Oddy (Hostway UK)
	Rob Shakir (GX Networks)
_______________________________________________
Idr mailing list
Idr at ietf.org
https://www.ietf.org/mailman/listinfo/idr