RE: [Idr] FW: IDR minutes

"Susan Hares" <shares@nexthop.com> Wed, 03 March 2004 08:03 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 DAA09154 for <idr-archive@ietf.org>; Wed, 3 Mar 2004 03:03:31 -0500 (EST)
Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyRLm-0000al-00 for idr-archive@ietf.org; Wed, 03 Mar 2004 03:03:30 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyRKz-0000P5-00 for idr-archive@ietf.org; Wed, 03 Mar 2004 03:02:42 -0500
Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1AyRJy-00009P-00; Wed, 03 Mar 2004 03:01:39 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyRJa-0000GW-NF; Wed, 03 Mar 2004 03:01:14 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1AyRIz-0000Bb-Se for idr@optimus.ietf.org; Wed, 03 Mar 2004 03:00:42 -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 DAA08495 for <idr@ietf.org>; Wed, 3 Mar 2004 03:00:14 -0500 (EST)
Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1AyRIb-0007XI-00 for idr@ietf.org; Wed, 03 Mar 2004 03:00:13 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1AyRH2-0007BS-00 for idr@ietf.org; Wed, 03 Mar 2004 02:58:37 -0500
Received: from dns.nexthop.com ([65.247.36.216] helo=aa-mx1.nexthop.com) by ietf-mx with esmtp (Exim 4.12) id 1AyRGG-0006zJ-00 for idr@ietf.org; Wed, 03 Mar 2004 02:57:49 -0500
Received: from localhost (localhost [127.0.0.1]) by aa-mx1.nexthop.com (Postfix) with ESMTP id D6CF92D48D0 for <idr@ietf.org>; Wed, 3 Mar 2004 02:57:19 -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 77477-01-7 for <idr@ietf.org>; Wed, 3 Mar 2004 02:57:18 -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 92BB92D4879 for <idr@ietf.org>; Wed, 3 Mar 2004 02:57:17 -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
Subject: RE: [Idr] FW: IDR minutes
Message-ID: <BE36D687C8CBFA4AB76F5CD3E3C0FB4E010CD908@aa-exchange1.corp.nexthop.com>
Thread-Topic: [Idr] FW: IDR minutes
Thread-Index: AcQAv/OALjBfDCc2Rr2faKxgck3z/AAK3dpA
From: Susan Hares <shares@nexthop.com>
To: Sharon Chisholm <schishol@nortelnetworks.com>, idr@ietf.org
X-Virus-Scanned: by amavisd-new at nexthop.com
Content-Transfer-Encoding: quoted-printable
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: Wed, 03 Mar 2004 02:57:17 -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

we'll add that.  We certainly did
talk about that!


sue

-----Original Message-----
From: Sharon Chisholm [mailto:schishol@nortelnetworks.com]
Sent: Tuesday, March 02, 2004 8:31 PM
To: idr@ietf.org
Subject: RE: [Idr] FW: IDR minutes


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 consistency
			issue between two places...  May not be an issue for
			a single selection point.

			Introduction of new step will effect current
			deployment 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 behavior.

	- Alex:		Will this be applicable to only situations where
			there is a problem?


	- Yakov:	Is this an implementation method?

	- Alex:		Is this informational or standards-track?

	- Enke:		Either is fine

	- 		It can't be a local matter because it must be
			consistent throughout the entire system

	- Enke:		Decision on redistributed routes is made locally in
			each router

	-		Behavior 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 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 mailing list
Idr@ietf.org
https://www1.ietf.org/mailman/listinfo/idr