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

[Enke Chen <[e-mail]>]

Hi, Paul:

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

----------------------------------------------------------------------------------
   Under certain conditions it may not be possible to reconstruct the
   entire AS path information from the AS_PATH and the NEW_AS_PATH
   attributes of a route. This occurs when two or more routes that carry
   the NEW_AS_PATH attribute are aggregated by an OLD BGP speaker, and
   the NEW_AS_PATH attribute of at least one of these routes carries at
   least one 4-octet AS number (as oppose to a 2-octet AS number that is
   encoded in 4 octets).
-----------------------------------------------------------------------------------

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.

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. 
(We could add some clarification, though.)

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

-- Enke

Paul Jakma wrote:

> Hi Enke,
>
> On Tue, 11 Oct 2005, Enke Chen wrote:
>
>> Hi, folks:
>>
>> Attached is the revised text on how to construct the AS path 
>> information.
>>
>> Please comment if you see any issue.
>
>
> Seems acceptable to me[1].
>
> The issue of what to do if we detect an OLD speaker has done 
> aggregation is still open though:
>
> - If AGGREGATOR does not contain AS_TRANS then:
>     - an OLD speaker, which tries to include unknown attributes
>           of aggregated routes in aggregates, has aggregated the
>           route
>       (these kinds of speakers are rare apparently?)
>
>     - NEW_AGGREGATOR should then be ignored (I believe you will
>           be specifying this in a new revision)
>
> This implies though that NEW_AS_PATH is *also* 'stale' and therefore 
> the merging method will not be appropriate. I'd suggest at least:
>
> - Also ignore NEW_AS_PATH if NEW_AGGREGATOR is ignored
>     - has an issue in what do about AS_TRANS's in the 2-byte path
>       - just remove it? (Section 7 mentions risks with
>             aggregates, as you pointed out to me privately)
>
> This seems far more appropriate than just merging AS_PATH and 
> NEW_AS_PATH given that doing so would likely replace the aggregate's 
> AS_SET information with completely different information from a stale 
> NEW_AS_PATH, or possibly fail to include /any/ portion of the 2-byte 
> path in the merged path.
>
> (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 
> ;) ).
>
> It's still sufficiently simple given that this condition will likely 
> be rare and the draft is willing to live with uncommon risks, 
> particulary wrt aggregation.
>
> 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)
>
> The risks could be mitigated better, but with a more involved process 
> of course.
>
>> -- Enke
>
>
> 1. Though, ideally, I'd prefer to see the NEW speaker actually check 
> the 2 paths make sense against each other, given the speaker doing the 
> merging is the only speaker who could detect any such inconsistencies. 
> After merging, the information will be lost. Also, the implementation 
> report strongly suggests that at least one of the implementations 
> /does/ attempt to detect inconsistencies... ;)
>
> regards,

_______________________________________________
Idr mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/idr