>> in bgpsec, all ass sign. end.
>
> Quoting from the sidr-bgpsec-ops-05 document:
> "To prevent exposure of the internals of BGP Confederations [RFC5065],
>a BGPsec speaker which is a Member-AS of a Confederation MUST NOT
>sign updates sent to another Member-AS of the same Confederation.
Comments below.
Sriram
>
>> This solution for confeds *requires* each AS within a confed to sign
>> internally (i.e., from AS to AS within the confed). It does not allow
>> the choice to a confed operator to sign or not sign the updates internally.
>> For instance, the operator may be satisfied w
> This solution for confeds *requires* each AS within a confed to sign
> internally
> (i.e., from AS to AS within the confed). It does not allow the choice to
> a confed operator to sign or not sign the updates internally.
> For instance, the operator may be satisfied with the level of mutual t
Original Message-
From: sidr-boun...@ietf.org [mailto:sidr-boun...@ietf.org] On Behalf Of Matt
Lepinski
Sent: Friday, June 15, 2012 3:09 PM
To: sidr@ietf.org
Subject: [sidr] Follow-up on June 6 Interim : Confederations
We had significant discussion at the June 6 Interim on the topic of support
-BGPSEC peer.
Sriram
>-Original Message-
>From: sidr-boun...@ietf.org [mailto:sidr-boun...@ietf.org] On Behalf Of Matt
>Lepinski
>Sent: Friday, June 15, 2012 3:09 PM
>To: sidr@ietf.org
>Subject: [sidr] Follow-up on June 6 Interim : Confederations
>
>We had significan
We had significant discussion at the June 6 Interim on the topic of
supporting confederation in BGPSEC without an AS-Path attribute.
My understanding was that at the interim there was some consensus for
the following confederation solution (but this consensus has not yet
been discussed/confirm
