I think 6811 is the right ref for this. 8481 is the one you put in an RFP ;-)
I still prefer my wording, but this should be sufficiently hard to misinterpret. Get Outlook for Android<https://aka.ms/ghei36> ________________________________ From: Job Snijders <[email protected]> Sent: Friday, March 20, 2020 8:48:51 PM To: Randy Bush <[email protected]> Cc: Ben Maddison <[email protected]>; [email protected] <[email protected]>; [email protected] <[email protected]>; [email protected] <[email protected]>; [email protected] <[email protected]>; [email protected] <[email protected]>; [email protected] <[email protected]> Subject: Re: [Last-Call] [Sidrops] Genart last call review of draft-ietf-sidrops-ov-egress-01 On Fri, Mar 20, 2020 at 11:42:47AM -0700, Randy Bush wrote: > > Having spend the better part of last week stepping a vendor through > > exactly these semantics > > while there is no proof of termination of clue insertion, that a BGP/ROV > *implementor* did not get it, justifies the hack. > > 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 (see [RFC6811] Sec 2) > against the origin Autonomous System number which will actually be > put in the AS_PATH (see [RFC4271] 4.3 Path Attributes:b) of the > UPDATE to the peer. Looks good to me. Kind regards, Job
_______________________________________________ Gen-art mailing list [email protected] https://www.ietf.org/mailman/listinfo/gen-art
