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 <j...@ntt.net> Sent: Friday, March 20, 2020 8:48:51 PM To: Randy Bush <ra...@psg.com> Cc: Ben Maddison <benm@workonline.africa>; ke...@arrcus.com <ke...@arrcus.com>; sidr...@ietf.org <sidr...@ietf.org>; draft-ietf-sidrops-ov-egress....@ietf.org <draft-ietf-sidrops-ov-egress....@ietf.org>; last-c...@ietf.org <last-c...@ietf.org>; gen-art@ietf.org <gen-art@ietf.org>; rjspa...@nostrum.com <rjspa...@nostrum.com> 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 Gen-art@ietf.org https://www.ietf.org/mailman/listinfo/gen-art
