Re: [Idr] RFC 4893 - Aggregation and mismatching AS paths

[Jeffrey Haas <jhaas at pfrc.org>]

Neil,

On Mon, Mar 31, 2008 at 02:32:36PM +0100, Neil Matthew wrote:
> 1. Aggregation (should an AS_SET contain multiple AS_TRANS entries)?
> When performing route aggregation a four-octet peer may create an AS_SET 
> with multiple non-mappable four-octet ASes.  When calculating the number 
> of ASes in a path an AS_SET counts as one regardless of how many ASes it 
> contains.  Am I therefore correct in thinking that it is an 
> implementation choice as to whether a four-octet peer advertising to a 
> two-octet peer creates an AS_SET with a single AS_TRANS entry 
> representing all non-mappable AS numbers or multiple AS_TRANS entries, 
> one per non-mappable AS?

There are (at least) two scenarios here:
1. A 4-octet ignorant speaker performs the aggregation.  If it does, you
will have AS4_ attributes that can't map to the aggregated AS path.  The
agregation rules in the BGP RFCs would have any duplicate AS numbers
removed from the AS_SET, including AS_TRANS.

2. A 4-octet aware speaker performs aggregation.  It's AS_SET will
contain all ASes.  When the aggregated path is set to a 4-octet ignorant
speaker, the 2-byte AS_PATH will contain multiple instances of AS_TRANS.

*HOWEVER*, it's not completely impossible that some BGP speaker further
downstream will choose to compress the AS_SET.  I believe that's
relatively unlikely in current implementations but it is not precluded.

> 2. Non Matching AS_PATH and AS4_PATH Attributes
> I wonder whether RFC 4893 defines strictly enough the required 
> relationship between AS_PATH and AS4_PATH. The RFC stipulates that the 
> number of AS numbers in an AS4_PATH must not exceed that of the 
> AS_PATH.  However this does not rule out the AS4_PATH containing more 
> segments (and by implication differing segment sizes).  If this were to 
> occur it would suggest something bad has happened. What should an 
> implementation do in such a situation? Accept the AS4_PATH or raise an 
> error?

This issue was raised a few times during the draft process.  It might be
interesting for you to review the mail archives for that discussion. :-)

One possible workaround for this is roughly this:
1. Prior to aggregation by a 4-octet ignorant implementation, the
AS4_PATH had all 4-octet ASes.
2. After aggregation by a 4-octet ignorant implementation, AS_TRANS will
be present one or more times.  New 2-octet ASes will join the aggregate.
3a. When it comes time to reconstruct the 4-octet path, if the leading
set of AS_SEQUENCE can be reasonably mapped to the AS4_PATH, missing
4-octet ASes can be added to the AS_SET.  This has the entertaining
property of potentially lengthening the calculated AS_PATH length by
overflowing a previously shorter segment.

Workaround 2:
3b. When you can't reasonably map the 2-octet path to the 4-octet path,
you may simply have to use what components are available from the
2-octet path as your leading sequence.  You could then put the remaining
ASes into as many AS_SET segments as need be.  This implicitly
re-aggregates the path.  HOWEVER, it is important to try to keep the new
calculated path length at least the same length.  Otherwise you may
create the potential for routing loops.

Final note: Artificially lengthening the new path by partially filling
AS_SET segments may not survive downstream if some implementation
aggressively implements segment compression.

-- Jeff
_______________________________________________
Idr mailing list
Idr at ietf.org
https://www.ietf.org/mailman/listinfo/idr