Hi Wes, I believe -05 should work for you -- we updated it to say 'don't leak across AS boundaries unless configured to do so'. Presumably in your case you would do that configuration.
Thanks, --John > On Jun 14, 2014, at 12:25 AM, George, Wes <wesley.geo...@twcable.com> wrote: > > > On 6/13/14, 5:07 AM, "bruno.decra...@orange.com" > <bruno.decra...@orange.com> wrote: > >> If this is the choosen way, draft-ietf-sidr-origin-validation-signaling >> should also say that: >> - ASBR should remove such community from routes received over eBGP >> sessions (possibly modulo confederation, 2 AS from the same >> organization/trusted...) >> - this community must not be used in the AS until all ASBR are upgraded >> to support draft-ietf-sidr-origin-validation-signaling > > Just wanted to note that as an operator of a network where my Autonomous > System (i.e. The span of the network under common control) spans multiple > Autonomous System NUMBERS, these carve-outs to handle confeds and multiple > ASNs from same org are pretty important if I am to implement Origin > Validation. Being able to validate at external ASBRs and keep that info > across the internal ASN boundaries would make a deployment in networks > like mine much simpler than if we have to revalidate at the internal ASBRs. > > Thanks > Wes George _______________________________________________ sidr mailing list sidr@ietf.org https://www.ietf.org/mailman/listinfo/sidr