Re: [Idr] Re: Revised text on how to construct the AS path info

On Wed, 12 Oct 2005, Enke Chen wrote:

> Hi, Paul:
>
> You seem to be talking about the same case described in the 
> Transition Sect. of the document::

No, I mean any case where one or more 4-byte paths are aggregated 
with one or more non-4-byte paths. The part in the draft concerns 
itself with two 4-byte paths being aggregated.

> As I am not aware of any implementation that compares and preserves 
> unrecognized attributes in aggregation, I concur that it should be 
> "rare" to see the NEW_AS_PATH after aggregation by an OLD BGP 
> speaker.

Sure. But the transitional mechanism specified in the draft might 
have to remain 'dormant' for 5 or more years. So in addition to 
considering what is typical for speakers today, we should consider 
situations which are valid according to the RFC, particularly if they 
are very easy to deal with.

> In the unlikely scenario that the NEW_AS_PATH got preserved during 
> aggregation by an OLD BGP speaker,  as it is not possible to construct the 
> exact AS path info, it does not seem to matter whether we take the AS_PATH or 
> the NEW_AS_PATH as each of them contains partial, valid info.

Well, the point is more that the merging /method/ doesn't apply any 
longer - the path lengths won't correlate. The method might even fail 
to include /any/ of the OLD path - which clearly is wrong.

> (We could add some clarification, though.)

What exactly is wrong with just ignoring NEW_AS_PATH if 
NEW_AGGREGATOR is? It's consistent and should be simple enough to 
state. I've left the outline quoted below.

> Regardless this loss of AS path info is not new for aggregation. 
> Currently a large portion of the aggregates are created without 
> AS_SET.

Sure, but I do not per se refer to the aggregated information. Other 
portions of the leading path could be lost too, because the method 
itself is inappropriate in such a case.

> -- Enke

>> (For in such a case the path length of the NEW_AS_PATH no longer would have 
>> any strong correlation to the path length of any trailing portion of the 
>> OLD AS_PATH, so the method to determine which part is 'leading' would 
>> produce a meaningless result - eg, it might indicate the AS_PATH has /no/ 
>> leading portion at all, or even a 'negative' leading portion ;) ).

>> E.g: move the text about ignoring NEW_AGGREGATOR to /before/ the text about 
>> NEW_AS_PATH and make the text concerning AS_PATH/NEW_AS_PATH be something 
>> like:
>> 
>> - if NEW_AGGREGATOR was present but has been ignored:
>>     - ignore NEW_AS_PATH
>>     - just strip AS_TRANS from the 2-byte AS_PATH and form the
>>           4-byte PATH directly from the result
>> - else
>>     - perform the merging process (i.e. the updated text you
>>           posted)

regards,
-- 
Paul Jakma	paul@clubi.ie	paul@jakma.org	Key ID: 64A2FF6A
Fortune:
 	The judge fined the jaywalker fifty dollars and told him if he was
caught again, he would be thrown in jail.  Fine today, cooler tomorrow.

_______________________________________________
Idr mailing list
Idr@ietf.org
https://www1.ietf.org/mailman/listinfo/idr