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

[Sandra Murphy <[e-mail]>]

There being no complaint from sidr about this post-wglc change, and the idr review also being judged as successful, the wg consensus is judged to support publication of this version of the draft.

A publication request will be issued shortly.

—Sandy, speaking as wg co-chair

On Dec 14, 2015, at 12:09 PM, John G. Scudder <[e-mail]> 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, [e-mail] 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-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/
>> 
>> _______________________________________________
>> sidr mailing list
>> [e-mail]
>> https://www.ietf.org/mailman/listinfo/sidr
> 
> _______________________________________________
> Idr mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/idr