[Idr] Re: WG LC for draft-ietf-idr-deprecate-as-set-confed-set-14 (7/8 to 7/

[Jeffrey Haas <[e-mail]>]

Alvaro,


> On Jul 17, 2024, at 12:21 PM, Alvaro Retana <[e-mail]> wrote:
> 
>>> 250 4.3. Recommendations to Mitigate Unpredictable AS_PATH Origins for
>>> 251 RPKI-ROV Purposes
>>> 
>>> 253 In order to ensure a consistent BGP origin AS is announced for
>>> 254 aggregate BGP routes for implementations of "brief" BGP aggregation,
>>> 255 the implementation should be configured to truncate the AS_PATH after
>>> 256 the right-most instance of the desired origin AS for the aggregate.
>>> 257 The desired origin AS could be the aggregating AS itself.
>>> 
>>> Should there be Normative language in this paragraph?
>>> 
>>> The obvious place seems to be s/implementation should be configured to
>>> truncate/implementation SHOULD be configured to truncate But, should that
>>> be a "MUST" instead? If the aggregation is to be "consistent", then the
>>> operation should be REQUIRED and not just RECOMMENDED.
>> 
>> It seems peculiar to try to be normative about "desired". "You're REQUIRED to
>> pick one". I'm reminded of the scene in an Indiana Jones movie where the main
>> character was required to "choose, but choose wisely".
>> 
>> What's being documented here is a configuration practice.
> 
> You lost me at "desired" -- what is the choice?  The text above talks
> about ensuring a consistent BGP origin announcement, which I
> interpreted as a requirement -- is it just a suggestion?

Is it a "requirement" that routes emitted from the aggregation procedure have an as-path that is "nice" for RPKI origin validation procedures?

If you know that you are generating aggregates that only aggregate at the AS of the speaker, is the requirement that there be ROAs for that provider AS?

If you know that the aggregates can be a downstream AS and you know that the aggregate will generate a path with that AS in the as-path, are you required to use that one instead in RPKI?

These are configuration options. They have RPKI implications. How you reconcile the two may be deployment specific.  How do you want those deployment specific considerations to be requirements?

-- Jeff