Subject: RE: BGP spec and IDR WG charter

From: "Natale, Jonathan" <[email-masked]>
Date: Fri, 23 Aug 2002 09:26:22 -0400

I am sorry, but I disagree with:
    "DONE    Submit BGP Capability Advertisement to the IESG"
 and AGAIN ( for the last time) I propose:

>    "If a BGP speaker that supports a certain capability determines that
>    its peer doesn't support this capability, the speaker MAY send a
>    NOTIFICATION message to the peer, and terminate peering (see Section
>    "Extensions to Error Handling" for more details). The Error Subcode
>    in the message is set to Unsupported Capability. The message SHOULD
>    contain the capability (capabilities) that causes the speaker to send
>    the message.  The decision to send the message and terminate peering
>    is local to the speaker. If terminated, such peering SHOULD NOT be
>    re-established automatically."
>
>be changed to:
>
>    "If a BGP speaker that **does not want its peer to support** a certain
>    capability determines that
>    its peer **does** support this capability, the speaker MAY send a
>    NOTIFICATION message to the peer, and terminate peering (see Section
>    "Extensions to Error Handling" for more details). The Error Subcode
>    in the message is set to Unsupported Capability. The message SHOULD
>    contain the capability (capabilities) that causes the speaker to send
>    the message.  The decision to send the message and terminate peering
>    is local to the speaker. **If terminated, the peer MAY re-open the
>    connection without the offending capability-this is known as capability
>    negotiation.**"

Thank you.

-----Original Message-----
From: Bill Fenner [mailto:[email-masked]] 
Sent: Thursday, August 22, 2002 7:11 PM
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.

---

From: Yakov Rekhter <[email-masked]>
Date: Fri, 23 Aug 2002 07:18:17 -0700

Jonathan,

>     "DONE    Submit BGP Capability Advertisement to the IESG"

The "DONE submit BGP Capability Advertisement to the IESG" just
documents the *fact*, that BGP Capability Advertisement was submitted 
to the IESG back in Spring of 2002, and was approved by the IESG
in May 2002 for publication as a Draft Standard.

> >    connection without the offending capability-this is known as capability

Yakov.