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

From: Neil Matthew <[email-masked]>
Date: Mon, 31 Mar 2008 14:32:36 +0100

Hi Folks

I'm seeking clarification on a couple of points.

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?

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?

Cheers

Neil

_______________________________________________
Idr mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/idr

---

From: Jeffrey Haas <[email-masked]>
Date: Mon, 31 Mar 2008 10:45:14 -0400

Neil,

> representing all non-mappable AS numbers or multiple AS_TRANS entries, 

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.

> implementation do in such a situation? Accept the AS4_PATH or raise an 

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