Draft minutes of November 18, 2008 rtgwg meeting

"John G. Scudder" <jgs@juniper.net> Thu, 20 November 2008 15:37 UTC

Return-Path: <rtgwg-bounces@ietf.org>
X-Original-To: rtgwg-archive@optimus.ietf.org
Delivered-To: ietfarch-rtgwg-archive@core3.amsl.com
Received: from [127.0.0.1] (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 640273A692F; Thu, 20 Nov 2008 07:37:20 -0800 (PST)
X-Original-To: rtgwg@core3.amsl.com
Delivered-To: rtgwg@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 413893A692F for <rtgwg@core3.amsl.com>; Thu, 20 Nov 2008 07:37:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.022
X-Spam-Level:
X-Spam-Status: No, score=-6.022 tagged_above=-999 required=5 tests=[AWL=-0.023, BAYES_00=-2.599, J_CHICKENPOX_31=0.6, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id c82wQX+-D4Xr for <rtgwg@core3.amsl.com>; Thu, 20 Nov 2008 07:37:18 -0800 (PST)
Received: from exprod7og105.obsmtp.com (exprod7og105.obsmtp.com [64.18.2.163]) by core3.amsl.com (Postfix) with ESMTP id 95B923A683B for <rtgwg@ietf.org>; Thu, 20 Nov 2008 07:37:17 -0800 (PST)
Received: from source ([66.129.228.6]) by exprod7ob105.postini.com ([64.18.6.12]) with SMTP ID DSNKSSWELB+eb9nzQHcG3sWkfWhNvtAcaM+J@postini.com; Thu, 20 Nov 2008 07:37:17 PST
Received: from p-emlb02-sac.jnpr.net ([66.129.254.47]) by p-emsmtp03.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 20 Nov 2008 07:34:21 -0800
Received: from emailsmtp56.jnpr.net ([172.24.60.77]) by p-emlb02-sac.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 20 Nov 2008 07:34:21 -0800
Received: from magenta.juniper.net ([172.17.27.123]) by emailsmtp56.jnpr.net with Microsoft SMTPSVC(6.0.3790.3959); Thu, 20 Nov 2008 07:34:21 -0800
Received: from sa-nc-common3-242.static.jnpr.net (sa-nc-common3-242.static.jnpr.net [172.23.10.242]) by magenta.juniper.net (8.11.3/8.11.3) with ESMTP id mAKFYKM84320 for <rtgwg@ietf.org>; Thu, 20 Nov 2008 07:34:20 -0800 (PST) (envelope-from jgs@juniper.net)
Message-Id: <8DB9DF4A-30B0-416E-8926-567019B787CD@juniper.net>
From: "John G. Scudder" <jgs@juniper.net>
To: rtgwg@ietf.org
Mime-Version: 1.0 (Apple Message framework v929.2)
Subject: Draft minutes of November 18, 2008 rtgwg meeting
Date: Thu, 20 Nov 2008 09:34:19 -0600
X-Mailer: Apple Mail (2.929.2)
X-OriginalArrivalTime: 20 Nov 2008 15:34:21.0403 (UTC) FILETIME=[7580FAB0:01C94B25]
X-BeenThere: rtgwg@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <rtgwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/rtgwg>, <mailto:rtgwg-request@ietf.org?subject=unsubscribe>
List-Archive: <https://www.ietf.org/mailman/private/rtgwg>
List-Post: <mailto:rtgwg@ietf.org>
List-Help: <mailto:rtgwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtgwg>, <mailto:rtgwg-request@ietf.org?subject=subscribe>
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="us-ascii"; Format="flowed"; DelSp="yes"
Sender: rtgwg-bounces@ietf.org
Errors-To: rtgwg-bounces@ietf.org

Please send any corrections.

--John

Routing Area WG (rtgwg)
73rd IETF - Minneapolis, MN

TUESDAY, November 18, 2008     1710-1810 Afternoon Session III
==============================================================


CHAIR(s): Alex Zinin <alex.zinin at alcatel-lucent.com> (not present)
          John Scudder <jgs at juniper.net>
          Alia Atlas <akatlas at gmail.com>

Scribe: Bob Salmi <bsalmi at routingdynamics.com>

existing work item update

    a) expect a last call on the 2 framework drafts after ietf.

    b) progress
           ordered fib draft progressing
           revived is-is extensions draft
           no ospf extensions draft need to investigate this.

    c) longer term
         ipfrr-notvia-addresses

    d) drafts which are on hold pending demand
        ipfrr-ip-mib
        microloop-analysis draft


What things need a home now
-------------------------------

dmitry: propose what about multicast frr should this be part of  
charter update ?

jgs: Mcast frr would be reasonable to add

dward : 1) igp scaling architectural issues
         2) composite transport groups
         (Not clear if there are deliverables now/yet)

Danny: transport layer protecction
                 align with work going on in other groups

Stuart Bryant: you mean layer 4 right

Danny: yes

Dward: some of this may happen in opsec

-----------------------

Loop Free IP fast reroute using Local and remote LFAP's presentation

Extensions needed to local lfap

X-hop neighborhood parameter
   route tables of nodes within X-hop neighborhood are locally  
calculated
   using lsdb and calculation of SPT without exchanging information
   no impact on convergence

failure notification mechanism

How it works
1) receive lsdb from ospf
2) calculate LFAP's
3) verify interfaces via fea
4) on failure send notification via fea & istall lfap's to rib
5) on receipt of fail notification install lFAP's to rib

have implementation using "WISER" emulation tool
Fedora core 8 and XORP

Convergence results in slides

loop free discussion

Comments:

Mike Shand: Are you saying that for unicast you won;t get micro loops ?

yes

Mike      You may get remote loops outside the diameter of
          the repair area

Alia: Inconsistencies in draft regarding how LFA's are computed
      some examples in draft would cause forwarding loops

Alia: Why is the notification not applicable to the IGP.
      I.E. Why not just tune the IGP instead of shorting it.

everything is pre computed so you can just trigger the install

George Swallow: do you need to precompute all the failures for your
                neighbors links as well
yes

George: so that lots of state I have to maintain right.  I have to  
have a
        strategy for all failures

Stewart in a realistic topology is this order k neighbors to the power  
of
         x hops the number for the number of strategies we need to  
precompute
         and store

Stewart: what about competing solutions
         also should look at some of the work with frr tunnels
         what is wrong with an encapsulation based solution

disadvantage is overhead of additional header and processing

jgs: perhaps we should take this discussion offline.

jgs:  2nd or 3rd time this draft has been presented what do you want
      to do with it

jgs: based on room poll we will pass on this work
_______________________________________________
rtgwg mailing list
rtgwg@ietf.org
https://www.ietf.org/mailman/listinfo/rtgwg