Subject: RE: IDR WG charter

From: "Abarbanel, Benjamin" <[email-masked]>
Date: Tue, 3 Sep 2002 13:39:52 -0400

Russ:
  I totally agree. The working group charter should be to review all new
technical draft proposals with equal merit based on what it offers not based

on whether the working group has time to take on more work. 

At the rate things get done it will be 1-2 years before the old work is
completed
(makes it to RFC status), where does that put us with new fresh ideas?

Ben

> -----Original Message-----
> From: Russ White [mailto:[email-masked]]
> Sent: Tuesday, September 03, 2002 1:27 PM
> To: Yakov Rekhter
> Cc: [email-masked]; [email-masked]
> Subject: Re: IDR WG charter
> 
> 
> 
> Actually, I'd like to modify this response some. I don't really
> understand why the IDR charter has specific drafts listed in this
> way, or if it's necessary. It seems to move the discussion of
> certain drafts from their technical merits, and deployment, to
> one of who can get the most votes on the charter, or cleverness
> in wording the charter a particular way.
> 
> It seems to me that it would be best to avoid making the charter
> a battelground for accepting or not accepting certain work, and
> instead, let that part happen traditionally, by acceptance of the
> draft, and the name change on the draft, as the indicator.
> 
> Or am I completely lost here?
> 
> In those terms, I'd reject until we can understand better about
> what we are trying to do with the charter, and how to handle it.
> 
> :-)
> 
> Russ
> 
> 
> On Tue, 3 Sep 2002, Russ White wrote:
> 
> > 
> > Accept.
> > 
> > :-)
> > 
> > Russ
> > 
> > On Tue, 3 Sep 2002, Yakov Rekhter wrote:
> > 
> > > Folks,
> > > 
> > > So far we received just two e-mail on the subject of the IDR WG
> > > charter proposed by Bill and Alex. The WG chairs would like to get
> > > opinion of the WG members on whether the WG should accept the new
> > > charter, or stay with the existing one.  With this in mind, please
> > > send me an e-mail with either "accept" (means accept the new
> > > charter), or "reject" (means stay with the existing charter). The
> > > deadline is Sep 17.
> > > 
> > > Sue & Yakov.
> > > ------- Forwarded Message
> > > 
> > > Date:    Mon, 26 Aug 2002 07:18:00 -0700
> > > From:    Yakov Rekhter <[email-masked]>
> > > 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
> > > 
> > > 
> > > ------- End of Forwarded Message
> > > 
> > 
> > __________________________________
> > [email-masked] CCIE <>< Grace Alone
> > 
> > 
> > 
> 
> __________________________________
> [email-masked] CCIE <>< Grace Alone
> 
>

---

From: Alex Zinin <[email-masked]>
Date: Wed, 4 Sep 2002 14:59:05 +0200

Ben-

> on whether the working group has time to take on more work.

Let's not confuse technical evaluation with not biting more than
we can chew and prioritizing work.

> (makes it to RFC status), where does that put us with new fresh ideas?

Sometimes we just have to chew and swallow what we've already
bitten to bite a new piece. In the particular case of the base
BGP spec, it is essential to have an accurate protocol
description, otherwise even describing 'fresh ideas' becomes
a problem, not even talking about interoperability.

As far as the delay is concerned--it is totally up to the WG
how fast the work is complete, as the ADs we can promise a fast
turnaround with reviews, so there will not be a unreasonable
delay from our side. We will also make sure the spec goes to
the IESG review as fast as possible. Also note that as soon
as the IESG approves the spec, we'll be happy to take other
documents for review, no need to wait until the RFC editor
is finished with their piece (takes several months now.)

Alex

---

From: Jeffrey Haas <[email-masked]>
Date: Wed, 4 Sep 2002 09:49:58 -0400

> a problem, not even talking about interoperability.

And sometimes getting the parties who have diverged from what has
been published to talk about why they did it can be somewhat
difficult.

Consider, for example (not to pick on them particularly), Cisco's
alteration of the route selection algorithm in their implementation
to account for cluster-list length.  If a particular problem is
being solved, then it probably belongs in the base spec.
One way or the other, it potentially introduces compatability issues.

Then there are things that are in the spec that should be dealt
with, but will generate resistance in doing so.  My favorite example
is atomic aggregate.  No one, to my knowledge, implements it as documented.
Additionally, the reasoning for its existance, seems to be largely
irrelevant in today's Internet. 

(In this particular case, no one seems to have knobs to explicitly
de-aggregate routes where there are overlaps.  We know this breaks
things due to the more specifics generated by deaggregation 
clobbering the covering aggregates.)

While the feature of telling that a given route would have components
that may not follow the as path in the route (especially for policy
purposes), its likely that most of the routes in the Net would have
this property - so thats useless.

The only useful thing it signals in current implementations is that
an aggregate has been synthesized and the as path has been truncated.

Apologies for the AA rant - this is what has occupied my attention
in trying to resolve some last minute MIB isssues. :-|

-- 
Jeff Haas 
NextHop Technologies

---

From: Jeffrey Haas <[email-masked]>
Date: Wed, 4 Sep 2002 09:55:53 -0400

Ben,

> (makes it to RFC status), where does that put us with new fresh ideas?

It shouldn't take that long.  The amount of effort the working group
has expended on debating new drafts would probably have pushed us
to a final draft on bgp if we had used the same effort.

-- 
Jeff Haas 
NextHop Technologies