[Idr] IDR WG minutes

Yakov Rekhter <yakov@juniper.net> Tue, 18 July 2006 13:41 UTC

Received: from [] (helo=stiedprmman1.va.neustar.com) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2pp7-0001bE-9J; Tue, 18 Jul 2006 09:41:17 -0400
Received: from [] (helo=ietf-mx.ietf.org) by megatron.ietf.org with esmtp (Exim 4.43) id 1G2pp5-0001XS-5f for idr@ietf.org; Tue, 18 Jul 2006 09:41:15 -0400
Received: from colo-dns-ext1.juniper.net ([]) by ietf-mx.ietf.org with esmtp (Exim 4.43) id 1G2pp3-0001TX-Ol for idr@ietf.org; Tue, 18 Jul 2006 09:41:15 -0400
Received: from merlot.juniper.net (merlot.juniper.net []) by colo-dns-ext1.juniper.net (8.11.3/8.9.3) with ESMTP id k6IDfBX73654 for <idr@ietf.org>; Tue, 18 Jul 2006 06:41:13 -0700 (PDT) (envelope-from yakov@juniper.net)
Received: from juniper.net (sapphire.juniper.net []) by merlot.juniper.net (8.11.3/8.11.3) with ESMTP id k6IDf2g18840 for <idr@ietf.org>; Tue, 18 Jul 2006 06:41:06 -0700 (PDT) (envelope-from yakov@juniper.net)
Message-Id: <200607181341.k6IDf2g18840@merlot.juniper.net>
To: idr@ietf.org
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-ID: <99549.1153230062.1@juniper.net>
Date: Tue, 18 Jul 2006 06:41:02 -0700
From: Yakov Rekhter <yakov@juniper.net>
X-Spam-Score: 0.0 (/)
X-Scan-Signature: 10d3e4e3c32e363f129e380e644649be
Subject: [Idr] IDR WG minutes
X-BeenThere: idr@ietf.org
X-Mailman-Version: 2.1.5
Precedence: list
List-Id: Inter-Domain Routing <idr.ietf.org>
List-Unsubscribe: <https://www1.ietf.org/mailman/listinfo/idr>, <mailto:idr-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www1.ietf.org/pipermail/idr>
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>
Errors-To: idr-bounces@ietf.org


Please review the minutes (attached). If any names have been
misspelled, please send me corrections.

The deadline for review/corrections is July 25, 2006

------- Forwarded Message

Date:    Tue, 11 Jul 2006 13:39:29 -0400
From:    Dave McDysan <dave.mcdysan@verizon.com>
To:      "'Yakov Rekhter'" <yakov@juniper.net>
Subject: Draft idr Meeting Minutes

Yakov - WG/ Document Status Update 
	- See Slides. (To be uploaded to IETF web site?)
draft-ietf-idr-rfc258bis-10.txt (Multiprotocol Extensions)
Graceful Restart Mechanisms 
	- Implemented, interoperable, need to make edits to satisfy IESG
	- Loa? - This is holding up MPLS document. 
	- Yakov - Yes, hopefully revision addresses IESG comments.

Submitted to IESG:

No new progress 
	- list of documents

QoS Support in BGP - Andreas Terzis

Authors made a few updates to presentation on the IETF web site. 
Updated presentation to be posted to the IETF web sie after the meeting.

Preliminary idea. Reason for presentation is to solicit comments &

Zandra pala (?). Is there one set of metrics for each AS? A: Propose a
standard set of metrics.

Larry Dennison: Set of metrics per AS-Path to tag different latencies and
bandwidths. A: QoS metrics need to be updated in the AS as the BGP update
message is propagated.

Tony Tauber: Update is touched multiple times in the AS? A: Performance
needs to be measured. Includes not only inter-domain links, but also the QoS
within the domain. QoS metrics can be dynamic (queuing delay) or static
(e.g., propagation delay). Initally, the plan is to support static metrics.
Would need to extend IGP to support multiple paths across the AS. This has
not been addressed yet. In order to force packet to traverse the advertised
path MPLS could be used.

Sabhi (?): What happens if path goes through route reflector? Normally, a RR
does not modify updates? A: Internal components of the QoS metric could be
updated by the RR bassed upon configuration. In this approach, the RR would
need to update the message. The RR would also need to generate multiple

Sabhi (?): What happens if there are multiple links to the upstream AS? A:
After DPSA, potentially multiple links would be advertised.

Yakov: In order to achieve routing system scalability, a tradeoff is made by
losing information. For example, in BGP to lose much of the IGP information
at the AS boundaries. These are not trivial questions, which have been
attempted to be addressed for the past 15 years. Before getting to specific
coding, the abstraction of information should first be considered.

Discussion on the mailing list is invited.


------- End of Forwarded Message

Idr mailing list