Re: [Idr] FW: IDR minutes

Alex Zinin <zinin@psg.com> Tue, 09 March 2004 23:18 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 SAA06488 for <idr-archive@ietf.org>; Tue, 9 Mar 2004 18:18:59 -0500 (EST)
Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B0qV2-0000cy-00 for idr-archive@ietf.org; Tue, 09 Mar 2004 18:19:00 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B0qU6-0000Tj-00 for idr-archive@ietf.org; Tue, 09 Mar 2004 18:18:03 -0500
Received: from optimus.ietf.org ([132.151.1.19]) by ietf-mx with esmtp (Exim 4.12) id 1B0qTg-0000KN-00; Tue, 09 Mar 2004 18:17:36 -0500
Received: from localhost.localdomain ([127.0.0.1] helo=www1.ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0qT7-0000y1-LN; Tue, 09 Mar 2004 18:17:01 -0500
Received: from odin.ietf.org ([132.151.1.176] helo=ietf.org) by optimus.ietf.org with esmtp (Exim 4.20) id 1B0qSN-0000nK-1i for idr@optimus.ietf.org; Tue, 09 Mar 2004 18:16:15 -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 SAA06217 for <idr@ietf.org>; Tue, 9 Mar 2004 18:16:10 -0500 (EST)
Received: from ietf-mx ([132.151.6.1]) by ietf-mx with esmtp (Exim 4.12) id 1B0qSK-0000At-00 for idr@ietf.org; Tue, 09 Mar 2004 18:16:12 -0500
Received: from exim by ietf-mx with spam-scanned (Exim 4.12) id 1B0qRK-00000m-00 for idr@ietf.org; Tue, 09 Mar 2004 18:15:11 -0500
Received: from psg.com ([147.28.0.62] ident=mailnull) by ietf-mx with esmtp (Exim 4.12) id 1B0qQR-0007ex-00 for idr@ietf.org; Tue, 09 Mar 2004 18:14:15 -0500
Received: from [147.28.0.62] (helo=127.0.0.1) by psg.com with esmtp (Exim 4.30; FreeBSD) id 1B0qQR-0008Wb-RW; Tue, 09 Mar 2004 23:14:15 +0000
From: Alex Zinin <zinin@psg.com>
X-Mailer: The Bat! (v1.62i) Personal
Reply-To: Alex Zinin <zinin@psg.com>
X-Priority: 3 (Normal)
Message-ID: <22240253766.20040309151326@psg.com>
To: Susan Hares <shares@nexthop.com>
CC: idr@ietf.org
Subject: Re: [Idr] FW: IDR minutes
In-Reply-To: <BE36D687C8CBFA4AB76F5CD3E3C0FB4E010CD8E3@aa-exchange1.corp.nexthop.com>
References: <BE36D687C8CBFA4AB76F5CD3E3C0FB4E010CD8E3@aa-exchange1.corp.nexthop.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
Content-Transfer-Encoding: 7bit
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, 09 Mar 2004 15:13:26 -0800
X-Spam-Checker-Version: SpamAssassin 2.60 (1.212-2003-09-23-exp) on ietf-mx.ietf.org
X-Spam-Status: No, hits=0.3 required=5.0 tests=AWL,RCVD_NUMERIC_HELO autolearn=no version=2.60
Content-Transfer-Encoding: 7bit

Sue-

Some corrections below, please.

Monday, March 1, 2004, 7:40:23 PM, Susan Hares wrote:
[...]
> 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

Change to "the draft says it's an RFC, shouldn't do that"

>                         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.

Change to:

the problem occurs if a router has to select best routes in two places: as in
the draft--once in BGP and once in the routing table, and the decisions are not
consistent. wonder if the problem still exists if an implementation selects best
paths in one place only, e.g. gated?. if so, is the problem
implementation-specific, not to mean it shouldn't resolved. Alex sent an e-mail
to the list with more details.


> 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

Change to:
No, that's why the drafts asks the WG chairs to keep track of the timers.

>         - Dave Meyer:   WG chair needs to manage this?

I think Dave asked if the WG chairs will need to maintain their own, parallel
registry to maintain this.

Alex: if IANA registry includes all info necessary, such as time of allocation,
responsible WG, etc., then it should be a matter of periodically looking through
the IANA registries.

>         -               What happens if the allocation is not renewed and
>                         code is using it still?

>         - Alex:         Add provision to document to deprecate but not return

Change to: the document allows 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


Thanks.
Alex


_______________________________________________
Idr mailing list
Idr@ietf.org
https://www1.ietf.org/mailman/listinfo/idr