RE: [Idr] FW: IDR minutes
"Sharon Chisholm" <schishol@nortelnetworks.com> Wed, 03 March 2004 01:38 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 UAA18855 for <idr-archive@ietf.org>; Tue, 2 Mar 2004 20:38:02 -0500 (EST)
Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyLKk-0000ae-00 for idr-archive@ietf.org; Tue, 02 Mar 2004 20:38:02 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyLK0-0000Rd-00 for idr-archive@ietf.org; Tue, 02 Mar 2004 20:37:17 -0500
Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AyLJ3-0000HC-00; Tue, 02 Mar 2004 20:36:17 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyLHs-0001YS-EE; Tue, 02 Mar 2004 20:35:04 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyLGz-0001SD-SL for idr@optimus.ietf.org; Tue, 02 Mar 2004 20:34:09 -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 UAA18462 for <idr@ietf.org>; Tue, 2 Mar 2004 20:34:07 -0500 (EST)
Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyLGx-0007lq-00 for idr@ietf.org; Tue, 02 Mar 2004 20:34:07 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyLGD-0007Zf-00 for idr@ietf.org; Tue, 02 Mar 2004 20:33:22 -0500
Received: from zcars04f.nortelnetworks.com ([47.129.242.57]) by ietf-mx with esmtp (Exim 4.12) id 1AyLEl-00074K-00 for idr@ietf.org; Tue, 02 Mar 2004 20:31:51 -0500
Received: from zcard309.ca.nortel.com (zcard309.ca.nortel.com [47.129.242.69]) by zcars04f.nortelnetworks.com (Switch-2.2.6/Switch-2.2.0) with ESMTP id i231VFi13770 for <idr@ietf.org>; Tue, 2 Mar 2004 20:31:15 -0500 (EST)
Received: by zcard309.ca.nortel.com with Internet Mail Service (5.5.2653.19) id <FS3DBZ3N>; Tue, 2 Mar 2004 20:31:15 -0500
Message-ID: <3549C09B853DD5119B540002A52CDD340A5AECCB@zcard0ka.ca.nortel.com>
From: Sharon Chisholm <schishol@nortelnetworks.com>
To: idr@ietf.org
Subject: RE: [Idr] FW: IDR minutes
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: text/plain
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: Tue, 02 Mar 2004 20:31:14 -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
hi I believe we also briefly discussed setting up a call to discuss the v2 MIB and that interested parties should contact either Sue or myself. Sharon -----Original Message----- From: Susan Hares [mailto:shares@nexthop.com] Sent: Monday, March 01, 2004 10:40 PM To: idr@ietf.org Subject: [Idr] FW: IDR minutes 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 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