( warning: quote depth errors and top posting. keyur's mta, well let's not get into that :) > Speaking as a wg member. and one of the first ROV implementors, tyvm. > Shouldn’t you be checking the "my autonomous system number" in the > update message (when sending it out to the ebgp peer) as opposed to > "my autonomous system number" in the open message. > > Regards, Keyur > > On 3/17/20, 8:27 PM, "Randy Bush" <randy@xxxxxxx> wrote: > >> I wanted to avoid "be able to be" and have an explicit actor. I see >> the difficulty you point to below. > > i am happy to change to the following > >>> As the origin AS may be modified by outbound policy, a BGP speaker >>> MUST apply ROV policy semantics using the My Autonomous System number >>> in the BGP OPEN message (see RFC 4271 section 4.2) issued to the peer >>> to which the UPDATE is being sent. > > but, in my free opinion, as it is in IETF LC, the change is enough that > it might require approval by chairs and/or AD. i think you're right. what counts for ROV is the origin AS in the UPDATE. open a hole to deviate from that and ... and we have to remember that, for these UPDATEs which are redistributed into BGP by this speaker, have their AS_PATH first created when sent to the peer. i.e. we can not (yet) speak of the origin AS in the AS_PATH. so maybe 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 origin Autonomous System number which it will put in the AS_PATH (see RFC 4271 4.3 Path Attributes:b) of the UPDATE to the peer. randy -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call