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 <[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-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 >> [email protected] >> https://www.ietf.org/mailman/listinfo/sidr > > _______________________________________________ > Idr mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/idr
signature.asc
Description: Message signed with OpenPGP using GPGMail
_______________________________________________ sidr mailing list [email protected] https://www.ietf.org/mailman/listinfo/sidr
