[Idr] FW: IDR minutes
"Susan Hares" <shares@nexthop.com> Tue, 02 March 2004 03:45 UTC
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA26855 for <idr-archive@ietf.org>; Mon, 1 Mar 2004 22:45:11 -0500 (EST)
Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ay0qF-0000nO-00 for idr-archive@ietf.org; Mon, 01 Mar 2004 22:45:11 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ay0pE-0000eO-00 for idr-archive@ietf.org; Mon, 01 Mar 2004 22:44:09 -0500
Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1Ay0oK-0000Xb-00; Mon, 01 Mar 2004 22:43:12 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ay0o9-0002qb-Cj; Mon, 01 Mar 2004 22:43:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1Ay0nL-0002pd-Mz for idr@optimus.ietf.org; Mon, 01 Mar 2004 22:42:11 -0500
Received: from ietf-mx (ietf-mx.ietf.org [132.151.6.1]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id WAA26811 for <idr@ietf.org>; Mon, 1 Mar 2004 22:42:08 -0500 (EST)
Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1Ay0nI-0000RS-00 for idr@ietf.org; Mon, 01 Mar 2004 22:42:08 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1Ay0mQ-0000M7-00 for idr@ietf.org; Mon, 01 Mar 2004 22:41:15 -0500
Received: from dns.nexthop.com ([65.247.36.216] helo=aa-mx1.nexthop.com) by ietf-mx with esmtp (Exim 4.12) id 1Ay0m6-0000GM-00 for idr@ietf.org; Mon, 01 Mar 2004 22:40:54 -0500
Received: from localhost (localhost [127.0.0.1]) by aa-mx1.nexthop.com (Postfix) with ESMTP id CF2232D493F for <idr@ietf.org>; Mon, 1 Mar 2004 22:40:24 -0500 (EST)
Received: from aa-mx1.nexthop.com ([127.0.0.1]) by localhost (aa-mx1.nexthop.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 45584-03-17 for <idr@ietf.org>; Mon, 1 Mar 2004 22:40:23 -0500 (EST)
Received: from mail.corp.nexthop.com (aa-exchange1.corp.nexthop.com [65.247.36.233]) by aa-mx1.nexthop.com (Postfix) with ESMTP id 7D4BE2D4932 for <idr@ietf.org>; Mon, 1 Mar 2004 22:40:23 -0500 (EST)
X-MimeOLE: Produced By Microsoft Exchange V6.0.6249.0
content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
Message-ID: <BE36D687C8CBFA4AB76F5CD3E3C0FB4E010CD8E3@aa-exchange1.corp.nexthop.com>
Thread-Topic: IDR minutes
Thread-Index: AcP/ZbUR5OkElLH7TN2Bea6gcoa+eQAjb2yw
From: Susan Hares <shares@nexthop.com>
To: idr@ietf.org
X-Virus-Scanned: by amavisd-new at nexthop.com
Content-Transfer-Encoding: quoted-printable
Subject: [Idr] FW: IDR minutes
Sender: idr-admin@ietf.org
Errors-To: idr-admin@ietf.org
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.0.12
Precedence: bulk
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Post: <mailto:idr@ietf.org>
List-Help: <mailto:idr-request@ietf.org?subject=help>
List-Subscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=subscribe>
List-Archive: <https://www1.ietf.org/mail-archive/working-groups/idr/>
Date: Mon, 01 Mar 2004 22:40:23 -0500
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org
X-Spam-Status: No, hits=0.0 required=5.0 tests=AWL autolearn=no version=2.60
Content-Transfer-Encoding: quoted-printable
Minutes for 3/1/04 session -----Original Message----- From: Jake Khuon Sent: Monday, March 01, 2004 3:18 AM To: Susan Hares; yakov@juniper.net Subject: IDR minutes Inter-Domain Routing WG (idr) Monday, March 1 at 1530-1730 ================================== CHAIRS: Sue Hares (skh@nexthop.com) Yakov Rekhter (yakov@juniper.net) AGENDA: 1) Agenda Bashing Agenda Slides 2) Document status [5 minutes] - Bundle went to IESG BGP-4 draft-23 draft-ietf-idr-bgp4-23.txt BGP-4 V1 MIB draft-ietf-idr-bgp4-mib-13.txt BGP-4 Protocol Analysis draft-ietf-idr-bgp-analysis-04.txt BGP Security Vulnerabilities Analysis draft-ietf-idr-bgp-vuln-00.txt Experience with the BGP-4 Protocol draft-ietf-idr-bgp4-experience-protocol-03.txt BGP 4 Implementation Report draft-ietf-idr-bgp-implementation-00.txt BGP-4 V1 MIB implementation report draft-ietf-idr-bgp-mibagent-survey-01.txt Presentation 3) Implementation Reports and FSM issues for current drafts [10 minutes] document: None, presentation only Presentation Sue Hares - Yakov: route-reflector update status? - Enke: route-reflector update (4 weeks) - Enke: prefix-orf was not added to charter - Sue: yes it was added, administrative error in listing 4) BGP Peer Restart Backoff Mechanisms [10 minutes] document: draft-hares-bgp-backoff-01.txt (ietf) (-02 Update) Author: Susan Hares Presentation Sue Hares - Alex: draft should say informational achieve functionality using existing states? - Sue: no... can't use existing states; already investigated that option 5) Deterministic Route Redistribution into BGP [10 minutes] document: draft-chen-bgp-redist-00.txt Authors: Jenny Yuan, Enke Chen Enke Chen - Andrew Lang: used to use configured localpref tweaking; not management intensive... unsure if this is needed - Enke: timing dependent non-deterministic problem so current knobs cannot be used reliably; does not break anything... backwards compatible - Andrew Lang: better to educate people about localpref - Barry Friedman: lacks generality too narrow a problem space... only addresses RIP/iBGP interaction - Enke: tweaking of admin distance defines a baseline - need per route granularity to solve for all cases? Possibility of adding more configuration conflicts. - Alex: this problem only occurs if there's a consistancy issue between two places... May not be an issue for a single selection point. Introduction of new step will effect current edployment traffic selection? - Enke: This will happen regardless. Should not effect current deployments and if there's a change, the change will be for the better. - By definition, it does change behaviour. - Alex: Will this be applicable to only situations where there is a problem? - Yakov: Is this an implimentation method? - Alex: Is this informational or standards-track? - Enke: Either is fine - It can't be a local matter because it must be consistant throughout the entire system - Enke: Decision on redistributed routes is made locally in each router - Behaviour is changed because new code now uses admin distance over localpref? - Enke: If only localpref is used then things should not change - Cengiz: If route-reflector is used? - Enke: I need to think about it further 6) BGP based auto-discovery [Sue Hares, P. Unbehagen] [10 minutes] document: draft-hlmu-l2vpn-bgp-discovery-00.txt authors: P. Unbehagen, P. Muley, V. Radoaca, Susan Hares Presentation Sue Hares, P. Unbehagen - Already a L2VPN draft that addresses this in a defined NLRI with label information - Paul: This draft is meant to provide LDP pseudowire config information - Other spec can do same thing [autodiscovery] without label information - Kireeti: Would like to be able to use this AFI with different SAFI [65] and NLRI format - Would the two SAFIs be solving similar problems - Kireeti: My SAFI solves different problems 7) BGP Assignment of AFI/SAFI address [10 minutes] Document: draft-hares-bgp-assign-afisafi-00.txt Author: Susan Hares Presentation Sue Hares 8) BGP Attribute Codes and Suggested Procedures Document: draft-kompella-zinin-early-allocation-00.txt Author: Alex Zinin, Kireeti Kompella Presentation Alex Zinin - Sharon: talking about protocols and not OIDs preallocation? bad to preallocate in the MIB... different from what other WGs; exclude MIB OIDs - Kireeti: not suggesting that everyone use this - It would have been nicer to have had OIDs preallocated so as not to reimpliment the MIB - Sharon: OIDs not allocated to drafts because if the drafts goes away then you've wasted numbers - Lou Berger: allocation with 1 year with 1 renewal is too short; alterntate policy: as long as draft or version is alive, expire in 3 to 6 months - Alex: that suggestion ties validity with ability of author to submit the draft; suggestion: once document is submitted to IESG then we freeze. Don't want to allocate codepoints too early. - Dave Meyer: Are you sure that IANA can time anything out - Alex: No - Dave Meyer: WG chair needs to manage this? - What happens if the allocation is not renewed and code is using it still? - Alex: Add provision to document to deprecate but not return - Kireeti: Deprecate for a period of time to give people time to remove. Formal process to do early allocations and if it goes through then stick with it but if it doesn't go through then people must take this out. - Dino: Allocate experimental codepoints and once standardised, then adopt standard codepoint for sending but accept both. - Sue: Good for SAFIs as well as AFIs? - Dino: All well known IANA values - Fenner: RFC already documents a process for transitioning codepoints 9) Charter Discussion [20 minutes] Thanks to all implementers who send in reports on the the base specification, we will be opening the charter. This section of the meeting will discuss what items will be added to the charter. Presentation - Top three most important; maybe ECMP little higher than Fault Isolation -- /*==================[ Jake Khuon <khuon@NextHop.COM> ]=====================+ | Field App. Engineer http://www.nexthop.com/ /\ /~ E X T H O P | | Ofc: +1 (425) 391-2262 Fax: +1 (425) 391-6772 / \/ Technologies, Inc.| +==========[ 1911 Landings Drive, Mountain View, CA 94043 USA ]===========*/ _______________________________________________ Idr mailing list Idr@ietf.org https://www1.ietf.org/mailman/listinfo/idr
- [Idr] FW: IDR minutes Susan Hares
- RE: [Idr] FW: IDR minutes Sharon Chisholm
- RE: [Idr] FW: IDR minutes Susan Hares
- Re: [Idr] FW: IDR minutes Alex Zinin