[I2rs-proto-dt] Action items from last week
"Susan Hares" <shares@ndzh.com> Thu, 27 August 2015 19:59 UTC
Return-Path: <shares@ndzh.com>
X-Original-To: i2rs-proto-dt@ietfa.amsl.com
Delivered-To: i2rs-proto-dt@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 949071A9148 for <i2rs-proto-dt@ietfa.amsl.com>; Thu, 27 Aug 2015 12:59:13 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -95.507
X-Spam-Level:
X-Spam-Status: No, score=-95.507 tagged_above=-999 required=5 tests=[BAYES_40=-0.001, DOS_OUTLOOK_TO_MX=2.845, FRT_TODAY2=1.648, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100] autolearn=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 0gKPRukV7Yxs for <i2rs-proto-dt@ietfa.amsl.com>; Thu, 27 Aug 2015 12:59:10 -0700 (PDT)
Received: from hickoryhill-consulting.com (hhc-web3.hickoryhill-consulting.com [64.9.205.143]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E752A1A8951 for <i2rs-proto-dt@ietf.org>; Thu, 27 Aug 2015 12:59:09 -0700 (PDT)
X-Default-Received-SPF: pass (skip=loggedin (res=PASS)) x-ip-name=174.124.171.7;
From: Susan Hares <shares@ndzh.com>
To: i2rs-proto-dt@ietf.org
Date: Thu, 27 Aug 2015 15:59:05 -0400
Message-ID: <017001d0e102$d4298760$7c7c9620$@ndzh.com>
MIME-Version: 1.0
Content-Type: multipart/alternative; boundary="----=_NextPart_000_0171_01D0E0E1.4D1F8880"
X-Mailer: Microsoft Outlook 14.0
Thread-Index: AdDg7Mpygc6Jee1zQyWiTQT26bDnJw==
Content-Language: en-us
X-Authenticated-User: skh@ndzh.com
X-IsFriend: <shares@ndzh.com>
Archived-At: <http://mailarchive.ietf.org/arch/msg/i2rs-proto-dt/4khzNhrXNMq7K2GFdM5iTzn37cY>
Cc: shares@ndzh.com
Subject: [I2rs-proto-dt] Action items from last week
X-BeenThere: i2rs-proto-dt@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: I2RS protocol design team <i2rs-proto-dt.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/i2rs-proto-dt>, <mailto:i2rs-proto-dt-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/i2rs-proto-dt/>
List-Post: <mailto:i2rs-proto-dt@ietf.org>
List-Help: <mailto:i2rs-proto-dt-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/i2rs-proto-dt>, <mailto:i2rs-proto-dt-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 27 Aug 2015 19:59:13 -0000
Hi all: Here's the action items from last week: . mail-list for the design team and a wiki for comments on design documents status: [i2rs-proto-dt@ietf.org] is a private list with member-only posting. Try it out todasy Question: Do you want a public or a private Wiki? I can link a public wiki off I2RS web page. . Sue will send to the list the examples of ephemeral to operational state, ephemeral to configuration, and ephemeral to ephemeral on the mail list and Wiki Status: Reposted bgp use case examples which have 16 use cases. https://datatracker.ietf.org/doc/draft-keyupate-idr-i2rs-bgp-usecases/ These use cases were developed early in I2RS use. These use cases have all pieces: ephemeral to operational state (Ephemeral monitor to BGP operational state), Ephemeral to configuration - I2RS BGP RIB configuration of route with cost community to be sent to BGP Peer must confirm that Peer exists. Ephemeral to Ephemeral - I2RS BGP modules extends I2RS RIB module (by setting cost community). I will walk through all these cases tomorrow if you are interested. . We will focus on two ideas as being key and other requirements being fluid o Feedback look for applications, o Being able to tie ephemeral to config ======================================== Example of Ephemeral state referring to operational state: . I2RS referring to MPLS LSP in order to create a tunnel for the I2RS RIB (see page 10 of the I2RS RIB in the tunnel-encap) . I2RS BGP requirements for monitoring BGP operational state are in the following document: https://datatracker.ietf.org/doc/draft-keyupate-idr-i2rs-bgp-usecases/ I've described the first two of these BGP use cases below as examples of ephemeral state referring to operational state/ BGP-REQ01: I2RS client/agent exchange SHOULD support the read, write and quick notification of status of the BGP peer operational State on each router within a given Autonomous System (AS). This operational status includes the quick notification of protocol events that proceed a destructive tear-down of BGP session. Note: This will require the ability of the I2RS agent to monitor the following operational state, and publish this state via pub/sub: 1. Increase in number of NOTIFICATONs per BGP (send/receive) 2. Count in number of total paths and prefixes - to see this count heading toward a maximum prefix or maximum paths per Peer or per box. 3. Change in state away from ESTABLISHED Example Yang for this operational state that augments BGP neighbor configuration state. augment /bgp/neighbors/neighbor/state { description "Augmentation to add operational state related to a particular BGP neighbor"; uses bgp-op:bgp-neighbor_state; } BGP-REQ02: I2RS client SHOULD be able to push BGP routes with custom cost communities to specific I2RS agents on BGP routers for insertion in specific BGP Peer(s) to aid Traffic engineering of data paths. These routes SHOULD be tracked by the I2RS Agent as specific BGP routes with customer cost communities. These routes installed via the RIB-Info. . This requirement implies that I2RS RIB route need to ip-attributes with BGP flag, and cost community attribute +--rw route-attributes | +--rw route-preference uint32 | +--rw local-only boolean | +--rw address-family-route-attributes | +--rw (route-type)? | +--:(ip-route-attributes) | +--:(mpls-route-attributes) | +--:(ethernet-route-attributes) Possible structure Augments i2rs-rib/rib-list/route-list/route-attributes +--rw bgp +--rw bgp-peer +--rw bgp-attributes +--rw cost-community
- [I2rs-proto-dt] Action items from last week Susan Hares