[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