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

Reply via email to