It doesn't clarify anything for me, but then I happen to know where that algorithm is defined.
Having spend the better part of last week stepping a vendor through exactly these semantics, my current mood is that explicit and specific is better.
The intent in having the ref where it is, is to point at the AS_PATH => Origin As mapping procedure, rather than that section more generally.
Cheers,
Ben
From: Randy Bush <randy@xxxxxxx>
Sent: Friday, 20 March 2020, 20:29
To: Ben Maddison
Cc: keyur@xxxxxxxxxx; last-call@xxxxxxxx; rjsparks@xxxxxxxxxxxx; sidrops@xxxxxxxx; gen-art@xxxxxxxx; draft-ietf-sidrops-ov-egress.all@xxxxxxxx
Subject: Re: [Sidrops] Genart last call review of draft-ietf-sidrops-ov-egress-01
> Although a little more verbose, perhaps the following is more explicit?
>
> As the origin AS of a BGP UPDATE is decided by configuration and
> outbound policy of the BGP speaker, a validating BGP speaker MUST
> apply Route Origin Validation policy semantics Against the Route
> Origin ASN as determined by applying the procedure in [RFC6811,
> Section 2] to the AS_PATH (see RFC 4271 4.3 Path Attributes:b) that
> it will send in the UPDATE to the peer.
i am torn about adding yet another 6811 ref. does it clarify anything?
are there other possible "Route Origin Validation policy semantics?"
if so, i might put it earlier, after "apply Route Origin Validation
policy semantics".
randy
--
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call
