Re: [sidr] [Idr] I-D Action: draft-ietf-sidr-origin-validation-signaling-08.txt

[Jeffrey Haas <[e-mail]>]

On Mon, Dec 14, 2015 at 12:09:09PM -0500, John G. Scudder wrote:
> Hi Everybody,
> 
> Just when we thought we were completely done with this draft, we were approached by Thomas King who pointed out a use case that can be enabled by validation signaling, which benefits from a minor revision in the language of the draft. Here's the revision:
[...]
> NEW:
>    By default, implementations SHOULD drop the origin validation state
>    extended community if received from an EBGP peer, without further
>    processing it.  Similarly, by default an implementation SHOULD NOT
>    send the community to EBGP peers.  However it SHOULD be possible to
>    configure an implementation to send or accept the community when
>    warranted.  An example of a case where the community would reasonably
>    be received from, or sent to, an EBGP peer is when two adjacent ASes
>    are under control of the same administration.  A second example is
>    documented in [I-D.kklf-sidr-route-server-rpki-light].
> 
> The change does two things. One is to add an informative reference to Thomas's draft. The second is a change in emphasis. Whereas we formerly said that an implementation MAY be configured to send and/or receive the community over EBGP, now we say it SHOULD be possible to configure it to do that.

For what it's worth, I'm highly supportive of this.  (In spite of the fact
that it's going to make me change code...)

We're seeing a generalized trend toward "if your feature says eBGP, you
might relax it in the following circumstances".

Pity confederations never caught on.

-- Jeff