I support allowing usage over EBGP sessions. Thanks, Acee On 12/14/15, 12:09 PM, "Idr on behalf of John G. Scudder" <[email protected] on behalf of [email protected]> 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: > 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 protected] wrote: >> >> >> 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-signal >>ing/ >> >> There's also a htmlized version available at: >> >>https://tools.ietf.org/html/draft-ietf-sidr-origin-validation-signaling-0 >>8 >> >> A diff from the previous version is available at: >> >>https://www.ietf.org/rfcdiff?url2=draft-ietf-sidr-origin-validation-signa >>ling-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/ >> >> _______________________________________________ >> sidr mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/sidr > >_______________________________________________ >Idr mailing list >[email protected] >https://www.ietf.org/mailman/listinfo/idr _______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
