Re: [Sidrops] Genart last call review of draft-ietf-sidrops-ov-egress-01

[Keyur Patel <[e-mail]>]

On 3/18/20, 12:56 PM, "Randy Bush" <[e-mail]> wrote:

    ( 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" <[e-mail]> 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.


Looks good to me. __ 

Regards,
Keyur
    
    randy