IETF Logo Mail Archive

[Sidrops] draft-ymbk-sidrops-ov-clarify-01.txt

Randy Bush <randy@psg.com> Sun, 30 July 2017 00:59 UTC

Return-Path: <randy@psg.com>
X-Original-To: sidrops@ietfa.amsl.com
Delivered-To: sidrops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 24937129AD1 for <sidrops@ietfa.amsl.com>; Sat, 29 Jul 2017 17:59:49 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.002
X-Spam-Level:
X-Spam-Status: No, score=-5.002 tagged_above=-999 required=5 tests=[RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id PcsGvXmTPjgO for <sidrops@ietfa.amsl.com>; Sat, 29 Jul 2017 17:59:47 -0700 (PDT)
Received: from ran.psg.com (ran.psg.com [IPv6:2001:418:8006::18]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 83835131D14 for <sidrops@ietf.org>; Sat, 29 Jul 2017 17:59:47 -0700 (PDT)
Received: from localhost ([127.0.0.1] helo=ryuu.rg.net) by ran.psg.com with esmtp (Exim 4.86_2) (envelope-from <randy@psg.com>) id 1dbca9-0004mH-QJ for sidrops@ietf.org; Sun, 30 Jul 2017 00:59:46 +0000
Date: Sun, 30 Jul 2017 09:59:44 +0900
Message-ID: <m2k22qzqm7.wl-randy@psg.com>
From: Randy Bush <randy@psg.com>
To: sidrops@ietf.org
User-Agent: Wanderlust/2.15.9 (Almost Unreal) Emacs/24.5 Mule/6.0 (HANACHIRUSATO)
MIME-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue")
Content-Type: text/plain; charset="US-ASCII"
Archived-At: <https://mailarchive.ietf.org/arch/msg/sidrops/8pJS7LsNtvE3RYtz46rppA-OJyk>
Subject: [Sidrops] draft-ymbk-sidrops-ov-clarify-01.txt
X-BeenThere: sidrops@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: A list for the SIDR Operations WG <sidrops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/sidrops>, <mailto:sidrops-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/sidrops/>
List-Post: <mailto:sidrops@ietf.org>
List-Help: <mailto:sidrops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/sidrops>, <mailto:sidrops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 30 Jul 2017 00:59:49 -0000

the following has been posted

    From: internet-drafts@ietf.org
    Subject: New Version Notification for draft-ymbk-sidrops-ov-clarify-01.txt
    To: "Randy Bush" <randy@psg.com>
    Date: Sat, 29 Jul 2017 17:56:22 -0700

    A new version of I-D, draft-ymbk-sidrops-ov-clarify-01.txt
    has been successfully submitted by Randy Bush and posted to the
    IETF repository.

    Name:		draft-ymbk-sidrops-ov-clarify
    Revision:	01
    Title:		Origin Validation Clarifications
    Document date:	2017-07-30
    Group:		Individual Submission
    Pages:		4
    URL:            https://www.ietf.org/internet-drafts/draft-ymbk-sidrops-ov-clarify-01.txt
    Status:         https://datatracker.ietf.org/doc/draft-ymbk-sidrops-ov-clarify/
    Htmlized:       https://tools.ietf.org/html/draft-ymbk-sidrops-ov-clarify-01
    Htmlized:       https://datatracker.ietf.org/doc/html/draft-ymbk-sidrops-ov-clarify-01
    Diff:           https://www.ietf.org/rfcdiff?url2=draft-ymbk-sidrops-ov-clarify-01

    Abstract:
       Deployment of RPKI-based BGP origin validation is hampered by, among
       other things, vendor mis-implementations in two critical areas, which
       routes are validated and whether policy is applied when not specified
       by configuration.  This document is meant to clarify possible
       misunderstandings causing those mis-implementations.

this version includes text to cover the AS specification hole noted by
keyur, as follows:

   When redistributing into BGP from connected, static, IGP, iBGP, etc.,
   there is no AS_PATH in the input to allow RPKI validation of the
   originating AS.  In such cases, the router SHOULD use the AS of the
   router's BGP configuration.  If that is ambiguous because of
   confederation, AS migration, or other multi-AS configuration, then
   the router configuration MUST provide a means of specifying the AS to
   be used on the redistribution, either per redistribution or globally.

thanks keyur.

can we please adopt this document and progress it?  thanks.

randy

v2.23.0 | Report a Bug | By Email