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

From: [email-masked]
Date: Mon, 14 Dec 2015 09:05:34 -0800

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Secure Inter-Domain Routing Working Group of the IETF.

        Title           : BGP Prefix Origin Validation State Extended Community
        Authors         : Pradosh Mohapatra
                          Keyur Patel
                          John Scudder
                          Dave Ward
                          Randy Bush
	Filename        : draft-ietf-sidr-origin-validation-signaling-08.txt
	Pages           : 5
	Date            : 2015-12-14

Abstract:
   This document defines a new BGP opaque extended community to carry
   the origination AS validation state inside an autonomous system.
   IBGP speakers that receive this validation state can configure local
   policies allowing it to influence their decision process.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-sidr-origin-validation-signaling/

There's also a htmlized version available at:
https://tools.ietf.org/html/draft-ietf-sidr-origin-validation-signaling-08

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-sidr-origin-validation-signaling-08

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: "John G. Scudder" <[email-masked]>
Date: Mon, 14 Dec 2015 12:09:09 -0500

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:

OLD:
   By default, implementations SHOULD drop the origin validation state
   extended community if received from an EBGP peer, without further
   processing it.  However an implementation MAY be configured to accept
   the community when warranted, for example when the EBGP session is to
   a neighbor AS under control of the same administration.  Similarly,
   an implementation SHOULD NOT send the community to EBGP peers but MAY
   be configured to do so if warranted.

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.

I'm hoping this change will be noncontroversial and we can continue to move forward towards RFC, however I anticipate the respective working group chairs of SIDR and IDR (for obvious reasons I'm recusing myself) may want to have a period to allow people to comment.

Thanks,

--John

> On Dec 14, 2015, at 12:05 PM, [email-masked] wrote:
> 
> 
> _______________________________________________
> sidr mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sidr

---

From: Jeffrey Haas <[email-masked]>
Date: Mon, 14 Dec 2015 12:51:28 -0500

> 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 r…
[...]
> 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 a…

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

---

From: "Acee Lindem (acee)" <[email-masked]>
Date: Tue, 15 Dec 2015 14:08:16 +0000

I support allowing usage over EBGP sessions.
Thanks,
Acee 

On 12/14/15, 12:09 PM, "Idr on behalf of John G. Scudder"
<[email-masked] on behalf of [email-masked]> 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:
>
>OLD:
>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.
>
>I'm hoping this change will be noncontroversial and we can continue to
>move forward towards RFC, however I anticipate the respective working
>group chairs of SIDR and IDR (for obvious reasons I'm recusing myself)
>may want to have a period to allow people to comment.
>
>Thanks,
>
>--John
>
>Idr mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/idr