[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