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

[Paul Jakma <[e-mail]>]

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,
-- 
Paul Jakma	[e-mail]	[e-mail]	Key ID: 64A2FF6A
Fortune:
"The four building blocks of the universe are fire, water, gravel and vinyl."
 		-- Dave Barry

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