Subject: Re: IDR WG charter

From: Danny McPherson <[email-masked]>
Date: Mon, 26 Aug 2002 09:38:23 -0600

FWIW, I'm working with John and Paul on updating 3065 and 
a new version should be available within a week or so.  I 
believe I've already addressed both of your chief concerns
below, but I'll have another look to verify.  

The terminology use confusion and other mailing list stuff 
has mostly been addressed as well, I believe.

-danny

> I would like to also propose that we add a specific working group item of
> correcting a serious error in RFC 3065 - Autonomous System
> Confederations for BGP - that makes it impossible to implement
> an interoperable implementation, much less a functional one.
> 
> From the RFC:
> :   When a BGP speaker originates a route:
> [...]
> :   c) the originating speaker shall include its own autonomous system in
> :      an AS_SEQUENCE segment of the AS_PATH attribute of all UPDATE
> :      messages sent to BGP speakers located in neighboring autonomous
> :      systems that are not members of the local confederation.  (In this
> :      case, the autonomous system number of the originating speaker's
> :      member confederation will be the only entry in the AS_PATH
> :      attribute).
> 
> the above MUST read "the originating speaker shall include its own
> CONFEDERATION IDENTIFIER" (emphasis added).
> 
> Additionally, I would *like* clarification text added about 
> the receipt of confederation segments by non-confederation members.
> Ambiguities in this behavior were likely responsible for recent
> issues in the Internet.
> 
> Once we get to this point, we can dig out the text from the mailing
> list last time we went around on this.

---

From: "Abarbanel, Benjamin" <[email-masked]>
Date: Mon, 26 Aug 2002 11:44:25 -0400

Yakov and all IDR List Users:

  Is it possible to have two groups active at the same time? 1. The current
group 
which needs to complete active IDR charter tasks as highlighted by Bill
Fenner. 
2. Advance group which wishes to pursue new ideas in improving BGP
technology for
the benefit of the Interdomain Routing across the Internet.

It seems to me that people do not want to entertain new GOOD ideas until
they 
finish old work. This is how we loose momentum in new and hopefully helpfull
technologies that will move us from Point A to Point B. The impact of saying
to someone, we can not accept this draft or idea now because we over booked
with old business tends to discourage further and new creative developments.

If we had a list or a working group for new IDR ideas we could keep the old
work 
and new work from impacting each other. I am sure there are plenty of people
who would not mind persuing this approach if IDR committee agrees to such a
plan.

Thanks in Advance, 
Ben

> -----Original Message-----
> From: Yakov Rekhter [mailto:[email-masked]]
> Sent: Monday, August 26, 2002 10:18 AM
> To: [email-masked]
> Cc: [email-masked]
> Subject: IDR WG charter
> 
> 
> Folks,
> 
> Please comment on the revised charter proposed by Bill and Alex
> (see below). The deadline for comments is Sep 10, 2002.
> 
> Sue & Yakov
> ------- Forwarded Message
> 
> Date:    Thu, 22 Aug 2002 16:11:10 -0700
> From:    Bill Fenner <[email-masked]>
> To:      [email-masked]
> Subject: BGP spec and IDR WG charter
> 
> Dear IDR WG,
> 
>   After some consideration, the Routing Area Directors have decided
> not to forward any IDR documents for IESG consideration until the
> base BGP spec update is finished.[*]  Despite the best efforts of all
> involved, the spec update has been taking an incredible amount of
> time.  We take this step in order to focus all possible resources
> of the WG community on the BGP spec update.
> 
>   This may seem like a negative action.  On the contrary, it is
> meant to support the accomplishment of the working group's goals.[**]
> The milestone for the submission of the BGP4 draft to the IESG
> was scheduled for January 2002.
> 
>   Attached is a proposed update for the IDR working group charter.
> Note that we just made up the dates in the goals and milestones,
> and the WG should come up with realistic ones.
> 
>   Bill and Alex
> 
> [*] "finished" means, in this case, WG consensus, WG Last Call,
> AD Review, IETF Last Call, and IESG approval for publication.
> 
> [**] In further support of the goal of having a quality specification
> that reflects current reality, the ADs have been working on assembling
> a team of reviewers that consists primarily of protocol implementors,
> who have committed their time to examine the spec.  We will be
> sending another message to this list explaining the details of how
> this team will do its work.
> 
> - - - -
> 
> The Inter-Domain Routing Working Group is chartered to standardize
> and promote the Border Gateway Protocol Version 4 (BGP-4) [RFC
> 1771] capable of supporting policy based routing for TCP/IP internets.
> The objective is to promote the use of BGP-4 to support IP version
> 4 and IP version 6. The working group will continue to work on
> improving the scalability of BGP.
> 
> The current tasks of the WG are limited to:
> 
> - - Revise and clarify the base BGP4 document (RFC 1771). Note that
> RFC 1771 no longer documents existing practice and one goal of the
> update is document existing practice. Determine whether the document
> can be advanced as full Standard or needs to recycle at Proposed
> or Draft Standard.
> 
> - - Submit updated MIBs to accompany the revised base BGP4 document.
> 
> Once these tasks are completed, work will progress on the following:
> 
> - - Review and Evaluate Existing RFCs on AS Confederations and Route
> Reflection. If changes are needed, create and advance revisions.
> 
> - - Review RFC 2385 (Protection of BGP via TCP MD5 signature) to see
> if any changes need to be made based on current Internet practice
> or based on the changes to the current bgp draft. If changes are
> needed, create an revision. Issue the WG Last Call on advancing
> the document to Draft Standard.
> 
> - - Produce an updated MIB for AS Confederations, Route Reflection,
> Communities, Multi-Protocol BGP, etc..
> 
> - - Review and evaluate Multiprotocol BGP (RFC 2858) for advancement
> as Draft Standard.
> 
> - - Complete work on an Extended Community Attribute. Develop MIB
> for BGP Extended Communities.
> 
> - - Extend BGP to support a 4-byte AS number, develop plan for
> transitioning to usage of 4-byte AS numbers
> 
> - - Progress along the IETF standards track a BGP-based mechanism
> that allows a BGP speaker to send to its BGP peer a set of route
> filters that the peer would use to constrain/filter its outbound
> routing updates to the speaker. Currently defined in
> draft-ietf-idr-route-filter-03.txt.
> 
> - - Progress along standards track an Outbound Router Filter (ORF)
> type for BGP, that can be used to perform aspath based route
> filtering. The ORF-type will support aspath based route filtering
> as well as regular expression based matching for address groups.
> Currently defined in draft-ietf-idr-aspath-orf-00.txt.
> 
> Tasks for this working group are limited to those listed above;
> new items to be added to the charter must be approved by the IESG.
> 
> Goals and Milestones
> 
> DONE    Submit BGP Capability Advertisement to the IESG
> NOV 02  Submit BGP4 document to IESG.
> DEC 02  Submit updated base BGP4 MIB to IESG.
> MAR 03  Submit extensible BGP MIB to IESG.
> MAR 03  Submit Extended Communities draft to IESG.
> MAR 03  Submit 4-byte AS ID to IESG.
> MAR 03  Initial Draft for RFC2858 (if needed)
> MAR 03  BGP TCP MD5 signatures document to IESG.
> MAR 03  Outbound Route Filter, Prefix and ASpath ORF draft to IESG.
> 
> ------- End of Forwarded Message
>