Subject: Re: draft-15 comments
From: Dan Pei <[email-masked]>
To: Yakov Rekhter <[email-masked]>
Cc: Jeffrey Haas <[email-masked]>, <[email-masked]>
Date: Wed, 31 Oct 2001 19:15:02 -0800 (PST)

> > : 9. UPDATE Message Handling
> >
> > [...]
> >
> > :    iii) If the new route has identical path attributes to an earlier
> > :    route contained in the Adj-RIB-In, and is more specific (see 9.1.4)
> > :    than the earlier route, no further actions are necessary.
> >
> > Then how is it going to end up in LocRib and thus to Adj-Ribs-Out?
> >
> > :    v) If the new route is an overlapping route that is less specific
> > :    (see 9.1.4) than an earlier route contained in the Adj-RIB-In, the
> > :    BGP speaker shall run its Decision Process on the set of destinations
> > :    described only by the less specific route.
> >
> > How do we run decision on only the uncovered components?
...
>
> Please propose the appropriate text that addresses your comments
> on Section 9.

My conjecture is that the draft actually requires taking these
actions(i-iv) in some implicit order.

BTW, It's clear that i) - v) are specifying whether to run Decision
Process, and the set of destinations to run Decision Process on. However,
only v) specifies the set of destinations to run Decision Process on.

Maybe we could make the conditions of these actions mutual
exclusive by(if it is right:-):

        -First deal with the NLRI in the new route itself, run decision
         process on this NLRI
                -if exists in Adj-RIB-In, then replace it,
                -otherwise, add it into Adj-RIB-In

        -Then deal with overlapping NLRI' that is already in Adj-RIB-In
                -if NLRI is more specific than NLRI', but same attributes,
                 no action

                -if NLRI is more specific than NLRI', but different
                attributes, run decision on (NLRI' - NLRI)?

                -if NLRI is less specific than NLRI', but different
                attributes,run decision on (NLRI - NLRI')?

                -if NLRI is less specific than NLRI', but same attributes,
                , no action.

If this is right, we can modify the draft text accordingly.

Thanks,

---
Dan

To: Jeffrey Haas <[email-masked]>
Cc: [email-masked]
Subject: Re: draft-15 comments 
Date: Wed, 31 Oct 2001 16:38:36 -0800
From: Yakov Rekhter <[email-masked]>
Sender: [email-masked]

Jeff,

> Comments on -15
> 
> :    not require periodic refresh of the routing table. Therefore, A BGP
> 
> "Therefore, _a_"

fixed.

> 
> :    KEEPALIVE messages are sent periodically to ensure the liveness of
> 
> "messages _may_ be sent"

fixed.

> There are several situations where you do not have to send them.
> 
> : 4.1 Message Header Format
> 
> [...]
> 
> :          Otherwise, the value of the marker can be predicted by some a
> :          computation specified as part of the authentication mechanism
> :          (which is specified as part of the Authentication Information)
> :          used.
> 
> Pullup from Section 6.1
> 
> "The Marker field should be all ones if the OPEN messages carried
> no authentication information."

what is exactly the problem here ?

> :    present in the Loc-RIB, and the next hop for each of these routes
> :    must be present in the local BGP speaker's Routing Table.  Routes
> 
> "next hop for each of these routes must be resolvable via the
> local BGP speaker's Routing Table."
> 
> The previous wording implied that a host entry for the BGP nexthop
> would be present in the Routing Table.

fixed.

> 
> : 4.2 OPEN Message Format
> 
> [...]
> 
> :        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> :        |                                                               |
> :        |                       Optional Parameters                     |
> :        |                                                               |
> :        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> 
> Insert "(variable)".

fixed.

> 
> : 4.3 UPDATE Message Format
> 
> [...]
> 
> :    An UPDATE message is used to advertise a single feasible route to a
> :    peer, or to withdraw multiple unfeasible routes from service (see
> :    3.1). An UPDATE message may simultaneously advertise a feasible route
> 
> "advertise feasible routes sharing common path attributes"
> 
> Without this, we imply that you send one destination in 3.1 and later
> we send multiple destinations.

Bear in mind that "the destination is the systems whose IP
addresses are reported in the Network Layer Reachability Information
(NLRI) field", and the NLRI field could contain one or more prefixes.

With this in mind, what is exactly the problem ?

> :    and withdraw multiple unfeasible routes from service. The UPDATE
> :    message always includes the fixed-size BGP header, and also includes
> :    the other fields as shown below (note, some of the shown fields may
> :    not be present in every UPDATE message):
> 
> 
> [Section 5]
> :    The mandatory category refers to an attribute which must be present
> :    in both IBGP and EBGP exchanges if NLRI are contained in the UPDATE
> 
> LOCAL_PREF is listed as "mandatory" throughout the document but
> doesn't meet this condition.

I removed "mandatory" from the first sentence in 5.1.5.

> : 6.2 OPEN message error handling.
> 
> [...]
> 
> :    If the version number contained in the Version field of the received
> :    OPEN message is not supported, then the Error Subcode is set to
> :    Unsupported Version Number. The Data field is a 2-octets unsigned
> :    integer, which indicates the largest locally supported version number
> :    less than the version the remote BGP peer bid (as indicated in the
> :    received OPEN message).
> 
> And if no lower number is supported?
> 
> For example, I send you 5, you send me 4.  If I only support 5,
> what do I put here?
> 
> Should we indicate the version that we told them or even "0" to
> indicate that we can't negotiate down?

Here is the proposed text:

   The Data field is a 2-octets unsigned
   integer, which indicates the largest locally supported version number
   less than the version the remote BGP peer bid (as indicated in the
   received OPEN message), or if the smallest locally supported version
   number is greater than the version the remote BGP peer bid, then
   the smallest locally supported version number.

> : 6.8 Connection collision detection.
> 
> [...]
> 
> I will note that this entire section precluds multiple peering
> sessions across different interfaces for purposes of redundancy
> or traffic engineering.

Could you point me to the specific text in this section that
precludes multiple peering sessions ?

> Should we just consider this to be out of scope for this document?
> 
> : 9. UPDATE Message Handling
> 
> [...]
> 
> :    iii) If the new route has identical path attributes to an earlier
> :    route contained in the Adj-RIB-In, and is more specific (see 9.1.4)
> :    than the earlier route, no further actions are necessary.
> 
> Then how is it going to end up in LocRib and thus to Adj-Ribs-Out?
> 
> :    v) If the new route is an overlapping route that is less specific
> :    (see 9.1.4) than an earlier route contained in the Adj-RIB-In, the
> :    BGP speaker shall run its Decision Process on the set of destinations
> :    described only by the less specific route.
> 
> How do we run decision on only the uncovered components?  
> 
> :    The selection process is formalized by defining a function that takes
> :    the attribute of a given route as an argument and returns a non-
> :    negative integer denoting the degree of preference for the route.
> 
> And further, we don't talk about how to say that "This route is
> excluded from becoming active in LocRib", say, negative preference.
> Additionally, we don't talk about excluding a route in LocRib from
> being installed in Adj-Ribs-Out.
> 
> This seems a serious deficiency since it implies promiscuous policy.
> We will thus always advertise _something_.

Please propose the appropriate text that addresses your comments
on Section 9.

> : 9.1.1 Phase 1: Calculation of Degree of Preference
> 
> [...]
> 
> :    is a local matter. For a route learned from an external peer, the
> :    local speaker shall then run the internal update process of 9.2.1 to
> :    select and advertise the most preferable route.
> 
> 9.2.1 says goto 9.1.2 rules.  Why do we even jump here?
> This point was brought up before.  Why aren't we fixing it?

Please propose the fix.

> :    The local speaker SHALL then install that route in the Loc-RIB,
> :    replacing any route to the same destination that is currently being
> :    held in the Loc-RIB.
> 
> Here's a perfect example of where we don't allow stuff to be excluded
> from becoming active.

Is that just a comment ? Or do you want to change something in the above ?
  
> :    All routes in the Loc-RIB shall be processed into a corresponding
> :    entry in the associated Adj-RIBs-Out. Route aggregation and
> :    information reduction techniques (see 9.2.4.1) may optionally be
> :    applied.
> 
> And here we don't preclude not sending them.

Is that just a comment ? Or do you want to change something in the above ?
  
> I also don't see anything that says that we shouldn't put stuff in
> Adj-Ribs-Out if we're going to place ourselves in the forwarding
> path and we haven't yet installed the LocRib entry in the Routing Table.

Please propose the fix.

Yakov.

Date: Wed, 31 Oct 2001 17:45:17 -0500
From: Jeffrey Haas <[email-masked]>
To: [email-masked]
Subject: draft-15 comments
Sender: [email-masked]

Comments on -15

:    not require periodic refresh of the routing table. Therefore, A BGP

"Therefore, _a_"

:    KEEPALIVE messages are sent periodically to ensure the liveness of

"messages _may_ be sent"

There are several situations where you do not have to send them.

: 4.1 Message Header Format

[...]

:          Otherwise, the value of the marker can be predicted by some a
:          computation specified as part of the authentication mechanism
:          (which is specified as part of the Authentication Information)
:          used.

Pullup from Section 6.1

"The Marker field should be all ones if the OPEN messages carried
no authentication information."

:    present in the Loc-RIB, and the next hop for each of these routes
:    must be present in the local BGP speaker's Routing Table.  Routes

"next hop for each of these routes must be resolvable via the
local BGP speaker's Routing Table."

The previous wording implied that a host entry for the BGP nexthop
would be present in the Routing Table.

: 4.2 OPEN Message Format

[...]

:        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
:        |                                                               |
:        |                       Optional Parameters                     |
:        |                                                               |
:        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Insert "(variable)".

: 4.3 UPDATE Message Format

[...]

:    An UPDATE message is used to advertise a single feasible route to a
:    peer, or to withdraw multiple unfeasible routes from service (see
:    3.1). An UPDATE message may simultaneously advertise a feasible route

"advertise feasible routes sharing common path attributes"

Without this, we imply that you send one destination in 3.1 and later
we send multiple destinations.

:    and withdraw multiple unfeasible routes from service. The UPDATE
:    message always includes the fixed-size BGP header, and also includes
:    the other fields as shown below (note, some of the shown fields may
:    not be present in every UPDATE message):

[Section 5]
:    The mandatory category refers to an attribute which must be present
:    in both IBGP and EBGP exchanges if NLRI are contained in the UPDATE

LOCAL_PREF is listed as "mandatory" throughout the document but
doesn't meet this condition.

: 6.2 OPEN message error handling.

[...]

:    If the version number contained in the Version field of the received
:    OPEN message is not supported, then the Error Subcode is set to
:    Unsupported Version Number. The Data field is a 2-octets unsigned
:    integer, which indicates the largest locally supported version number
:    less than the version the remote BGP peer bid (as indicated in the
:    received OPEN message).

And if no lower number is supported?

For example, I send you 5, you send me 4.  If I only support 5,
what do I put here?

Should we indicate the version that we told them or even "0" to
indicate that we can't negotiate down?

: 6.8 Connection collision detection.

[...]

I will note that this entire section precluds multiple peering
sessions across different interfaces for purposes of redundancy
or traffic engineering.

Should we just consider this to be out of scope for this document?

: 9. UPDATE Message Handling

[...]

:    iii) If the new route has identical path attributes to an earlier
:    route contained in the Adj-RIB-In, and is more specific (see 9.1.4)
:    than the earlier route, no further actions are necessary.

Then how is it going to end up in LocRib and thus to Adj-Ribs-Out?

:    v) If the new route is an overlapping route that is less specific
:    (see 9.1.4) than an earlier route contained in the Adj-RIB-In, the
:    BGP speaker shall run its Decision Process on the set of destinations
:    described only by the less specific route.

How do we run decision on only the uncovered components?  

:    The selection process is formalized by defining a function that takes
:    the attribute of a given route as an argument and returns a non-
:    negative integer denoting the degree of preference for the route.

And further, we don't talk about how to say that "This route is
excluded from becoming active in LocRib", say, negative preference.
Additionally, we don't talk about excluding a route in LocRib from
being installed in Adj-Ribs-Out.

This seems a serious deficiency since it implies promiscuous policy.
We will thus always advertise _something_.

: 9.1.1 Phase 1: Calculation of Degree of Preference

[...]

:    is a local matter. For a route learned from an external peer, the
:    local speaker shall then run the internal update process of 9.2.1 to
:    select and advertise the most preferable route.

9.2.1 says goto 9.1.2 rules.  Why do we even jump here?
This point was brought up before.  Why aren't we fixing it?

:    The local speaker SHALL then install that route in the Loc-RIB,
:    replacing any route to the same destination that is currently being
:    held in the Loc-RIB.

Here's a perfect example of where we don't allow stuff to be excluded
from becoming active.

:    All routes in the Loc-RIB shall be processed into a corresponding
:    entry in the associated Adj-RIBs-Out. Route aggregation and
:    information reduction techniques (see 9.2.4.1) may optionally be
:    applied.

And here we don't preclude not sending them.

I also don't see anything that says that we shouldn't put stuff in
Adj-Ribs-Out if we're going to place ourselves in the forwarding
path and we haven't yet installed the LocRib entry in the Routing Table.

-- 
Jeff Haas 
NextHop Technologies

To: [email-masked]
Subject: second WG Last Call
Date: Wed, 31 Oct 2001 05:59:42 -0800
From: Yakov Rekhter <[email-masked]>
Sender: [email-masked]

Folks,

This is to start the second WG Last Call on advancing
draft-ietf-idr-bgp4-15.txt to a Draft Standard. Note that during
this Last Call you can *only* bring comments on the issues raised
during the previous Last Call that you feel have not been adequately
addressed in the latest revision of the document.

This Last Call ends on Nov 14, 2001.

Yakov.
------- Forwarded Message

Date:    Wed, 31 Oct 2001 07:11:57 -0500
From:    [email-masked]
To:      IETF-Announce: ;
cc:      [email-masked] (subscribed members only)
Subject: I-D ACTION:draft-ietf-idr-bgp4-15.txt

- --NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Inter-Domain Routing Working Group of the IETF
.

	Title		: A Border Gateway Protocol 4 (BGP-4)
	Author(s)	: Y. Rekhter, T. Li
	Filename	: draft-ietf-idr-bgp4-15.txt
	Pages		: 60
	Date		: 30-Oct-01
	
The Border Gateway Protocol (BGP) is an inter-Autonomous System
routing protocol.  It is built on experience gained with EGP as
defined in RFC 904 [1] and EGP usage in the NSFNET Backbone as
described in RFC 1092 [2] and RFC 1093 [3].

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-idr-bgp4-15.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-idr-bgp4-15.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-idr-bgp4-15.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

- --NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

- --OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[email-masked]"

Content-Type: text/plain
Content-ID:	<[email-masked]>

ENCODING mime
FILE /internet-drafts/draft-ietf-idr-bgp4-15.txt

- --OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-idr-bgp4-15.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[email-masked]>

- --OtherAccess--

- --NextPart--

------- End of Forwarded Message

To: Jeffrey Haas <[email-masked]>
Cc: [email-masked]
Subject: Re: draft-14 misc. comments 
Date: Mon, 29 Oct 2001 09:24:58 -0800
From: Yakov Rekhter <[email-masked]>
Sender: [email-masked]

Jeff,

> On Fri, Oct 26, 2001 at 01:40:23PM -0700, Yakov Rekhter wrote:
> :          1) if the first path segment of the AS_PATH is of type
> :          AS_SEQUENCE, the local system shall prepend its own AS number
> :          as the last element of the sequence (put it in the leftmost
> :          position). 
> 
> (Note added period.)
> 
> Add:
> If the act of prepending will cause an overflow in the AS_PATH segment,
> i.e. more than 255 elements, it shall be legal to prepend a new
> segment of type AS_SEQUENCE and prepend its own AS number to this
> new segment.

done.

> > How about if I'll add:
> > 
> >     The Marker field should be all ones if the OPEN message carried no
> >     authentication information.
> 
> This sounds good.

done.

> 
> > > : 6.2 OPEN message error handling.
> > > 
> > > [...]
> > > 
> > > :    If one of the Optional Parameters in the OPEN message is not
> > > :    recognized, then the Error Subcode is set to Unsupported Optional
> > > :    Parameters.
> > > 
> > > What about when optional parameters items are malformed?
> > 
> > The same - Unsupported Optional Parameters.
> 
> I would suggest otherwise.  "Unsupported" argues that we do not support
> it.  If it is supported and is malformed, I would argue 0 (unspecific)
> is more appropriate in the absence of a new error subcode.

done.
  
> Should the draft, draft-chen-bgp-cease-subcode-00.txt, be made a
> generic BGP error code cleanup document if accepted as a WG item?

probably yes.

yakov.

Date: Mon, 29 Oct 2001 12:08:02 -0500
From: Jeffrey Haas <[email-masked]>
To: Dan Pei <[email-masked]>
Cc: [email-masked], Daniel Massey <[email-masked]>
Subject: Re: draft-14 section 9 comments
Sender: [email-masked]

Dan,

On Fri, Oct 26, 2001 at 09:41:30AM -0700, Dan Pei wrote:
> BTW, in the draft, different wording are used to describe whether to
> advertise an EBGP route to iBGP peers.
> 
> -9.1: ...that have the highest degree of preference(what if there is
> a tie?)
> 
> -9.1.1: ... the most preferable route(also, what if there is a tie?)
> 
> -9.2.1: ..."if this route will be installed in its Loc-RIB according to
> the route selection rules in 9.1.2"
> 
> it seems to me that the third one is best among the three, but how to
> modify the draft depends on how we answer the first question(when to send
> internal updates)

I believe we are going to end up with a new draft that moves internal
updates to the same spot as external updates.  If this is so, we
should update the text consistantly based on what we end up with.

I also like the third one since its the most precise answer.

> Dan

-- 
Jeff Haas 
NextHop Technologies

Date: Mon, 29 Oct 2001 12:05:45 -0500
From: Jeffrey Haas <[email-masked]>
To: Yakov Rekhter <[email-masked]>
Cc: [email-masked]
Subject: Re: draft-14 section 9 comments
Sender: [email-masked]

On Fri, Oct 26, 2001 at 01:45:10PM -0700, Yakov Rekhter wrote:
> > Here's the appropriate sections:
> > 
> > :       For the purpose of aggregating AS_PATH attributes we model each AS
> > :       within the AS_PATH attribute as a tuple <type, value>, where
> > :       "type" identifies a type of the path segment the AS belongs to
> > :       (e.g. AS_SEQUENCE, AS_SET), and "value" is the AS number. If the
> > :       routes to be aggregated have different AS_PATH attributes, then
> > :       the aggregated AS_PATH attribute shall satisfy all of the
> > :       following conditions:
> > 
> > So, the AS_PATH AS_SEQ (1, 1, 1) would then be represented as
> > <AS_SEQ, 1> <AS_SEQ, 1> <AS_SEQ, 1>
> > 
> > :          - No tuple with the same value shall appear more than once in
> > :          the aggregated AS_PATH, regardless of the tuple's type.
> > 
> > This implies that we must truncate the above.
> > 
> > Have I missed something?  If so, perhaps we need to tighten some wording.
> 
> No, you are correct - it was my mistake. 
> 
> Please propose the appropriate text.

How about:

- No tuple with the type of AS_SET with the same value shall appear more
than once in the aggregated AS_PATH.

- Tuples with the type of AS_SEQUENCE with the same value may
appear more than once in the aggregated AS_PATH only when it is
adjacent to another tuple of type AS_SEQUENCE with the same value.

(This last sentence feels a little awkward.  Other suggestions?)

> Yakov.

-- 
Jeff Haas 
NextHop Technologies

Date: Mon, 29 Oct 2001 12:01:24 -0500
From: Jeffrey Haas <[email-masked]>
To: Yakov Rekhter <[email-masked]>
Cc: [email-masked]
Subject: Re: draft-14 misc. comments
Sender: [email-masked]

On Fri, Oct 26, 2001 at 01:40:23PM -0700, Yakov Rekhter wrote:
:          1) if the first path segment of the AS_PATH is of type
:          AS_SEQUENCE, the local system shall prepend its own AS number
:          as the last element of the sequence (put it in the leftmost
:          position). 

(Note added period.)

Add:
If the act of prepending will cause an overflow in the AS_PATH segment,
i.e. more than 255 elements, it shall be legal to prepend a new
segment of type AS_SEQUENCE and prepend its own AS number to this
new segment.

> How about if I'll add:
> 
>     The Marker field should be all ones if the OPEN message carried no
>     authentication information.

This sounds good.

> > : 6.2 OPEN message error handling.
> > 
> > [...]
> > 
> > :    If one of the Optional Parameters in the OPEN message is not
> > :    recognized, then the Error Subcode is set to Unsupported Optional
> > :    Parameters.
> > 
> > What about when optional parameters items are malformed?
> 
> The same - Unsupported Optional Parameters.

I would suggest otherwise.  "Unsupported" argues that we do not support
it.  If it is supported and is malformed, I would argue 0 (unspecific)
is more appropriate in the absence of a new error subcode.

Should the draft, draft-chen-bgp-cease-subcode-00.txt, be made a
generic BGP error code cleanup document if accepted as a WG item?

If so, this would argue adding a new subcode to open:

7 - Malformed Optional Attribute(s)
Data - contains the malformed optional attributes.

In the case where the field lenghts are malformed, 0 (unspecific) is
still probably appropriate. 

-- 
Jeff Haas 
NextHop Technologies

To: Jeffrey Haas <[email-masked]>
Cc: [email-masked]
Subject: Re: draft-14 editorial comments 
Date: Fri, 26 Oct 2001 13:47:54 -0700
From: Yakov Rekhter <[email-masked]>
Sender: [email-masked]

> :    configured local policy, the BGP Route Refresh option [12] may be
> 
> Perhaps referring to it as an extension would be more precise.

Done.

> 
> 
> : 3.2 Routing Information Bases
> 
> When talking about the RIBs, we don't discuss possible route modifications
> that may be done in the process of installing things in the Adj-Ribs-Out.
> What are we claiming to store in the Adj-Ribs-Out - a "handle" to the
> item in the Loc-Rib or the changes that will happen to the route when
> we advertise it to the peer associated with the Rib?
> 
> In other words, do we keep state of the changes to the route instance
> in the rib or is that part of the Update-Send process?

That seems like an implementation issue (aka "local matter").

> :        0                   1                   2                   3
> :        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
> :        +-+-+-+-+-+-+-+-+
> :        |    Version    |
> :        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> :        |     My Autonomous System      |
> :        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> :        |           Hold Time           |
> :        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> :        |                         BGP Identifier                        |
> :        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> :        | Opt Parm Len  |
> : 
> : 
> : 
> : Expiration Date April 2002                                      [Page 8]
> : 
> : 
> : 
> : 
> : 
> : RFC DRAFT                                                   October 2001
> : 
> : 
> :        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> :        |                                                               |
> :        |                       Optional Parameters                     |
> :        |                                                               |
> :        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> 
> Could we keep these diagrams together?

Yes.

> : 3.1 Routes: Advertisement and Storage
> : 
> :    For purposes of this protocol a route is defined as a unit of
> :    information that pairs a destination with the attributes of a path to
> :    that destination:
> [...]
> :    An UPDATE message is used to advertise a single feasible route to a
> :    peer, or to withdraw multiple unfeasible routes from service (see
> :    3.1).
> 
> A "single feasible route" by 3.1 seems to indicate a destination and
> a path attribute set.

If you have a specific replacement text, then please propose it.

> :        0                   1                   2                   3
> :        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
> :        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> :        | Error code    | Error subcode |           Data                |
> :        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               +
> :        |                     (variable)                                |
> :        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> 
> Shorten to:
> 
> :        0                   1                   2                   3
> :        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
> :        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> :        | Error code    | Error subcode |      Data (variable)          |
> :        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Done.

Yakov.

To: Jeffrey Haas <[email-masked]>
Cc: [email-masked]
Subject: Re: draft-14 section 9 comments 
Date: Fri, 26 Oct 2001 13:45:10 -0700
From: Yakov Rekhter <[email-masked]>
Sender: [email-masked]

Jeff,

> > > : 9.1.2.1 Route Resolvability Condition
> > > 
> > > :    It is also important that implementations do not consider feasible
> > > :    routes that would become unresolvable if they were installed in the
> > > :    Routing Table even if their NEXT_HOPs are resolvable using the
> > > :    current contents of the Routing Table. This check ensures that a BGP
> > > :    speaker does not install in the Routing Table routes that will be
> > > :    removed and not used by the speaker. Therefore, in addition to local
> > > :    Routing Table stability, this check also improves behavior of the
> > > :    protocol in the network.
> > > 
> > > It is unclear what we're looking at here.  An example may help.
> > 
> > The example is in the paragraph before the one you quoted above
> > (the example talks about mutually recursive routes).
> 
> I'm suggesting that it should say so explicitly.
> 
> :    It is also important that implementations do not consider feasible
> :    routes that would become unresolvable if they were installed in the
> :    Routing Table even if their NEXT_HOPs are resolvable using the
> :    current contents of the Routing Table
> 
> , e.g. (i.e.?) mutually recursive routes.

fixed.

> > > :          - No tuple with the same value shall appear more than once in
> > > :          the aggregated AS_PATH, regardless of the tuple's type.
> > > 
> > > This would seem to say that we get rid of AS-Path prepending at this
> > > point.
> > 
> > No, its not (please look at how "tuple" is defined earlier in that section)
.
> 
> Here's the appropriate sections:
> 
> :       For the purpose of aggregating AS_PATH attributes we model each AS
> :       within the AS_PATH attribute as a tuple <type, value>, where
> :       "type" identifies a type of the path segment the AS belongs to
> :       (e.g. AS_SEQUENCE, AS_SET), and "value" is the AS number. If the
> :       routes to be aggregated have different AS_PATH attributes, then
> :       the aggregated AS_PATH attribute shall satisfy all of the
> :       following conditions:
> 
> So, the AS_PATH AS_SEQ (1, 1, 1) would then be represented as
> <AS_SEQ, 1> <AS_SEQ, 1> <AS_SEQ, 1>
> 
> :          - No tuple with the same value shall appear more than once in
> :          the aggregated AS_PATH, regardless of the tuple's type.
> 
> This implies that we must truncate the above.
> 
> Have I missed something?  If so, perhaps we need to tighten some wording.

No, you are correct - it was my mistake. 

Please propose the appropriate text.

Yakov.

To: Jeffrey Haas <[email-masked]>
Cc: [email-masked]
Subject: Re: draft-14 misc. comments 
Date: Fri, 26 Oct 2001 13:40:23 -0700
From: Yakov Rekhter <[email-masked]>
Sender: [email-masked]

Jeff,

> Some miscellaneous comments:
> 
> :       b) When a given BGP speaker advertises the route to an external
> :       peer, then the advertising speaker shall update the AS_PATH
> :       attribute as follows:
> : 
> :          1) if the first path segment of the AS_PATH is of type
> :          AS_SEQUENCE, the local system shall prepend its own AS number
> :          as the last element of the sequence (put it in the leftmost
> :          position)
> : 
> :          2) if the first path segment of the AS_PATH is of type AS_SET,
> :          the local system shall prepend a new path segment of type
> :          AS_SEQUENCE to the AS_PATH, including its own AS number in that
> :          segment.
> : 
> :    When a BGP speaker originates a route then:
> : 
> :       a) the originating speaker shall include its own AS number in a
> :       path segment of type AS_SEQUENCE in the AS_PATH attribute of all
> :       UPDATE messages sent to an external peer. (In this case, the AS
> :       number of the originating speaker's autonomous system will be the
> :       only entry the path segment, and this path segment will be the
> :       only segment in the AS_PATH attribute).
> : 
> :       b) the originating speaker shall include an empty AS_PATH
> :       attribute in all UPDATE messages sent to internal peers.  (An
> :       empty AS_PATH attribute is one whose length field contains the
> :       value zero).
> : 
> :    Whenever the modification of the AS_PATH attribute calls for
> :    including or prepending the AS number of the local system, the local
> :    system may include/prepend more than one instance of its own AS
> :    number in the AS_PATH attribute. This is controlled via local
> :    configuration.
> 
> We should make mention that if we need to add a new segment because
> we've filled the last one, that is allowable.

Please proposed the specific text.

> : 5.1.7 AGGREGATOR
> : 
> : 
> :    AGGREGATOR is an optional transitive attribute which may be included
> 
> "should" be included?

Let's stick with the current text.

> 
> : 6.1 Message Header error handling.
> : 
> : 
> :    All errors detected while processing the Message Header are indicated
> :    by sending the NOTIFICATION message with Error Code Message Header
> :    Error. The Error Subcode elaborates on the specific nature of the
> :    error.
> : 
> :    The expected value of the Marker field of the message header is all
> :    ones if the message type is OPEN. The expected value of the Marker
> :    field for all other types of BGP messages determined based on the
> :    presence of the Authentication Information Optional Parameter in the
> :    BGP OPEN message and the actual authentication mechanism (if the
> :    Authentication Information in the BGP OPEN message is present). If
> :    the Marker field of the message header is not the expected one, then
> :    a synchronization error has occurred and the Error Subcode is set to
> :    Connection Not Synchronized.
> 
> We don't discuss what the Marker field should be when no authentication
> is present.  I see that GateD uses all one's every time.

How about if I'll add:

    The Marker field should be all ones if the OPEN message carried no
    authentication information.

> 
> : 6.2 OPEN message error handling.
> 
> [...]
> 
> :    If one of the Optional Parameters in the OPEN message is not
> :    recognized, then the Error Subcode is set to Unsupported Optional
> :    Parameters.
> 
> What about when optional parameters items are malformed?

The same - Unsupported Optional Parameters.
  
> : 6.7 Cease.
> 
> [...]
> 
> :    either (a) stop accepting new address prefixes from the neighbor, or
> 
> "discard new prefixes" may be more precise.

fixed.

Yakov.

To: Enke Chen <[email-masked]>
Cc: [email-masked]
Subject: Re: Last Call 
Date: Fri, 26 Oct 2001 13:25:19 -0700
From: Yakov Rekhter <[email-masked]>
Sender: [email-masked]

Enke,

> Hi, Yakov:
> Just noticed that Sect. 9.2.1.1 "Breaking Ties (Internal Updates)" is
> not consistent with Section 9.1.2.2 "Breaking Ties (Phase 2)". It also
> seems redundant.
> 
> So I suggest that Sect. 9.2.1.1 be removed.

The suggestion accepted.

Yakov.

> 
> Thanks.  -- Enke
> 
> > Message-Id: <[email-masked]>
> > To: [email-masked]
> > Cc: [email-masked], [email-masked]
> > Subject: Last Call
> > Date: Mon, 15 Oct 2001 18:37:06 -0700
> > From: Yakov Rekhter <[email-masked]>
> > Sender: [email-masked]
> > Precedence: bulk
> > 
> > Folks,
> > 
> > This is to start the IDR WG Last Call on advancing
> > draft-ietf-idr-bgp4-14.txt to Draft Standard. The Last
> > Call ends on 10/29.
> > 
> > Yakov.
> > ------- Forwarded Message
> > 
> > Date:    Mon, 15 Oct 2001 07:01:50 -0400
> > From:    [email-masked]
> > To:      IETF-Announce: ;
> > cc:      [email-masked] (subscribed members only)
> > Subject: I-D ACTION:draft-ietf-idr-bgp4-14.txt
> > 
> > - --NextPart
> > 
> > A New Internet-Draft is available from the on-line Internet-Drafts director
ies.
> > This draft is a work item of the Inter-Domain Routing Working Group of the 
IETF
> > .
> > 
> > 	Title		: A Border Gateway Protocol 4 (BGP-4)
> > 	Author(s)	: Y. Rekhter, T. Li
> > 	Filename	: draft-ietf-idr-bgp4-14.txt
> > 	Pages		: 61
> > 	Date		: 12-Oct-01
> > 	
> > The Border Gateway Protocol (BGP) is an inter-Autonomous System
> > routing protocol.  It is built on experience gained with EGP as
> > defined in RFC 904 [1] and EGP usage in the NSFNET Backbone as
> > described in RFC 1092 [2] and RFC 1093 [3].
> > 
> > A URL for this Internet-Draft is:
> > http://www.ietf.org/internet-drafts/draft-ietf-idr-bgp4-14.txt
> > 
> > To remove yourself from the IETF Announcement list, send a message to 
> > ietf-announce-request with the word unsubscribe in the body of the message.
> > 
> > Internet-Drafts are also available by anonymous FTP. Login with the usernam
e
> > "anonymous" and a password of your e-mail address. After logging in,
> > type "cd internet-drafts" and then
> > 	"get draft-ietf-idr-bgp4-14.txt".
> > 
> > A list of Internet-Drafts directories can be found in
> > http://www.ietf.org/shadow.html 
> > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> > 

Date: Fri, 26 Oct 2001 15:32:44 -0400
From: Jeffrey Haas <[email-masked]>
To: Yakov Rekhter <[email-masked]>
Cc: [email-masked]
Subject: Re: draft-14 section 9 comments
Sender: [email-masked]

On Fri, Oct 26, 2001 at 11:55:56AM -0700, Yakov Rekhter wrote:
> > : 9.1.2.1 Route Resolvability Condition
> > 
> > :    It is also important that implementations do not consider feasible
> > :    routes that would become unresolvable if they were installed in the
> > :    Routing Table even if their NEXT_HOPs are resolvable using the
> > :    current contents of the Routing Table. This check ensures that a BGP
> > :    speaker does not install in the Routing Table routes that will be
> > :    removed and not used by the speaker. Therefore, in addition to local
> > :    Routing Table stability, this check also improves behavior of the
> > :    protocol in the network.
> > 
> > It is unclear what we're looking at here.  An example may help.
> 
> The example is in the paragraph before the one you quoted above
> (the example talks about mutually recursive routes).

I'm suggesting that it should say so explicitly.

:    It is also important that implementations do not consider feasible
:    routes that would become unresolvable if they were installed in the
:    Routing Table even if their NEXT_HOPs are resolvable using the
:    current contents of the Routing Table

, e.g. (i.e.?) mutually recursive routes.

> > :          - No tuple with the same value shall appear more than once in
> > :          the aggregated AS_PATH, regardless of the tuple's type.
> > 
> > This would seem to say that we get rid of AS-Path prepending at this
> > point.
> 
> No, its not (please look at how "tuple" is defined earlier in that section).

Here's the appropriate sections:

:       For the purpose of aggregating AS_PATH attributes we model each AS
:       within the AS_PATH attribute as a tuple <type, value>, where
:       "type" identifies a type of the path segment the AS belongs to
:       (e.g. AS_SEQUENCE, AS_SET), and "value" is the AS number. If the
:       routes to be aggregated have different AS_PATH attributes, then
:       the aggregated AS_PATH attribute shall satisfy all of the
:       following conditions:

So, the AS_PATH AS_SEQ (1, 1, 1) would then be represented as
<AS_SEQ, 1> <AS_SEQ, 1> <AS_SEQ, 1>

:          - No tuple with the same value shall appear more than once in
:          the aggregated AS_PATH, regardless of the tuple's type.

This implies that we must truncate the above.

Have I missed something?  If so, perhaps we need to tighten some wording.

> Yakov.

-- 
Jeff Haas 
NextHop Technologies

To: Jeffrey Haas <[email-masked]>
Cc: [email-masked]
Subject: Re: draft-14 section 9 comments 
Date: Fri, 26 Oct 2001 11:55:56 -0700
From: Yakov Rekhter <[email-masked]>
Sender: [email-masked]

Jeff,

[clipped...]

> : 9.1.2.1 Route Resolvability Condition
> 
> :    It is also important that implementations do not consider feasible
> :    routes that would become unresolvable if they were installed in the
> :    Routing Table even if their NEXT_HOPs are resolvable using the
> :    current contents of the Routing Table. This check ensures that a BGP
> :    speaker does not install in the Routing Table routes that will be
> :    removed and not used by the speaker. Therefore, in addition to local
> :    Routing Table stability, this check also improves behavior of the
> :    protocol in the network.
> 
> It is unclear what we're looking at here.  An example may help.

The example is in the paragraph before the one you quoted above
(the example talks about mutually recursive routes).

> : 9.1.3 Phase 3: Route Dissemination
> 
> [...]
> 
> :       c) when a new BGP speaker - BGP speaker connection has been
> :       established
> 
> This argues that an Adj-RIB-Out exists for every BGP peer, even if
> the connection isn't established.  This makes unconfigured peers a
> little awkward in this context since the Adj-RIB-Out doesn't exist
> until the peer comes up.
> 
> Suggestions?
> 
> : 9.2.1.1 Breaking Ties (Internal Updates)
> 
> Why are we duplicating part of the decision process here?  This
> should have been done as part of putting the routes in the
> Adj-RIB-Out for this peer.
> 
> We also really don't talk about modification to the route here.

Enke's e-mail that he posted to the list on Oct 15 suggested this
already.

> : 9.2.4.1 Information Reduction
> 
> [...]
> 
> :       a)   Network Layer Reachability Information (NLRI):
> : 
> :       Destination IP addresses can be represented as IP address
> :       prefixes. In cases where there is a correspondence between the
> :       address structure and the systems under control of an autonomous
> :       system administrator, it will be possible to reduce the size of
> :       the NLRI carried in the UPDATE messages.
> 
> Huh?
> 
> : 9.2.4.2 Aggregating Routing Information
> 
> [...]
> 
> :       route is INTERNAL.
> 
> IGP.

Ok.

> 
> :          - No tuple with the same value shall appear more than once in
> :          the aggregated AS_PATH, regardless of the tuple's type.
> 
> This would seem to say that we get rid of AS-Path prepending at this
> point.

No, its not (please look at how "tuple" is defined earlier in that section).

Yakov.

To: [email-masked]
Cc: [email-masked]
Subject: Last Call on draft-ietf-idr-route-oscillation-00.txt 
Date: Fri, 26 Oct 2001 10:47:57 -0700
From: Yakov Rekhter <[email-masked]>
Sender: [email-masked]

Folks,

This is to start the IDR WG Last Call on advancing
draft-ietf-idr-route-oscillation-00.txt to an Informational RFC.
The Last Call ends Nov 9, 2001.

Please send any comments to the list.

Yakov.

Date: Fri, 26 Oct 2001 09:41:30 -0700 (PDT)
From: Dan Pei <[email-masked]>
To: Jeffrey Haas <[email-masked]>
Cc: <[email-masked]>, Daniel Massey <[email-masked]>
Subject: Re: draft-14 section 9 comments
Sender: [email-masked]

Jeffrey,

> : 9.1.1 Phase 1: Calculation of Degree of Preference
>
> [...]
>
> :    For a route learned from an external peer, the
> :    local speaker shall then run the internal update process of 9.2.1 to
> :    select and advertise the most preferable route.
>
> Why are we jumping here?  That section talks about Loc-Rib and thus
> sends us right back to Phase 2.

A quite related comment is(I remember one or two months ago, people asked
similar questions):

|9.1
|[...]
|
|   The Decision Process takes place in three distinct phases, each
|   triggered by a different event:
|
|      a) Phase 1 is responsible for calculating the degree of preference
|      for each route received from an external peer, and MAY also
                                                          ^^^^^^^
The draft seems imply that it is allowed to send internal updates at phase
1, before phase 2(note that "Phase 2 is invoked on completion of phase
1").

|      advertise to all the internal peers the routes from external peers
|      that have the highest degree of preference for each distinct
|      destination.
|
|      b) Phase 2 is invoked on completion of phase 1. It is responsible
|      for choosing the best route out of all those available for each
|      distinct destination, and for installing each chosen route into
|      the appropriate Loc-RIB.
...
|      c) Phase 3 is invoked after the Loc-RIB has been modified. It is
|      responsible for disseminating routes in the Loc-RIB to each
|      external peer, according to the policies contained in the PIB.
|      Route aggregation and information reduction can optionally be
|      performed within this phase.

Phase 3 sends updates to only external peer--- here the draft seems
require that sending internal update can only happen in phase 1!

I am wondering what is really happening in practice(when to send internal
update), and how we could modify the draft to reflect the practice?

BTW, in the draft, different wording are used to describe whether to
advertise an EBGP route to iBGP peers.

-9.1: ...that have the highest degree of preference(what if there is
a tie?)

-9.1.1: ... the most preferable route(also, what if there is a tie?)

-9.2.1: ..."if this route will be installed in its Loc-RIB according to
the route selection rules in 9.1.2"

it seems to me that the third one is best among the three, but how to
modify the draft depends on how we answer the first question(when to send
internal updates)

Thanks,

---
Dan

Date: Fri, 26 Oct 2001 10:41:42 -0400
From: Jeffrey Haas <[email-masked]>
To: [email-masked]
Subject: draft-14 section 9 comments
Sender: [email-masked]

: 9. UPDATE Message Handling

[...]

:    iii) If the new route has identical path attributes to an earlier
:    route contained in the Adj-RIB-In, and is more specific (see 9.1.4)
:    than the earlier route, no further actions are necessary.

If we don't run the Decision Process, then how is this going to 
end up in Loc-Rib or Adj-Ribs-Out?

:    v) If the new route is an overlapping route that is less specific
:    (see 9.1.4) than an earlier route contained in the Adj-RIB-In, the
:    BGP speaker shall run its Decision Process on the set of destinations
:    described only by the less specific route.

How do we run the Decision Process on the un-covered portions of the
route?

: 9.1.1 Phase 1: Calculation of Degree of Preference

[...]

:    For a route learned from an external peer, the
:    local speaker shall then run the internal update process of 9.2.1 to
:    select and advertise the most preferable route.

Why are we jumping here?  That section talks about Loc-Rib and thus
sends us right back to Phase 2.

: 9.1.2.1 Route Resolvability Condition

:    It is also important that implementations do not consider feasible
:    routes that would become unresolvable if they were installed in the
:    Routing Table even if their NEXT_HOPs are resolvable using the
:    current contents of the Routing Table. This check ensures that a BGP
:    speaker does not install in the Routing Table routes that will be
:    removed and not used by the speaker. Therefore, in addition to local
:    Routing Table stability, this check also improves behavior of the
:    protocol in the network.

It is unclear what we're looking at here.  An example may help.

: 9.1.3 Phase 3: Route Dissemination

[...]

:       c) when a new BGP speaker - BGP speaker connection has been
:       established

This argues that an Adj-RIB-Out exists for every BGP peer, even if
the connection isn't established.  This makes unconfigured peers a
little awkward in this context since the Adj-RIB-Out doesn't exist
until the peer comes up.

Suggestions?

: 9.2.1.1 Breaking Ties (Internal Updates)

Why are we duplicating part of the decision process here?  This
should have been done as part of putting the routes in the
Adj-RIB-Out for this peer.

We also really don't talk about modification to the route here.

: 9.2.4.1 Information Reduction

[...]

:       a)   Network Layer Reachability Information (NLRI):
: 
:       Destination IP addresses can be represented as IP address
:       prefixes. In cases where there is a correspondence between the
:       address structure and the systems under control of an autonomous
:       system administrator, it will be possible to reduce the size of
:       the NLRI carried in the UPDATE messages.

Huh?

: 9.2.4.2 Aggregating Routing Information

[...]

:       route is INTERNAL.

IGP.

:          - No tuple with the same value shall appear more than once in
:          the aggregated AS_PATH, regardless of the tuple's type.

This would seem to say that we get rid of AS-Path prepending at this
point.

:          - determine the longest leading sequence of tuples (as defined
:          above) common to all the AS_PATH attributes of the routes to be
:          aggregated. Make this sequence the leading sequence of the
:          aggregated AS_PATH attribute.

But this argues that we'd keep them in some cases.

-- 
Jeff Haas 
NextHop Technologies

Date: Fri, 26 Oct 2001 10:39:46 -0400
From: Jeffrey Haas <[email-masked]>
To: [email-masked]
Subject: draft-14 misc. comments
Sender: [email-masked]

Some miscellaneous comments:

:       b) When a given BGP speaker advertises the route to an external
:       peer, then the advertising speaker shall update the AS_PATH
:       attribute as follows:
: 
:          1) if the first path segment of the AS_PATH is of type
:          AS_SEQUENCE, the local system shall prepend its own AS number
:          as the last element of the sequence (put it in the leftmost
:          position)
: 
:          2) if the first path segment of the AS_PATH is of type AS_SET,
:          the local system shall prepend a new path segment of type
:          AS_SEQUENCE to the AS_PATH, including its own AS number in that
:          segment.
: 
:    When a BGP speaker originates a route then:
: 
:       a) the originating speaker shall include its own AS number in a
:       path segment of type AS_SEQUENCE in the AS_PATH attribute of all
:       UPDATE messages sent to an external peer. (In this case, the AS
:       number of the originating speaker's autonomous system will be the
:       only entry the path segment, and this path segment will be the
:       only segment in the AS_PATH attribute).
: 
:       b) the originating speaker shall include an empty AS_PATH
:       attribute in all UPDATE messages sent to internal peers.  (An
:       empty AS_PATH attribute is one whose length field contains the
:       value zero).
: 
:    Whenever the modification of the AS_PATH attribute calls for
:    including or prepending the AS number of the local system, the local
:    system may include/prepend more than one instance of its own AS
:    number in the AS_PATH attribute. This is controlled via local
:    configuration.

We should make mention that if we need to add a new segment because
we've filled the last one, that is allowable.

: 5.1.7 AGGREGATOR
: 
: 
:    AGGREGATOR is an optional transitive attribute which may be included

"should" be included?

: 6.1 Message Header error handling.
: 
: 
:    All errors detected while processing the Message Header are indicated
:    by sending the NOTIFICATION message with Error Code Message Header
:    Error. The Error Subcode elaborates on the specific nature of the
:    error.
: 
:    The expected value of the Marker field of the message header is all
:    ones if the message type is OPEN. The expected value of the Marker
:    field for all other types of BGP messages determined based on the
:    presence of the Authentication Information Optional Parameter in the
:    BGP OPEN message and the actual authentication mechanism (if the
:    Authentication Information in the BGP OPEN message is present). If
:    the Marker field of the message header is not the expected one, then
:    a synchronization error has occurred and the Error Subcode is set to
:    Connection Not Synchronized.

We don't discuss what the Marker field should be when no authentication
is present.  I see that GateD uses all one's every time.

: 6.2 OPEN message error handling.

[...]

:    If one of the Optional Parameters in the OPEN message is not
:    recognized, then the Error Subcode is set to Unsupported Optional
:    Parameters.

What about when optional parameters items are malformed?

: 6.7 Cease.

[...]

:    either (a) stop accepting new address prefixes from the neighbor, or

"discard new prefixes" may be more precise.

-- 
Jeff Haas 
NextHop Technologies

Date: Fri, 26 Oct 2001 10:43:20 -0400
From: Jeffrey Haas <[email-masked]>
To: [email-masked]
Subject: draft-14 editorial comments
Sender: [email-masked]

:    configured local policy, the BGP Route Refresh option [12] may be

Perhaps referring to it as an extension would be more precise.

: 3.2 Routing Information Bases

When talking about the RIBs, we don't discuss possible route modifications
that may be done in the process of installing things in the Adj-Ribs-Out.
What are we claiming to store in the Adj-Ribs-Out - a "handle" to the
item in the Loc-Rib or the changes that will happen to the route when
we advertise it to the peer associated with the Rib?

In other words, do we keep state of the changes to the route instance
in the rib or is that part of the Update-Send process?

:        0                   1                   2                   3
:        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
:        +-+-+-+-+-+-+-+-+
:        |    Version    |
:        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
:        |     My Autonomous System      |
:        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
:        |           Hold Time           |
:        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
:        |                         BGP Identifier                        |
:        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
:        | Opt Parm Len  |
: 
: 
: 
: Expiration Date April 2002                                      [Page 8]
: 
: 
: 
: 
: 
: RFC DRAFT                                                   October 2001
: 
: 
:        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
:        |                                                               |
:        |                       Optional Parameters                     |
:        |                                                               |
:        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Could we keep these diagrams together?

: 3.1 Routes: Advertisement and Storage
: 
:    For purposes of this protocol a route is defined as a unit of
:    information that pairs a destination with the attributes of a path to
:    that destination:
[...]
:    An UPDATE message is used to advertise a single feasible route to a
:    peer, or to withdraw multiple unfeasible routes from service (see
:    3.1).

A "single feasible route" by 3.1 seems to indicate a destination and
a path attribute set.

:        0                   1                   2                   3
:        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
:        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
:        | Error code    | Error subcode |           Data                |
:        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               +
:        |                     (variable)                                |
:        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Shorten to:

:        0                   1                   2                   3
:        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
:        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
:        | Error code    | Error subcode |      Data (variable)          |
:        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

-- 
Jeff Haas 
NextHop Technologies

Date: Fri, 26 Oct 2001 10:36:10 -0400
From: Jeffrey Haas <[email-masked]>
To: [email-masked]
Subject: draft-14 ATOMIC_AGGREGATE comments
Sender: [email-masked]

The most recent text in draft-14 for ATOMIC_AGGREGATE seems to be
closer to the actual intent of it, but still missed a case.

: 5.1.6 ATOMIC_AGGREGATE
: 
: 
:    ATOMIC_AGGREGATE is a well-known discretionary attribute. There are
:    two cases where the ATOMIC_AGGREGATE attribute is used:
: 
:       - a speaker receives both more and less specific routes, these
:       routes have the same NEXT_HOP, the AS_PATH attribute of the more
:       specific route is different from the AS_PATH attribute of the less
:       specific route, and the speaker installs in its Loc-RIB only the
:       less specific route. In this case the speaker should advertise
:       this route with the ATOMIC_AGGREGATE attribute to all neighbors
:       (subject to the outbound route filtering).
:
:       - a speaker receives both more and less specific routes the
:       AS_PATH attribute of the more specific route is different from the
:       AS_PATH attribute of the less specific route, the speaker installs
:       in its Loc-RIB both routes, but the speaker advertises to a
:       particular neighbor only the less specific route. In this case the
:       advertisement MUST carry the ATOMIC_AGGREGATE attribute.

Say I have two peers, 1 and 2.  I receive less specific prefix L and
more specific prefix M from 1.  I receive from peer 2 more specific M.
I select M from peer 2 and L from peer 1.  I advertise both actives.

Should I then append AA?  I don't think so.

I would suggest the following text:

"5.1.6 ATOMIC_AGGREGATE

 ATOMIC_AGGREGATE is a well-known discretionary attribute.  It is used
 to indicate (signal?) that the actual path to destinations, as
 specified in the NLRI of the route, while having the loop-free
 property, may not be the path specified in the AS_PATH attribute
 of the route.

 If a BGP speaker chooses to aggregate BGP routes (see 9.2.4.2),
 then the ATOMIC_AGGREGATE attribute must be added.

 A BGP may also implicitly aggregate routes by announcing a less
 specific route when more specific routes are available.  A BGP
 speaker may optionally add the ATOMIC_AGGREGATE attribute when
 the following conditions are met:

 L is a less-specific route in a peer's Adj-Rib-Out.

 If there is a more specific route, M, in the same Adj-Rib-In as L
 and, for that destination, there is no route with the same destination
 present in the peer's Adj-Rib-Out and the NEXT_HOP or AS_PATH of
 L and M are different, then the ATOMIC_AGGREGATE attribute may be
 added.

 A BGP speaker that receives a route with the ATOMIC_AGGREGATE
 attribute MUST NOT remove the attribute from the route when
 propagating it to other speakers.

 A BGP speaker that receives a route with the ATOMIC_AGGREGATE
 attribute MUST NOT make any NLRI of that route more specific (as
 defined in 9.1.4) when advertising this route to other BGP speakers."

-- 
Jeff Haas 
NextHop Technologies

From: "Fouant, Stefan" <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: Route Dissemination in BGP-4
Date: Thu, 18 Oct 2001 12:13:05 -0400
Sender: [email-masked]

Hi,

I have a question concerning RFC 1771.  In Section 9.1.3, 4th paragraph, the
authors state the following:

"For the benefit of future support of inter-AS multicast capabilities, a BGP
speaker that participates in inter-AS multicast routing shall advertise a
route it receives from one of its external peers and if it installs it in
its Loc-RIB, it shall advertise it back to the peer from which the route was
received. For a BGP speaker that does not participate in inter-AS multicast
routing such an advertisement is optional."

In addition, this paragraph does not appear in draft-ietf-idr-bgp4-14.txt.

Can someone please tell me why this behavior was desired, and is this
behavior necessary in light of new inter-domain multicast routing protocols,
namely MBGP or BGMP?

Other than multicast scenarios, why would an EBGP peer want to re-advertise
the same routes it had learned back to the peer whom he had learned them
from?  Thanks,

Stefan Fouant
Senior Network Engineer
UUNET, an MCI WorldCom Company

To: [email-masked]
Cc: [email-masked], [email-masked]
Subject: draft-chen-bgp-cease-subcode-00.txt
Date: Tue, 16 Oct 2001 15:02:16 -0700
From: Yakov Rekhter <[email-masked]>
Sender: [email-masked]

Folks,

Since there have been no objections to the attached, we'll take 
draft-chen-bgp-cease-subcode-00.txt as an IDR WG document. 
With this in mind, I'd like to ask authors of the document to 
re-issue it as an IDR WG Internet Draft.

Yakov.
------- Forwarded Message

Date:    Fri, 21 Sep 2001 12:41:03 -0700
From:    Yakov Rekhter <[email-masked]>
To:      [email-masked]
Subject: draft-chen-bgp-cease-subcode-00.txt

Folks,

We received a request to accept draft-chen-bgp-cease-subcode-00.txt
as a WG document (see below). If you have any objections, please
send them to this list within the next 3 weeks. In the absence of
any objections by Oct 12, we'll accept draft-chen-bgp-cease-subcode-00.txt
as a IDR WG document.

Yakov.
- ------- Forwarded Message

Date:    Fri, 21 Sep 2001 09:02:01 -0700
From:    Enke Chen <[email-masked]>
To:      [email-masked], [email-masked]
cc:      [email-masked], [email-masked]
Subject: Re: I-D ACTION:draft-chen-bgp-cease-subcode-00.txt

Hi, Yakov and Sue:
Here is a draft that formalizes the idea of defining several Cease
Subcodes (discussed on the IDR mailing list without any objection).

Could you accept it as an IDR Working Group document?

Thanks. -- Enke

- - ------- Forwarded Message

To: IETF-Announce: ;
From: [email-masked]
Reply-To: [email-masked]
Subject: I-D ACTION:draft-chen-bgp-cease-subcode-00.txt
Date: Fri, 21 Sep 2001 07:04:13 -0400
Sender: [email-masked]

- - - --NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.

	Title		: Subcodes for BGP Cease Notification Message
	Author(s)	: E. Chen, V.Gillet
	Filename	: draft-chen-bgp-cease-subcode-00.txt
	Pages		: 4
	Date		: 20-Sep-01
	
This document defines several subcodes for the BGP Cease NOTIFICATION
message that would provide more information to aid network operators
in co-relating network events and diagnosing BGP peering issues.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-chen-bgp-cease-subcode-00.txt

- - ------- End of Forwarded Message

- ------- End of Forwarded Message

------- End of Forwarded Message

Date: Tue, 16 Oct 2001 13:19:09 +0200 (W. Europe Daylight Time)
From: Yong Jiang <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Subject: Re: why same BGP updates
Sender: [email-masked]

> "Duplicate" updates are a normal part of BGP operation. They are an artifact
> of the way most vendors maintain state and implement MinRouteAdver timers.

Do you mean that if the MinRouteAdver timer expires and if the router has
nothing new to update, then it will send duplicates to its peers? Even if
so, the receiving peers don't need to further propogate them.

/Yong
>
> For more information, see
> http://www.ietf.org/internet-drafts/draft-ietf-bmwg-bgpbas-00.txt
> http://www.acm.org/pubs/citations/journals/ton/2001-9-3/p293-labovitz/
>
> - Craig
>
> ----- Original Message -----
> From: "Yong Jiang" <[email-masked]>
> To: <[email-masked]>
> Sent: Monday, October 15, 2001 11:43 AM
> Subject: why same BGP updates
>
>
> > Hi,
> >
> > In a probe logging BGP updates from another EBGP peer, I found there are
> > concecutive BGP announcement messages with exactly the same attribute
> > values (next hop, AS path, etc) for the same prefix, except the arrival
> time is
> > different.
> >
> > One of the reasons I can suspect is that the origin AS uses
> > confederation, and when there is an internal change in the origin AS, the
> > border router drops the private ASes in the AS path. That's why to the
> > external peers the updates are exactly the same. I wonder if my
> > speculation is right? And is there any other situation that can result in
> > a BGP peer sending updates for a common prefix with exactly the same
> > attribute values? Doesn't "update" mean there is something new to update?
>

-- 
----------------------------------------------------
Yong Jiang		Phone: +46 8 713 8125
Telia Research AB	Mobile: +46 70 3487200
Network Services	Fax: +46 8 713 8320
123 86 Farsta		Email: [email-masked]
Sweden

----------------------------------------------------

From: "Guna Ramireddy" <[email-masked]>
To: <[email-masked]>
Subject: test, please ignore
Date: Mon, 15 Oct 2001 21:22:54 -0700
Importance: Normal
Sender: [email-masked]

Date: Mon, 15 Oct 2001 22:24:50 -0400
From: Greg Hankins <[email-masked]>
To: [email-masked]
Subject: Re: Last Call
Reply-To: [email-masked]
Sender: [email-masked]

I've been wondering about the BGP Timers section for some time.  RFC 1771 and
draft-ietf-idr-bgp4-14.txt specifies that all timers MUST be configurable.
I'm not aware of any implementation that fully supports this requirement.

I think the section should be updated to reflect today's implementation
practices.  Most implementations that I've used only support configuring
the Hold Time, and a few support configuring the KeepAlive timer as well.

The other thing that I noticed is most of the implementations that I've used,
with one exception, use a default Hold Time of 180 and KeepAlive timer of
60 seconds.  I'm sure there was a reason for suggesting the values of 90 and
30 seconds respectively when the draft was first written, but is that reason
still valid today?  I suggest that the values be changed to reflect reality.

Suggested changes:

6.4 BGP Timers

   BGP employs five timers: ConnectRetry, Hold Time, KeepAlive,
   MinASOriginationInterval, and MinRouteAdvertisementInterval The
   suggested value for the ConnectRetry timer is 120 seconds.  The
   suggested value for the Hold Time is 180 seconds.  The suggested value
   for the KeepAlive timer is 60 seconds.  The suggested value for the
   MinASOriginationInterval is 15 seconds.  The suggested value for the
   MinRouteAdvertisementInterval is 30 seconds.

   An implementation of BGP MUST allow the Hold Time to be configurable
   and MAY allow the other timers to be configurable.

Greg

-- 
Greg Hankins <[email-masked]> | Riverstone Networks, Inc.
Corporate Systems Engineering             | 3600 Mansell Road
http://www.riverstonenet.com/             | Suite 125             
+1 404 434 0355                           | Alpharetta, GA 30022

To: Yakov Rekhter <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked], [email-masked]
Subject: Re: Last Call 
Date: Mon, 15 Oct 2001 18:45:46 -0700
From: Enke Chen <[email-masked]>
Sender: [email-masked]

Hi, Yakov:
Just noticed that Sect. 9.2.1.1 "Breaking Ties (Internal Updates)" is
not consistent with Section 9.1.2.2 "Breaking Ties (Phase 2)". It also
seems redundant.

So I suggest that Sect. 9.2.1.1 be removed.

Thanks.  -- Enke

> Message-Id: <[email-masked]>
> To: [email-masked]
> Cc: [email-masked], [email-masked]
> Subject: Last Call
> Date: Mon, 15 Oct 2001 18:37:06 -0700
> From: Yakov Rekhter <[email-masked]>
> Sender: [email-masked]
> Precedence: bulk
> 
> Folks,
> 
> This is to start the IDR WG Last Call on advancing
> draft-ietf-idr-bgp4-14.txt to Draft Standard. The Last
> Call ends on 10/29.
> 
> Yakov.
> ------- Forwarded Message
> 
> Date:    Mon, 15 Oct 2001 07:01:50 -0400
> From:    [email-masked]
> To:      IETF-Announce: ;
> cc:      [email-masked] (subscribed members only)
> Subject: I-D ACTION:draft-ietf-idr-bgp4-14.txt
> 
> - --NextPart
> 
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> This draft is a work item of the Inter-Domain Routing Working Group of the IETF
> .
> 
> 	Title		: A Border Gateway Protocol 4 (BGP-4)
> 	Author(s)	: Y. Rekhter, T. Li
> 	Filename	: draft-ietf-idr-bgp4-14.txt
> 	Pages		: 61
> 	Date		: 12-Oct-01
> 	
> The Border Gateway Protocol (BGP) is an inter-Autonomous System
> routing protocol.  It is built on experience gained with EGP as
> defined in RFC 904 [1] and EGP usage in the NSFNET Backbone as
> described in RFC 1092 [2] and RFC 1093 [3].
> 
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-idr-bgp4-14.txt
> 
> To remove yourself from the IETF Announcement list, send a message to 
> ietf-announce-request with the word unsubscribe in the body of the message.
> 
> Internet-Drafts are also available by anonymous FTP. Login with the username
> "anonymous" and a password of your e-mail address. After logging in,
> type "cd internet-drafts" and then
> 	"get draft-ietf-idr-bgp4-14.txt".
> 
> A list of Internet-Drafts directories can be found in
> http://www.ietf.org/shadow.html 
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> 

To: [email-masked]
Cc: [email-masked], [email-masked]
Subject: Last Call
Date: Mon, 15 Oct 2001 18:37:06 -0700
From: Yakov Rekhter <[email-masked]>
Sender: [email-masked]

Folks,

This is to start the IDR WG Last Call on advancing
draft-ietf-idr-bgp4-14.txt to Draft Standard. The Last
Call ends on 10/29.

Yakov.
------- Forwarded Message

Date:    Mon, 15 Oct 2001 07:01:50 -0400
From:    [email-masked]
To:      IETF-Announce: ;
cc:      [email-masked] (subscribed members only)
Subject: I-D ACTION:draft-ietf-idr-bgp4-14.txt

- --NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Inter-Domain Routing Working Group of the IETF
.

	Title		: A Border Gateway Protocol 4 (BGP-4)
	Author(s)	: Y. Rekhter, T. Li
	Filename	: draft-ietf-idr-bgp4-14.txt
	Pages		: 61
	Date		: 12-Oct-01
	
The Border Gateway Protocol (BGP) is an inter-Autonomous System
routing protocol.  It is built on experience gained with EGP as
defined in RFC 904 [1] and EGP usage in the NSFNET Backbone as
described in RFC 1092 [2] and RFC 1093 [3].

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-idr-bgp4-14.txt

To remove yourself from the IETF Announcement list, send a message to 
ietf-announce-request with the word unsubscribe in the body of the message.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-idr-bgp4-14.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-idr-bgp4-14.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

- --NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

- --OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[email-masked]"

Content-Type: text/plain
Content-ID:	<[email-masked]>

ENCODING mime
FILE /internet-drafts/draft-ietf-idr-bgp4-14.txt

- --OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-idr-bgp4-14.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[email-masked]>

- --OtherAccess--

- --NextPart--

------- End of Forwarded Message

To: [email-masked]
Cc: abha ahuja <[email-masked]>, [email-masked]
Subject: revised IDR WG charter
Date: Mon, 15 Oct 2001 15:23:04 -0700
From: Yakov Rekhter <[email-masked]>
Sender: [email-masked]

Folks,

Attached is the most current version of the IDR WG charter.  The
IESG suggested to post it to the mailing list to get comments in
case it misses anything, etc... 

The deadline for comments is two weeks (10/29).

Yakov.
---------------------------------------------------------------

Inter-Domain Routing (idr)

Chair(s):

Susan Hares <[email-masked]>
Y Rekhter <[email-masked]>

Routing Area Director(s):

Rob Coltun <[email-masked]>
Abha Ahuja <[email-masked]>

Routing Area Advisor:

Abha Ahuja <[email-masked]>

Technical Advisor(s):

Jonathan Saperia <[email-masked]>

Mailing Lists:

General Discussion:[email-masked] (must be subscribed to idr-post to post
messages)
To Subscribe: [email-masked]
In Body: subscribe idr-post
         subscribe idr
Archive: ftp://ftp.merit.edu/mail.archives/idr

Description of Working Group:

The Technical Advisor listed above advises the WG on technical matters
related to all the MIB work in this WG.

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 include:

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

- - Advance RFC 2842, BGP Capability Advertisement, to Draft Standard.

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

- - The existing BGP MIBs (RFC 1657) are not current with regards to
  BGP4. Produce a revised MIB that matches revised BGP4 document and
  move RFC 1657 to Historic.

- - Produce MIBS for AS Confederations, Route Reflection, and
  Communities.

- - Review and evaluate  Multiprotocol BGP (RFC 2858) for advancement as
  Draft Standard, develop MIBs that support it.

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

- - Progress a BGP Graceful Restart mechanism along standards track.

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:

Oct 01  Initial ID for  MPBGP MIB

Nov 01  Submit to BGP Capability Advertisement to the IESG.

Nov 01 Submit 4 BGP MIBs to IESG.

Nov 01 Submit BGP4 document to IESG.

Nov 01 Initial Draft for  RFC2858 (if needed)

Nov 01 BGP TCP MD5 signatures document to IESG.

Dec 01 Submit Extended Communities draft to IESG.

Dec 01 Submit 4-byte AS ID to IESG.

Dec 01 Outbound Route Filter, Prefix and ASpath ORF draft to IESG.

Feb 02 Advance BGP Graceful Restart to Proposed Standard

From: <[email-masked]>
To: "Yong Jiang" <[email-masked]>
Cc: <[email-masked]>
Subject: Re: why same BGP updates
Date: Mon, 15 Oct 2001 18:33:00 -0400
Sender: [email-masked]

"Duplicate" updates are a normal part of BGP operation. They are an artifact
of the way most vendors maintain state and implement MinRouteAdver timers.

For more information, see
http://www.ietf.org/internet-drafts/draft-ietf-bmwg-bgpbas-00.txt
http://www.acm.org/pubs/citations/journals/ton/2001-9-3/p293-labovitz/

- Craig

> ----- Original Message -----
> From: "Yong Jiang" <[email-masked]>
> To: <[email-masked]>
> Sent: Monday, October 15, 2001 11:43 AM
> Subject: why same BGP updates
>
>
> Hi,
>
> In a probe logging BGP updates from another EBGP peer, I found there are
> concecutive BGP announcement messages with exactly the same attribute
> values (next hop, AS path, etc) for the same prefix, except the arrival
> time is different.
>
> One of the reasons I can suspect is that the origin AS uses
> confederation, and when there is an internal change in the origin AS, the
> border router drops the private ASes in the AS path. That's why to the
> external peers the updates are exactly the same. I wonder if my
> speculation is right? And is there any other situation that can result in
> a BGP peer sending updates for a common prefix with exactly the same
> attribute values? Doesn't "update" mean there is something new to update?

Date: Mon, 15 Oct 2001 17:43:54 +0200 (CEST)
From: Yong Jiang <[email-masked]>
To: [email-masked]
Subject: why same BGP updates
Sender: [email-masked]

Hi,

In a probe logging BGP updates from another EBGP peer, I found there are
concecutive BGP announcement messages with exactly the same attribute
values (next hop, AS path, etc) for the same prefix, except the arrival time is
different.

One of the reasons I can suspect is that the origin AS uses
confederation, and when there is an internal change in the origin AS, the
border router drops the private ASes in the AS path. That's why to the
external peers the updates are exactly the same. I wonder if my
speculation is right? And is there any other situation that can result in
a BGP peer sending updates for a common prefix with exactly the same
attribute values? Doesn't "update" mean there is something new to update?

/Yong
--
+46 8 713 8125 (office)
+46 70 3487200 (mobile)

From: "Yong Jiang" <[email-masked]>
To: <[email-masked]>
Subject: test
Date: Fri, 12 Oct 2001 22:20:03 +0200
Sender: [email-masked]

This is a multi-part message in MIME format.

------=_NextPart_000_0036_01C1536C.0A05A500
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

------=_NextPart_000_0036_01C1536C.0A05A500
Content-Type: text/html;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 5.50.4207.2601" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</DIV></BODY></HTML>

------=_NextPart_000_0036_01C1536C.0A05A500--

Date: Thu, 11 Oct 2001 19:22:59 -0700 (PDT)
From: Dan Pei <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Subject: Re: draft-ietf-idr-bgp4-13.txt 
Sender: [email-masked]

Hi,

|9.1.2.2 Breaking Ties (Phase 2)
|
|
|   In its Adj-RIBs-In a BGP speaker may have several routes to the same
|   destination that have the same degree of preference. The local
|   speaker can select only one of these routes for inclusion in the
|   associated Loc-RIB. The local speaker considers all routes with the
|   same degrees of preference, both those received from internal peers,
|   and those received from external peers.
|
|   The following tie-breaking procedure assumes that for each candidate
|   route all the BGP speakers within an autonomous system can ascertain
|   the cost of a path (interior distance) to the address depicted by the
|   NEXT_HOP attribute of the route, and follow the same route selection
|   algorithm.
|
|   The tie-breaking algorithm begins by considering all equally
|   preferable routes to the same destination, and then selects routes to
|   be removed from consideration. The algorithm terminates as soon as
|   only one route remains in consideration.  The criteria must be
|   applied in the order specified.

The draft assumes that interior distance to NEXT_HOP can be assertained by
all the BGP speakers. Is it possible that this is not true in some
practical scenario? If so, what's the correct behavior:

         -ignore the rule of prefering lower interior cost to NEXT_HOP
         -assign the highest interior cost to the NEXT_HOP if its
 	 interior distance is not available

It seems better to me if we could clarify this either in the second
paragraph of this section, or in the the paragraph where this rule
is stated.

Thanks,

---
Dan

To: abha ahuja <[email-masked]>
Cc: [email-masked]
Subject: Re: 2842 to Draft Standard 
Date: Thu, 11 Oct 2001 09:22:18 -0700
From: Yakov Rekhter <[email-masked]>
Sender: [email-masked]

Abha,

> Folks,
> 
> This is to start the IDR WG Last Call on advancing RFC 2842
> (Capabilities Advertisement with BGP-4) to Draft Standard. The Last
> Call ends in 2 weeks (Oct 9).

The IDR WG would like to ask the IESG to advance RFC2842 to
Draft Standard. The only change to the document would be to
replace in Section 3 the following sentence:

   The Data field in the NOTIFICATION
   message lists the set of capabilities that cause the speaker to send
   the message. 

with 

   The Data field in the NOTIFICATION
   message SHOULD list the set of capabilities that cause the speaker to send
   the message. 

This change is to make the above sentence consistent with the last
paragraph in Section 1.

The following is the list of some of the implementations of rfc2842:

Ericsson:
Interoperates with: Cisco, Juniper

Juniper Networks
Interoperates with: Cisco

Laurel Networks:
Interoperates with: Cisco, Juniper

NetPlane Systems Inc.
Interoperates with: Cisco, Juniper

Redback
Interoperates with: Cisco, Juniper

Riverstone:
Interoperates with: Cisco, Juniper, Zebra, Foundry

Unisphere Networks:
Interoperates with: Cisco, Juniper 

Yakov.

Date: Wed, 10 Oct 2001 15:22:29 -0400
To: Enke Chen <[email-masked]>
From: Susan Hares <[email-masked]>
Subject: Re: how to define new path attributes? 
Cc: xingqqbgp <[email-masked]>, [email-masked]
Sender: [email-masked]

Enke:

How many ways do people use the Extended communities
attribute fields?   Can you list a few?

Sue

At 10:31 AM 10/9/2001 -0700, Enke Chen wrote:
>Hi,
>If an existing attribute (e.g., community or extended community) can
>accomplish what you try to do, clearly you do not need to define a
>new path attribute and a new path attribute would not be justified.
>
>-- Enke
>
> > Date: Tue, 9 Oct 2001 08:50:12 +0800
> > From: xingqqbgp <[email-masked]>
> > X-Mailer: The Bat! (v1.53d)
> > Reply-To: xingqqbgp <[email-masked]>
> > Organization: BUPT-SBELL Uni-Center
> > X-Priority: 3 (Normal)
> > Message-ID: <[email-masked]>
> > To: [email-masked]
> > Subject: how to define new path attributes?
> > MIME-Version: 1.0
> >
> > Hello idr,
> >
> >   I'm working on a MPLS project now,and I'm responsible for
> >   the BGP4 module.But I meet some difficulties.Some new path
> >   attributes are needed in my BGP4 module.In other words,they
> >   are vendor-specific path attributes.I searched out all of
> >   the BGP4 documents,but found nothing about how to use vendor-
> >   specific path attributes.I've supposed that path attribute
> >   type 128~255 are for vendor use.But none of the RFCs and drafts
> >   proves that.Now I have to use the EXTENDED_COMMUNITY path
> >   attribute to hold them(The new attributes are not for routing
> >   policy).I don't know if it is legal.
> >
> >   Would you please give me some suggestion about it?How to define
> >   new path attributes?If can't,then can I put them into the
> >   EXTENDED_COMMUNITY path attribute?
> >
> >   Looking forward for your replying,and thanks a lot.
> >
> > --
> > Best regards,
> >  xingqqbgp                          mailto:[email-masked]
> >

From: Katia Linker <[email-masked]>
To: [email-masked], [email-masked], [email-masked]
Subject: OPEN message
Date: Wed, 10 Oct 2001 09:16:30 +0200
Sender: [email-masked]

Hi, all !
Regards sending and receiving an OPEN message.
According to FSM described in RFC 1771, a BGP speaker 
ignore any incoming OPEN messages untill it moves to 
OpenSent state, which means untill speaker itself sent 
an OPEN message. So my question is if I'm BGP speaker
and I didn't send any OPEN msg yet, but some of my peers
sent me an OPEN msg, I ignore this message and it is lost.
Should this peer of mine after sending an OPEN start some additional
timer and if it won't get a KEEPALIVE confirming his OPEN after
some interval of time, it will send an OPEN again ? Is it correct ?

   Waiting for your answers.
      Thanks in advance
         Katya

To: xingqqbgp <[email-masked]>
Cc: [email-masked]
Subject: Re: how to define new path attributes? 
Date: Tue, 09 Oct 2001 10:31:23 -0700
From: Enke Chen <[email-masked]>
Sender: [email-masked]

Hi,
If an existing attribute (e.g., community or extended community) can
accomplish what you try to do, clearly you do not need to define a
new path attribute and a new path attribute would not be justified. 

-- Enke

> Date: Tue, 9 Oct 2001 08:50:12 +0800
> From: xingqqbgp <[email-masked]>
> X-Mailer: The Bat! (v1.53d)
> Reply-To: xingqqbgp <[email-masked]>
> Organization: BUPT-SBELL Uni-Center
> X-Priority: 3 (Normal)
> Message-ID: <[email-masked]>
> To: [email-masked]
> Subject: how to define new path attributes?
> MIME-Version: 1.0
> 
> Hello idr,
> 
>   I'm working on a MPLS project now,and I'm responsible for
>   the BGP4 module.But I meet some difficulties.Some new path
>   attributes are needed in my BGP4 module.In other words,they
>   are vendor-specific path attributes.I searched out all of
>   the BGP4 documents,but found nothing about how to use vendor-
>   specific path attributes.I've supposed that path attribute
>   type 128~255 are for vendor use.But none of the RFCs and drafts
>   proves that.Now I have to use the EXTENDED_COMMUNITY path
>   attribute to hold them(The new attributes are not for routing
>   policy).I don't know if it is legal.
> 
>   Would you please give me some suggestion about it?How to define
>   new path attributes?If can't,then can I put them into the
>   EXTENDED_COMMUNITY path attribute?
> 
>   Looking forward for your replying,and thanks a lot.
> 
> -- 
> Best regards,
>  xingqqbgp                          mailto:[email-masked]
> 

Date: Tue, 9 Oct 2001 11:00:14 -0400
From: Jeffrey Haas <[email-masked]>
To: xingqqbgp <[email-masked]>
Cc: [email-masked]
Subject: Re: how to define new path attributes?
Sender: [email-masked]

Depending on the nature of your attribute, you can use 255
per rfc2042 for development purposes.  You should use a 
path attribute if the item in question is common to a set of
routes.  If it is particular to a prefix, you may want to consider
custom NLRI in MPBGP using private SAFI's.

On Tue, Oct 09, 2001 at 08:50:12AM +0800, xingqqbgp wrote:
>   I'm working on a MPLS project now,and I'm responsible for
>   the BGP4 module.But I meet some difficulties.Some new path
>   attributes are needed in my BGP4 module.In other words,they
>   are vendor-specific path attributes.I searched out all of
>   the BGP4 documents,but found nothing about how to use vendor-
>   specific path attributes.I've supposed that path attribute
>   type 128~255 are for vendor use.But none of the RFCs and drafts
>   proves that.Now I have to use the EXTENDED_COMMUNITY path
>   attribute to hold them(The new attributes are not for routing
>   policy).I don't know if it is legal.
> 
>   Would you please give me some suggestion about it?How to define
>   new path attributes?If can't,then can I put them into the
>   EXTENDED_COMMUNITY path attribute?
> 
>   Looking forward for your replying,and thanks a lot.
> 
> -- 
> Best regards,
>  xingqqbgp                          mailto:[email-masked]
> 
> 

-- 
Jeff Haas 
NextHop Technologies

Date: Tue, 9 Oct 2001 08:50:12 +0800
From: xingqqbgp <[email-masked]>
Reply-To: xingqqbgp <[email-masked]>
Organization: BUPT-SBELL Uni-Center
To: [email-masked]
Subject: how to define new path attributes?
Sender: [email-masked]

Hello idr,

  I'm working on a MPLS project now,and I'm responsible for
  the BGP4 module.But I meet some difficulties.Some new path
  attributes are needed in my BGP4 module.In other words,they
  are vendor-specific path attributes.I searched out all of
  the BGP4 documents,but found nothing about how to use vendor-
  specific path attributes.I've supposed that path attribute
  type 128~255 are for vendor use.But none of the RFCs and drafts
  proves that.Now I have to use the EXTENDED_COMMUNITY path
  attribute to hold them(The new attributes are not for routing
  policy).I don't know if it is legal.

  Would you please give me some suggestion about it?How to define
  new path attributes?If can't,then can I put them into the
  EXTENDED_COMMUNITY path attribute?

  Looking forward for your replying,and thanks a lot.

-- 
Best regards,
 xingqqbgp                          mailto:[email-masked]

Date: Mon, 8 Oct 2001 09:00:34 -0400 (EDT)
From: Susan Harris <[email-masked]>
To: xingqqbgp <[email-masked]>
Cc: [email-masked]
Subject: Re: how many mailing lists?
Sender: [email-masked]

>   In the website of ietf,I found that there are at least 3 mailing
>   lists about BGP4.They are [email-masked],[email-masked],[email-masked].

I can't speak for the ANS list, but [email-masked] is an old list that
we're about to send into oblivion ... Thanks for reminding us about it.

Date: Mon, 8 Oct 2001 08:50:40 -0400 (EDT)
From: Russ White <[email-masked]>
Reply-To: Russ White <[email-masked]>
To: Enke Chen <[email-masked]>
Cc: Dan Pei <[email-masked]>, Yakov Rekhter <[email-masked]>, enke Mathew Richardson <[email-masked]>, [email-masked], [email-masked]
Subject: Re: draft-ietf-idr-bgp4-13.txt 
Sender: [email-masked]

I'd say let's swap them as well. It would make the text clearer,
and match what I think most people have implemented.

:-)

Russ

On Sat, 6 Oct 2001, Enke Chen wrote:

> Dan:
> As the draft is being revised to reflect reality much more closely, it seems to be
> a good idea to swap the ordering of "external" and "igp metric" for route selection
> in the draft.
> 
> There is one more place in the draft that does not reflect the reality:
> 
>      In the pseudo-code above, MED(n) is a function which returns the
>      value of route n's MULTI_EXIT_DISC attribute. If route n has no
>      MULTI_EXIT_DISC attribute, the function returns the highest
>      possible MULTI_EXIT_DISC value, i.e. 2^32-1.
> 
> Missing MEDs are treated as 0 in reality. It seems to me that this text should
> be revised as well.
> 
> -- Enke
> 
> > Date: Thu, 4 Oct 2001 17:52:38 -0700 (PDT)
> > From: Dan Pei <[email-masked]>
> > To: Yakov Rekhter <[email-masked]>
> > Cc: Mathew Richardson <[email-masked]>, <[email-masked]>,
> > 	<[email-masked]>
> > Subject: Re: draft-ietf-idr-bgp4-13.txt 
> > In-Reply-To: <[email-masked]>
> > Message-ID: <[email-masked]>
> > MIME-Version: 1.0
> > Content-Type: TEXT/PLAIN; charset=US-ASCII
> > Sender: [email-masked]
> > Precedence: bulk
> > 
> > Yakov,
> > 
> > > > 9.1.2.2 Breaking Ties (Phase 2)
> > > >
> > > > <snip>
> > > >
> > > > >      a) Remove from consideration routes with less-preferred
> > > > >      MULTI_EXIT_DISC attributes. MULTI_EXIT_DISC is only comparable
> > > > >      between routes learned from the same neighboring AS. Routes which
> > > > >      do not have the MULTI_EXIT_DISC attribute are considered to have
> > > > >      the highest possible MULTI_EXIT_DISC value.
> > > > >
> > > > >      This is also described in the following procedure:
> > > > >
> > > > >            for m = all routes still under consideration
> > > > >                for n = all routes still under consideration
> > > > >                    if (neighborAS(m) == neighborAS(n)) and (MED(n) < MED(m)
> > > )
> > > > >                        remove route m from consideration
> > > > >
> > > > >      In the pseudo-code above, MED(n) is a function which returns the
> > > > >      value of route n's MULTI_EXIT_DISC attribute. If route n has no
> > > > >      MULTI_EXIT_DISC attribute, the function returns the highest
> > > > >      possible MULTI_EXIT_DISC value, i.e. 2^32-1.
> > > > >
> > > > >      Similarly, neighborAS(n) is a function which returns the neighbor
> > > > >      AS from which the route was received.
> > > > >
> > > > >      b) Remove from consideration any routes with less-preferred
> > > > >      interior cost.  The interior cost of a route is determined by
> > > > >      calculating the metric to the next hop for the route using the
> > > > >      Routing Table. If the next hop for a route is reachable, but no
> > > > >      cost can be determined, then this step should be skipped
> > > > >      (equivalently, consider all routes to have equal costs).
> > > > >
> > > > >      This is also described in the following procedure.
> > > > >
> > > > >            for m = all routes still under consideration
> > > > >                for n = all routes in still under consideration
> > > > >                    if (cost(n) is better than cost(m))
> > > > >                        remove m from consideration
> > > > >
> > > > >      In the pseudo-code above, cost(n) is a function which returns the
> > > > >      cost of the path (interior distance) to the address given in the
> > > > >      NEXT_HOP attribute of the route.
> > > > >
> > > > >      c) If at least one of the candidate routes was received from an
> > > > >      external peer in a neighboring autonomous system, remove from
> > > > >      consideration all routes which were received from internal peers.
> > > > >
> > > > >      d) Remove from consideration all routes other than the route that
> > > > >      was advertised by the BGP speaker whose BGP Identifier has the
> > > > >      lowest value.
> > > >
> > > > There is no mention here of breaking ties based on AS Path length,
> > > > or Origin type, both of which are widely deployed methods of
> > > > breaking ties.  I propose that these be added as the first step
> > > > of the tie-breaking process:
> > > >
> > > > 	a) Remove from consideration all routes which are not tied
> > > > 	for having the smallest number of AS numbers present in their
> > > > 	AS_PATH attributes.
> > > >
> > > > 	b) Remove from consideration all routes which are not tied
> > > > 	for having the lowest Origin number in their Origin attribute.
> > >
> > > In the absence of any objections from the folks on the list by
> > > 10/11 I'll add (a) and (b), as you suggested.
> > >
> > 
> > I am not sure it is appropriate or not to point it out, but here
> > is a question I asked before on the IDR mailing list:
> > 
> > The  "widely used tie-breaking rules" as shown in
> > 
> >          - http://www.cisco.com/warp/public/459/25.shtml   and
> >          - Internet Routing Architectures(Halabi)
> > 
> > the order to break ties when comparing paths is:
> >         ...
> >         7. prefer eBGP paths over iBGP paths
> >         8. prefer lowest IGP metric to the BGP next hop.
> >         ...
> > 
> > But in this draft, the order is:
> >         ...
> >         b)prefer lowest internal cost to BGP nexthop;
> >         c)prefer eBGP paths over iBGP paths.
> > 
> > If we've decided to add the ASPATH and ORIGIN into tie-breaking rules to
> > make the draft reflect the pratice, would it better to also fix this
> > problem ? More spefically, switch b) and c) of the draft?
> > 
> > Thanks,
> > 
> > ---
> > Dan
> > 
> 

_____________________________
[email-masked] <>< Grace Alone

Date: Mon, 8 Oct 2001 14:19:10 +0800
From: xingqqbgp <[email-masked]>
Reply-To: xingqqbgp <[email-masked]>
Organization: BUPT-SBELL Uni-Center
To: [email-masked]
Subject: how many mailing lists?
Sender: [email-masked]

Hello idr,

  In the website of ietf,I found that there are at least 3 mailing
  lists about BGP4.They are [email-masked],[email-masked],[email-masked].
  What are their differences?

  How to join [email-masked] & [email-masked].

-- 
Best regards,
 xingqqbgp                          mailto:[email-masked]

Date: Mon, 8 Oct 2001 00:44:31 -0400
From: Mathew Richardson <[email-masked]>
To: Dan Pei <[email-masked]>
Cc: [email-masked]
Subject: Re: draft-ietf-idr-bgp4-13.txt
Sender: [email-masked]

> Dan Pei <[email-masked]> [Fri, Oct 05, 2001 at 08:58:50PM -0700]:
>Hi, Jeffrey,
>
>On Fri, 5 Oct 2001, Jeffrey Haas wrote:

<snip>

>Yes, it does seem that in most cases the draft tie-breaking rules
>and the cisco rules will give you an identical result.
>
>But there are cases where they will differ.  In addition to the example
>you mention, multihop BGP is likely to produce different results(suppose
>there are a tie before conside these two rules):
>   - Cisco will always select the route from the multihop
>      eBGP peer (prefer eBGP over iBGP rule)
>   - the draft rules will select the iBGP route if the iBGP's
>      next hop is closer than the eBGP next hop (prefer lowest metric)
>
>How about keeping the existing draft order, but making the definition
>more explicit, like the following:
>
>Section 9.1.2.1
>
>b) Remove from consideration any routes with less-preferred interior cost.
>For routes learned via eBGP, the interior cost is the minimum IGP cost
>that would be associated with a directly connected network.  For routes
>learned via iBGP, the interior cost is determined by calculating the IGP
>metric to the  NEXT_HOP.  If no IGP metric can be determined, then
>this step should be skipped.
>
>Note that in most cases, the NEXT_HOP reported by eBGP NEXT_HOP will be a
>directly connected network. However in some scenarios such as multihop
>BGP, the eBGP NEXT_HOP may not be on a directly connected network and care
>should be taken to insure that interior cost used during the tie-breaking
>process is set to the minimum IGP cost of a directly connected network.

<snip>

Just to add my two cents, I would prefer swapping the two steps to
adding clarifying text for two reasons.  First, and primarily, the
"swapped" behaviour matches reality.  Second, the clarification,
I think, is intended to provide the same behaviour as if the
order were swapped... if that's the case, why not just swap them?

mrr

To: Dan Pei <[email-masked]>
Cc: Yakov Rekhter <[email-masked]>, enke Mathew Richardson <[email-masked]>, [email-masked], [email-masked]
Subject: Re: draft-ietf-idr-bgp4-13.txt 
Date: Sat, 06 Oct 2001 13:47:22 -0700
From: Enke Chen <[email-masked]>
Sender: [email-masked]

Dan:
As the draft is being revised to reflect reality much more closely, it seems to be
a good idea to swap the ordering of "external" and "igp metric" for route selection
in the draft.

There is one more place in the draft that does not reflect the reality:

     In the pseudo-code above, MED(n) is a function which returns the
     value of route n's MULTI_EXIT_DISC attribute. If route n has no
     MULTI_EXIT_DISC attribute, the function returns the highest
     possible MULTI_EXIT_DISC value, i.e. 2^32-1.

Missing MEDs are treated as 0 in reality. It seems to me that this text should
be revised as well.

-- Enke

> Date: Thu, 4 Oct 2001 17:52:38 -0700 (PDT)
> From: Dan Pei <[email-masked]>
> To: Yakov Rekhter <[email-masked]>
> Cc: Mathew Richardson <[email-masked]>, <[email-masked]>,
> 	<[email-masked]>
> Subject: Re: draft-ietf-idr-bgp4-13.txt 
> In-Reply-To: <[email-masked]>
> Message-ID: <[email-masked]>
> MIME-Version: 1.0
> Content-Type: TEXT/PLAIN; charset=US-ASCII
> Sender: [email-masked]
> Precedence: bulk
> 
> Yakov,
> 
> > > 9.1.2.2 Breaking Ties (Phase 2)
> > >
> > > <snip>
> > >
> > > >      a) Remove from consideration routes with less-preferred
> > > >      MULTI_EXIT_DISC attributes. MULTI_EXIT_DISC is only comparable
> > > >      between routes learned from the same neighboring AS. Routes which
> > > >      do not have the MULTI_EXIT_DISC attribute are considered to have
> > > >      the highest possible MULTI_EXIT_DISC value.
> > > >
> > > >      This is also described in the following procedure:
> > > >
> > > >            for m = all routes still under consideration
> > > >                for n = all routes still under consideration
> > > >                    if (neighborAS(m) == neighborAS(n)) and (MED(n) < MED(m)
> > )
> > > >                        remove route m from consideration
> > > >
> > > >      In the pseudo-code above, MED(n) is a function which returns the
> > > >      value of route n's MULTI_EXIT_DISC attribute. If route n has no
> > > >      MULTI_EXIT_DISC attribute, the function returns the highest
> > > >      possible MULTI_EXIT_DISC value, i.e. 2^32-1.
> > > >
> > > >      Similarly, neighborAS(n) is a function which returns the neighbor
> > > >      AS from which the route was received.
> > > >
> > > >      b) Remove from consideration any routes with less-preferred
> > > >      interior cost.  The interior cost of a route is determined by
> > > >      calculating the metric to the next hop for the route using the
> > > >      Routing Table. If the next hop for a route is reachable, but no
> > > >      cost can be determined, then this step should be skipped
> > > >      (equivalently, consider all routes to have equal costs).
> > > >
> > > >      This is also described in the following procedure.
> > > >
> > > >            for m = all routes still under consideration
> > > >                for n = all routes in still under consideration
> > > >                    if (cost(n) is better than cost(m))
> > > >                        remove m from consideration
> > > >
> > > >      In the pseudo-code above, cost(n) is a function which returns the
> > > >      cost of the path (interior distance) to the address given in the
> > > >      NEXT_HOP attribute of the route.
> > > >
> > > >      c) If at least one of the candidate routes was received from an
> > > >      external peer in a neighboring autonomous system, remove from
> > > >      consideration all routes which were received from internal peers.
> > > >
> > > >      d) Remove from consideration all routes other than the route that
> > > >      was advertised by the BGP speaker whose BGP Identifier has the
> > > >      lowest value.
> > >
> > > There is no mention here of breaking ties based on AS Path length,
> > > or Origin type, both of which are widely deployed methods of
> > > breaking ties.  I propose that these be added as the first step
> > > of the tie-breaking process:
> > >
> > > 	a) Remove from consideration all routes which are not tied
> > > 	for having the smallest number of AS numbers present in their
> > > 	AS_PATH attributes.
> > >
> > > 	b) Remove from consideration all routes which are not tied
> > > 	for having the lowest Origin number in their Origin attribute.
> >
> > In the absence of any objections from the folks on the list by
> > 10/11 I'll add (a) and (b), as you suggested.
> >
> 
> I am not sure it is appropriate or not to point it out, but here
> is a question I asked before on the IDR mailing list:
> 
> The  "widely used tie-breaking rules" as shown in
> 
>          - http://www.cisco.com/warp/public/459/25.shtml   and
>          - Internet Routing Architectures(Halabi)
> 
> the order to break ties when comparing paths is:
>         ...
>         7. prefer eBGP paths over iBGP paths
>         8. prefer lowest IGP metric to the BGP next hop.
>         ...
> 
> But in this draft, the order is:
>         ...
>         b)prefer lowest internal cost to BGP nexthop;
>         c)prefer eBGP paths over iBGP paths.
> 
> If we've decided to add the ASPATH and ORIGIN into tie-breaking rules to
> make the draft reflect the pratice, would it better to also fix this
> problem ? More spefically, switch b) and c) of the draft?
> 
> Thanks,
> 
> ---
> Dan
> 

Date: Fri, 5 Oct 2001 20:58:50 -0700 (PDT)
From: Dan Pei <[email-masked]>
To: Jeffrey Haas <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>
Subject: Re: draft-ietf-idr-bgp4-13.txt
Sender: [email-masked]

Hi, Jeffrey,

On Fri, 5 Oct 2001, Jeffrey Haas wrote:

> I don't see any reason why they couldn't switch.  GateD implements
> the draft tie-breaking.  Ideally, "igp distance" to anything
> directly connected will be 0 or 1.  Any IGP should send a
> distance of at least 1.  In the case where directly attached
> interfaces are 1, there's a possible tie and it falls through to
> the internal vs. external case anyway.
>
> If directly attached interfaces don't have a cost of 0 or 1 then
> there may be an issue.

Yes, it does seem that in most cases the draft tie-breaking rules
and the cisco rules will give you an identical result.

But there are cases where they will differ.  In addition to the example
you mention, multihop BGP is likely to produce different results(suppose
there are a tie before conside these two rules):
   - Cisco will always select the route from the multihop
      eBGP peer (prefer eBGP over iBGP rule)
   - the draft rules will select the iBGP route if the iBGP's
      next hop is closer than the eBGP next hop (prefer lowest metric)

How about keeping the existing draft order, but making the definition
more explicit, like the following:

Section 9.1.2.1

b) Remove from consideration any routes with less-preferred interior cost.
For routes learned via eBGP, the interior cost is the minimum IGP cost
that would be associated with a directly connected network.  For routes
learned via iBGP, the interior cost is determined by calculating the IGP
metric to the  NEXT_HOP.  If no IGP metric can be determined, then
this step should be skipped.

Note that in most cases, the NEXT_HOP reported by eBGP NEXT_HOP will be a
directly connected network. However in some scenarios such as multihop
BGP, the eBGP NEXT_HOP may not be on a directly connected network and care
should be taken to insure that interior cost used during the tie-breaking
process is set to the minimum IGP cost of a directly connected network.

> On Thu, Oct 04, 2001 at 05:52:38PM -0700, Dan Pei wrote:
> > I am not sure it is appropriate or not to point it out, but here
> > is a question I asked before on the IDR mailing list:
> >
> > The  "widely used tie-breaking rules" as shown in
> >
> >          - http://www.cisco.com/warp/public/459/25.shtml   and
> >          - Internet Routing Architectures(Halabi)
> >
> > the order to break ties when comparing paths is:
> >         ...
> >         7. prefer eBGP paths over iBGP paths
> >         8. prefer lowest IGP metric to the BGP next hop.
> >         ...
> >
> > But in this draft, the order is:
> >         ...
> >         b)prefer lowest internal cost to BGP nexthop;
> >         c)prefer eBGP paths over iBGP paths.
> >
> > If we've decided to add the ASPATH and ORIGIN into tie-breaking rules to
> > make the draft reflect the pratice, would it better to also fix this
> > problem ? More spefically, switch b) and c) of the draft?
>
> --
> Jeff Haas
> NextHop Technologies
>

Thanks,
---
Dan

Date: Fri, 5 Oct 2001 18:15:41 -0700 (PDT)
From: Dilip Kumar <[email-masked]>
Subject: RFC-3107
To: [email-masked]
Sender: [email-masked]

Hello,
   I have a small question on withdrawing a BGP Route
from the BGP speaker which maintains multiple routes
to a destination. Please see the following text from
the RFC-3107

   "A BGP speaker can withdraw a previously advertised
   route (as well as the binding between this route
   and a label) by either (a) advertising a new route
   (and a label) with the same NLRI as the previously
   advertised route, or (b) listing the NLRI of the
   previously advertised route in the Withdrawn Routes
   field of an Update message. The label information
   carried (as part of NLRI) in the Withdrawn Routes
   field should be set to 0x800000." 

So the above text means that in the Withdrawn Routes
Field, the 'Label' will be set to '0x800000'.

Here is another para from the same RFC

   "In the case where a BGP speaker advertises
   multiple routes to a destination, if a route is 
   withdrawn, and a label(s) is specified at the time 
   of withdrawal, only the corresponding route with
the
   corresponding label is withdrawn.  If a route is
   withdrawn, and no label is specified at the time of
   withdrawal, then only the corresponding unlabeled
   route is withdrawn; the labeled routes are left in 
   place."

The above text assumes that a valid 'Label' will be
present in the Withdrawn Routes field.

  I think, the above 2 para of the RFC-3107
contradicts each other on the presence of 'Label' in
the Withdrawn Routes field. If both the para is taken
as correct, then the routes with label will never
(can't) be withdrawn.

Please clarify.

Thanks,
Dilip Kumar. 

__________________________________________________
Do You Yahoo!?
NEW from Yahoo! GeoCities - quick and easy web site hosting, just $8.95/month.
http://geocities.yahoo.com/ps/info1

Date: Fri, 5 Oct 2001 16:26:36 -0400
From: Jeffrey Haas <[email-masked]>
To: Dan Pei <[email-masked]>, [email-masked]
Subject: Re: draft-ietf-idr-bgp4-13.txt
Sender: [email-masked]

I don't see any reason why they couldn't switch.  GateD implements
the draft tie-breaking.  Ideally, "igp distance" to anything
directly connected will be 0 or 1.  Any IGP should send a
distance of at least 1.  In the case where directly attached
interfaces are 1, there's a possible tie and it falls through to
the internal vs. external case anyway.

If directly attached interfaces don't have a cost of 0 or 1 then
there may be an issue.  

On Thu, Oct 04, 2001 at 05:52:38PM -0700, Dan Pei wrote:
> I am not sure it is appropriate or not to point it out, but here
> is a question I asked before on the IDR mailing list:
> 
> The  "widely used tie-breaking rules" as shown in
> 
>          - http://www.cisco.com/warp/public/459/25.shtml   and
>          - Internet Routing Architectures(Halabi)
> 
> the order to break ties when comparing paths is:
>         ...
>         7. prefer eBGP paths over iBGP paths
>         8. prefer lowest IGP metric to the BGP next hop.
>         ...
> 
> But in this draft, the order is:
>         ...
>         b)prefer lowest internal cost to BGP nexthop;
>         c)prefer eBGP paths over iBGP paths.
> 
> If we've decided to add the ASPATH and ORIGIN into tie-breaking rules to
> make the draft reflect the pratice, would it better to also fix this
> problem ? More spefically, switch b) and c) of the draft?

-- 
Jeff Haas 
NextHop Technologies

Date: Thu, 4 Oct 2001 17:52:38 -0700 (PDT)
From: Dan Pei <[email-masked]>
To: Yakov Rekhter <[email-masked]>
Cc: Mathew Richardson <[email-masked]>, <[email-masked]>, <[email-masked]>
Subject: Re: draft-ietf-idr-bgp4-13.txt 
Sender: [email-masked]

Yakov,

> > 9.1.2.2 Breaking Ties (Phase 2)
> >
> > <snip>
> >
> > >      a) Remove from consideration routes with less-preferred
> > >      MULTI_EXIT_DISC attributes. MULTI_EXIT_DISC is only comparable
> > >      between routes learned from the same neighboring AS. Routes which
> > >      do not have the MULTI_EXIT_DISC attribute are considered to have
> > >      the highest possible MULTI_EXIT_DISC value.
> > >
> > >      This is also described in the following procedure:
> > >
> > >            for m = all routes still under consideration
> > >                for n = all routes still under consideration
> > >                    if (neighborAS(m) == neighborAS(n)) and (MED(n) < MED(m)
> )
> > >                        remove route m from consideration
> > >
> > >      In the pseudo-code above, MED(n) is a function which returns the
> > >      value of route n's MULTI_EXIT_DISC attribute. If route n has no
> > >      MULTI_EXIT_DISC attribute, the function returns the highest
> > >      possible MULTI_EXIT_DISC value, i.e. 2^32-1.
> > >
> > >      Similarly, neighborAS(n) is a function which returns the neighbor
> > >      AS from which the route was received.
> > >
> > >      b) Remove from consideration any routes with less-preferred
> > >      interior cost.  The interior cost of a route is determined by
> > >      calculating the metric to the next hop for the route using the
> > >      Routing Table. If the next hop for a route is reachable, but no
> > >      cost can be determined, then this step should be skipped
> > >      (equivalently, consider all routes to have equal costs).
> > >
> > >      This is also described in the following procedure.
> > >
> > >            for m = all routes still under consideration
> > >                for n = all routes in still under consideration
> > >                    if (cost(n) is better than cost(m))
> > >                        remove m from consideration
> > >
> > >      In the pseudo-code above, cost(n) is a function which returns the
> > >      cost of the path (interior distance) to the address given in the
> > >      NEXT_HOP attribute of the route.
> > >
> > >      c) If at least one of the candidate routes was received from an
> > >      external peer in a neighboring autonomous system, remove from
> > >      consideration all routes which were received from internal peers.
> > >
> > >      d) Remove from consideration all routes other than the route that
> > >      was advertised by the BGP speaker whose BGP Identifier has the
> > >      lowest value.
> >
> > There is no mention here of breaking ties based on AS Path length,
> > or Origin type, both of which are widely deployed methods of
> > breaking ties.  I propose that these be added as the first step
> > of the tie-breaking process:
> >
> > 	a) Remove from consideration all routes which are not tied
> > 	for having the smallest number of AS numbers present in their
> > 	AS_PATH attributes.
> >
> > 	b) Remove from consideration all routes which are not tied
> > 	for having the lowest Origin number in their Origin attribute.
>
> In the absence of any objections from the folks on the list by
> 10/11 I'll add (a) and (b), as you suggested.
>

I am not sure it is appropriate or not to point it out, but here
is a question I asked before on the IDR mailing list:

The  "widely used tie-breaking rules" as shown in

         - http://www.cisco.com/warp/public/459/25.shtml   and
         - Internet Routing Architectures(Halabi)

the order to break ties when comparing paths is:
        ...
        7. prefer eBGP paths over iBGP paths
        8. prefer lowest IGP metric to the BGP next hop.
        ...

But in this draft, the order is:
        ...
        b)prefer lowest internal cost to BGP nexthop;
        c)prefer eBGP paths over iBGP paths.

If we've decided to add the ASPATH and ORIGIN into tie-breaking rules to
make the draft reflect the pratice, would it better to also fix this
problem ? More spefically, switch b) and c) of the draft?

Thanks,

---
Dan

Date: Thu, 4 Oct 2001 13:57:59 -0400
From: Mathew Richardson <[email-masked]>
To: Yakov Rekhter <[email-masked]>
Cc: [email-masked]
Subject: Re: draft-ietf-idr-bgp4-13.txt
Sender: [email-masked]

> Yakov Rekhter <[email-masked]> [Thu, Oct 04, 2001 at 07:02:14AM -0700]:

<snip>

>> >3. Summary of Operation
>> >
>> >   Two systems form a transport protocol connection between one another.
>> >   They exchange messages to open and confirm the connection parameters.
>> >
>> >   The initial data flow is the entire BGP routing table. Incremental
>> >   updates are sent as the routing tables change. BGP does not require
>> >   periodic refresh of the entire BGP routing table. Therefore, a BGP
>> >   speaker must retain the current version of the entire BGP routing
>> >   tables of all of its peers for the duration of the connection.
>>  ---
>> >                                                                   If
>> >   the implementation decides to not store the routes that have been
>> >   received from a peer, but have been filtered out according to
>> >   configured local policy, the BGP Route Refresh option [12] may be
>> >   used to request the full set of routes from a peer without resetting
>> >   the BGP session when the local policy configuration changes.
>>  ---
>> 
>> This seems to imply that it's OK, with vanilla BGP, to not store all
>> learned routes.  
>
>Strictly speaking, vanilla BGP doesn't *have to* store all the
>routes that have been received from a peer, provided that it is
>willing to reset the BGP session when the local policy configuration
>changes.

That's true, but it's definitely not a good thing to flap your
peering sessions just because your local policy changed.  I think
that it's a mistake for the wording of the section to even imply this
as a choice, in the absence of an extension that allows you to avoid
flapping the peering session.

Additionally, I still don't like the idea of mentioning a specific
optional extension...  I think it's much better to simply say that
optional extensions may make this behaviour (not keeping routes that
were rejected due to policy) less damaging.

<snip>

>>       a) the originating speaker shall include its own AS number at least
>>       once in a path segment of type AS_SEQUENCE.  This segment shall
>>       be the leftmost element of the AS_PATH.  (In this case, the AS number
>>       of the originating speaker's autonomous system will be the only entry
>>       in the AS_PATH attribute).      
>
>I like Enke's suggestion that "instead of enumerating the scenarios for 
>AS stuffing in multiple places, we could add a couple of sentences in 
>the section that describes the AS-PATH attribute." So, I would appreciate
>if you and Enke would provide me with the text to cover this.

<snip>

Well, then, how about changing the second paragraph of section 5.1.2
to read:

   When a BGP speaker propagates a route which it has learned from
   another BGP speaker's UPDATE message, it shall modify the route's
   AS_PATH attribute based on the location of the BGP speaker to which
   the route will be sent  (NOTE: whenever the modification of the
   AS_PATH calls for including, or prepending the AS number of the
   local system, it shall be legal for the local system to prepend it's
   own AS number any number of times, but no less than once):

This still leaves the need for clarifying the type of segment that
is prepended when originating a route to an external peer:

       a) the originating speaker shall include its own AS number in
       a path segment of type AS_SEQUENCE in the AS_PATH attribute of
       all UPDATE messages sent to external peers.  This segment shall
       be the leftmost element of the AS_PATH.  (In this case, the AS
       number of the originating speaker's autonomous system will be the
       only AS number present in the AS_PATH attribute).

<snip>

>> >9. UPDATE Message Handling
>> 
>> <snip>
>> 
>> >   iii) If the new route has identical path attributes to an earlier
>> >   route contained in the Adj-RIB-In, and is more specific (see 9.1.4)
>> >   than the earlier route, no further actions are necessary.
>> 
>> This appears to be wrong, because of the ATOMIC_AGGREGATE attribute.
>> According to section 4.3, page 14:
>> 
>>         "ATOMIC_AGGREGATE ... is used by a BGP speaker to inform other
>>         BGP speakers that the local system selected a less specific
>>         route without selecting a more specific route which is included
>>         in it."
>> 
>> Then, in section 5.1.3, page 24:
>> 
>>         "If a BGP speaker, when presented with a set of overlapping
>>         routes from one of its peers ... selects the less specific route
>>         without selecting the more specific one, then the local system
>>         MUST attach the ATOMIC_AGGREGATE attribute to the route when
>>         propagating it to other BGP speakers ..."
>> 
>> So, when we receive a more specific route, we have to continue on and
>> decide whether to select it or not... then, if we choose not to select
>> it, we may need to readvertise the less specific route with the
>> ATOMIC_AGGREGATE attribute.
>> 
>> I propose simply striking this paragraph.
>
>The current text on ATOMIC_AGGREGATE isn't exactly correct. I would
>suggest to change 4.3 to the following:
>
>         ATOMIC_AGGREGATE ... is used by a BGP speaker to inform other
>         BGP speakers that the local system selected a less specific
>         route without selecting a more specific route which is included
>         in it, where the AS_PATH attribute of the more specific route
>         is different from the AS_PATH attribute of the less specific
>         route.

<snip>

I agree that this is much closer to the way ATOMIC_AGGREGATE should
be used, but this also includes differences solely in the layout of
the AS_PATH (different order, or differences in whether a particular
AS is represented in an AS_SET or an AS_SEQUENCE.)  How about:

         ATOMIC_AGGREGATE ... is used by a BGP speaker to inform other
         BGP speakers that the local system selected a less specific
         route without selecting a more specific route which is included
         in it, where the AS_PATH attribute of the more specific route
	 contains AS numbers not present in the AS_PATH attribute of
	 the less specific route.

This ensures that ATOMIC_AGGREGATE is included only when packets
forwarded using the less specific route may traverse ASes not listed
in the less specific route's AS_PATH.

>And also change 5.1.6 to the following:
>
>         "If a BGP speaker, when presented with a set of overlapping
>         routes from one of its peers ... selects the less specific route
>         without selecting the more specific one, and the AS_PATH attribute
>         of the less specific route is different from the AS_PATH attribute
>         of the more specific route, then the local system
>         MUST attach the ATOMIC_AGGREGATE attribute to the route when
>         propagating it to other BGP speakers ..."

<snip>

And here as well, I would prefer to see:

         "If a BGP speaker, when presented with a set of overlapping
         routes from one of its peers ... selects the less specific route
         without selecting the more specific one, and the AS_PATH attribute
         of the more specific route contains AS numbers not present in the
	 AS_PATH of the less specific route, then the local system MUST
	 attach the ATOMIC_AGGREGATE attribute to the route when
	 propagating it to other BGP speakers ..."

<snip>

>> >   Unfeasible routes SHALL be removed from the Loc-RIB and the routing
>> >   table. However, corresponding unfeasible routes SHOULD be kept in the
>> >   Adj-RIBs-In.

<snip>

>> Either way, I think that more information on which routes this statement
>> pertains to needs to be included...
>
>changed to:
>
>   Unresolvable routes SHALL be removed from the Loc-RIB and the routing
>   table. However, corresponding unresolvable routes SHOULD be kept in the
>   Adj-RIBs-In.

Sounds good.

<snip>

mrr

Date: Thu, 4 Oct 2001 11:39:51 -0400
From: Jeffrey Haas <[email-masked]>
To: Yakov Rekhter <[email-masked]>
Cc: [email-masked]
Subject: Re: draft-ietf-idr-bgp4-13.txt
Sender: [email-masked]

Yakov,

On Thu, Oct 04, 2001 at 07:02:14AM -0700, Yakov Rekhter wrote:
> The current text on ATOMIC_AGGREGATE isn't exactly correct. I would
> suggest to change 4.3 to the following:
> 
>          ATOMIC_AGGREGATE ... is used by a BGP speaker to inform other
>          BGP speakers that the local system selected a less specific
>          route without selecting a more specific route which is included
>          in it, where the AS_PATH attribute of the more specific route
>          is different from the AS_PATH attribute of the less specific
>          route.
> 
> And also change 5.1.6 to the following:
> 
>          "If a BGP speaker, when presented with a set of overlapping
>          routes from one of its peers ... selects the less specific route
>          without selecting the more specific one, and the AS_PATH attribute
>          of the less specific route is different from the AS_PATH attribute
>          of the more specific route, then the local system
>          MUST attach the ATOMIC_AGGREGATE attribute to the route when
>          propagating it to other BGP speakers ..."

My impression of ATOMIC_AGGREGATE has always been that it implies a
loss of path information.  I'm not certain the above text appropriately
reflects that.  Consider the following scenarios:

First scenario:

A BGP speaker receives a BGP route, R1(A) where A is an AS_PATH.
The same speaker receives R2(A), R2(B) where R2 is more specific
than R1.

If the speaker selects R1(A), R2(B), the proposed text would have R1(A)
sent with ATOMIC_AGGREGATE.  In my opinion, ATOMIC_AGGREGATE is only
approropate, for a given receiving peer, if R1(A) is present in
that peer's Adj-Ribs-Out and R2(B) is not.  If both routes are present,
then no path information has been lost.

Second scenario:

The speaker receives R1(A) and R2(B).  If R1(A) is selected to be
active and R2(B) is not (i.e. it is present in Adj-Ribs-In), we
are not utilizing R2(B) for forwarding purposes.  The proposed
text would have us attached ATOMIC_AGGREGATE.  However, since we are
not utilizing R2(B) for forwarding purposes, no path information is
lost.

related Third scenario:

The speaker receives R1(A), R2(A) and R2(B).  R1(A) is selected to
be active and no R2 are selected to be active.  By the proposed text,
we still send ATOMIC_AGGREGATE.

...

If I have the gist of ATOMIC_AGGREGATE, then talking about "selecting a
route" isn't quite accurate for conveying the loss of path information.
It has more to do with the presence of a more specific route in the
Loc-Rib that is not present in the Adj-Ribs-Out - i.e. we're using
something for forwarding that isn't present in Adj-Ribs-Out.

Does this sound right?

-- 
Jeff Haas 
NextHop Technologies

To: Mathew Richardson <[email-masked]>
Cc: [email-masked]
Subject: Re: draft-ietf-idr-bgp4-13.txt 
Date: Thu, 04 Oct 2001 07:02:14 -0700
From: Yakov Rekhter <[email-masked]>
Sender: [email-masked]

Mathew,

> I've put together a few of my comments/concerns on draft 13.  I've
> tried to leave out anything dealing exclusively with grammar/
> formatting/etc., and just deal with those places where I feel the
> draft is misleading, contradictory, or wrong.
> 
> <snip>
> 
> >3. Summary of Operation
> >
> >   Two systems form a transport protocol connection between one another.
> >   They exchange messages to open and confirm the connection parameters.
> >
> >   The initial data flow is the entire BGP routing table. Incremental
> >   updates are sent as the routing tables change. BGP does not require
> >   periodic refresh of the entire BGP routing table. Therefore, a BGP
> >   speaker must retain the current version of the entire BGP routing
> >   tables of all of its peers for the duration of the connection.
>  ---
> >                                                                   If
> >   the implementation decides to not store the routes that have been
> >   received from a peer, but have been filtered out according to
> >   configured local policy, the BGP Route Refresh option [12] may be
> >   used to request the full set of routes from a peer without resetting
> >   the BGP session when the local policy configuration changes.
>  ---
> 
> This seems to imply that it's OK, with vanilla BGP, to not store all
> learned routes.  

Strictly speaking, vanilla BGP doesn't *have to* store all the
routes that have been received from a peer, provided that it is
willing to reset the BGP session when the local policy configuration
changes. BGP Route Refresh is optional ("may be used...")

> I propose either striking this section, or rewording
> it to say something like:
> 
>     Optional extensions to BGP may be used to relax this restriction.
> 
> I don't personally like the idea of mentioning specific optional documents
> in the base specification, but if others feel differently, it could
> even be rewritten as:
> 
>     Optional extensions to BGP (such as the BGP Route Refresh option [12])
>     may be used to relax this restriction.
> 
> <snip>
> 
> >4.3 UPDATE Message Format
> 
> <snip>
> 
> >   and withdraw multiple unfeasible routes from service. The UPDATE
> >   message always includes the fixed-size BGP header, and can optionally
> >   include the other fields as shown below:
> >
> >
> >      +-----------------------------------------------------+
> >      |   Withdrawn Routes Length (2 octets)                |
> >      +-----------------------------------------------------+
> 
> Withdrawn Routes length is not an optional field...
> 
> >      |   Withdrawn Routes (variable)                       |
> >      +-----------------------------------------------------+
> >      |   Total Path Attribute Length (2 octets)            |
> >      +-----------------------------------------------------+
> 
> Neither is total Path Attribute Length...
> 
> >      |   Path Attributes (variable)                        |
> >      +-----------------------------------------------------+
> >      |   Network Layer Reachability Information (variable) |
> >      +-----------------------------------------------------+
> 
> Perhaps reword the sentence as:
>                     
>       An UPDATE message also includes other fields, as shown below
>       (note, some of the shown fields are not present in every UPDATE
>       message):

fixed.

> 
> <snip>
> 
> >4.5 NOTIFICATION Message Format
> 
> <snip>
> 
> The diagram of a notification message doesn't make it clear that the
> Data field is of a variable length:
> 
> >       0                   1                   2                   3
> >       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
> >       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> >       | Error code    | Error subcode |           Data                |
> >       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               +
> >       |                                                               |
> >       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> 
> <snip>
> 
> Perhaps change the diagram to:
> 
>        0                   1                   2                   3
>        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>        | Error code    | Error subcode |     Data (variable length)    |
>        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> 
> <snip>

fixed.

> 
> >5.1.2 AS_PATH
> 
> <snip>
> 
> >      a) When a given BGP speaker advertises the route to an internal
> >      peer, the advertising speaker shall not modify the AS_PATH
> >      attribute associated with the route.
> >
> >      b) When a given BGP speaker advertises the route to an external
> >      peer, then the advertising speaker shall update the AS_PATH
> >      attribute as follows:
> >
> >         1) if the first path segment of the AS_PATH is of type
> >         AS_SEQUENCE, the local system shall prepend its own AS number
> >         as the last element of the sequence (put it in the leftmost
> >         position)
> >
> >         2) if the first path segment of the AS_PATH is of type AS_SET,
> >         the local system shall prepend a new path segment of type
> >         AS_SEQUENCE to the AS_PATH, including its own AS number in that
> >         segment.
> 
> This doesn't cover AS Path stuffing.  Perhaps reword this as follows:
> 
>          1) if the first path segment of the AS_PATH is of type
>          AS_SEQUENCE, the local system shall prepend its own AS number
>          as the last element of the sequence (put it in the leftmost
>          position) one, or more, times.
> 
>          2) if the first path segment of the AS_PATH is of type AS_SET,
>          the local system shall prepend a new path segment of type
>          AS_SEQUENCE to the AS_PATH, including its own AS number in that
>          segment, at least once.      
> 
> >   When a BGP speaker originates a route then:
> >
> >      a) the originating speaker shall include its own AS number in the
> >      AS_PATH attribute of all UPDATE messages sent to an external peer.
> >      (In this case, the AS number of the originating speaker's
> >      autonomous system will be the only entry in the AS_PATH
> >      attribute).
> 
> This doesn't mention what kind of segment your AS number is in, nor
> does it cover AS Path stuffing.  I suggest rewording as follows:
> 
>       a) the originating speaker shall include its own AS number at least
>       once in a path segment of type AS_SEQUENCE.  This segment shall
>       be the leftmost element of the AS_PATH.  (In this case, the AS number
>       of the originating speaker's autonomous system will be the only entry
>       in the AS_PATH attribute).      

I like Enke's suggestion that "instead of enumerating the scenarios for 
AS stuffing in multiple places, we could add a couple of sentences in 
the section that describes the AS-PATH attribute." So, I would appreciate
if you and Enke would provide me with the text to cover this.

> 
> <snip>
> 
> >9. UPDATE Message Handling
> 
> <snip>
> 
> >   iii) If the new route has identical path attributes to an earlier
> >   route contained in the Adj-RIB-In, and is more specific (see 9.1.4)
> >   than the earlier route, no further actions are necessary.
> 
> This appears to be wrong, because of the ATOMIC_AGGREGATE attribute.
> According to section 4.3, page 14:
> 
>         "ATOMIC_AGGREGATE ... is used by a BGP speaker to inform other
>         BGP speakers that the local system selected a less specific
>         route without selecting a more specific route which is included
>         in it."
> 
> Then, in section 5.1.3, page 24:
> 
>         "If a BGP speaker, when presented with a set of overlapping
>         routes from one of its peers ... selects the less specific route
>         without selecting the more specific one, then the local system
>         MUST attach the ATOMIC_AGGREGATE attribute to the route when
>         propagating it to other BGP speakers ..."
> 
> So, when we receive a more specific route, we have to continue on and
> decide whether to select it or not... then, if we choose not to select
> it, we may need to readvertise the less specific route with the
> ATOMIC_AGGREGATE attribute.
> 
> I propose simply striking this paragraph.

The current text on ATOMIC_AGGREGATE isn't exactly correct. I would
suggest to change 4.3 to the following:

         ATOMIC_AGGREGATE ... is used by a BGP speaker to inform other
         BGP speakers that the local system selected a less specific
         route without selecting a more specific route which is included
         in it, where the AS_PATH attribute of the more specific route
         is different from the AS_PATH attribute of the less specific
         route.

And also change 5.1.6 to the following:

         "If a BGP speaker, when presented with a set of overlapping
         routes from one of its peers ... selects the less specific route
         without selecting the more specific one, and the AS_PATH attribute
         of the less specific route is different from the AS_PATH attribute
         of the more specific route, then the local system
         MUST attach the ATOMIC_AGGREGATE attribute to the route when
         propagating it to other BGP speakers ..."

> 
> >9.1.2 Phase 2: Route Selection
> 
> <snip>
> 
> >   Unfeasible routes SHALL be removed from the Loc-RIB and the routing
> >   table. However, corresponding unfeasible routes SHOULD be kept in the
> >   Adj-RIBs-In.
> 
> <snip>
> 
> I'm not sure what is considered an unfeasible route for this section.
> Because we're keeping them in the Adj-RIBs-In, I suspect that they
> are routes which are not selected by the decision process, or, possibly,
> routes which are not considered by the decision process because of
> unresolvable nexthops.
> 
> If this is the case, then the SHOULD should be a MUST, shouldn't it?
> 
> Either way, I think that more information on which routes this statement
> pertains to needs to be included...

changed to:

   Unresolvable routes SHALL be removed from the Loc-RIB and the routing
   table. However, corresponding unresolvable routes SHOULD be kept in the
   Adj-RIBs-In.

> 
> 9.1.2.2 Breaking Ties (Phase 2)       
> 
> <snip>
> 
> >      a) Remove from consideration routes with less-preferred
> >      MULTI_EXIT_DISC attributes. MULTI_EXIT_DISC is only comparable
> >      between routes learned from the same neighboring AS. Routes which
> >      do not have the MULTI_EXIT_DISC attribute are considered to have
> >      the highest possible MULTI_EXIT_DISC value.
> >
> >      This is also described in the following procedure:
> >
> >            for m = all routes still under consideration
> >                for n = all routes still under consideration
> >                    if (neighborAS(m) == neighborAS(n)) and (MED(n) < MED(m)
)
> >                        remove route m from consideration
> >
> >      In the pseudo-code above, MED(n) is a function which returns the
> >      value of route n's MULTI_EXIT_DISC attribute. If route n has no
> >      MULTI_EXIT_DISC attribute, the function returns the highest
> >      possible MULTI_EXIT_DISC value, i.e. 2^32-1.
> >
> >      Similarly, neighborAS(n) is a function which returns the neighbor
> >      AS from which the route was received.
> >
> >      b) Remove from consideration any routes with less-preferred
> >      interior cost.  The interior cost of a route is determined by
> >      calculating the metric to the next hop for the route using the
> >      Routing Table. If the next hop for a route is reachable, but no
> >      cost can be determined, then this step should be skipped
> >      (equivalently, consider all routes to have equal costs).
> >
> >      This is also described in the following procedure.
> >
> >            for m = all routes still under consideration
> >                for n = all routes in still under consideration
> >                    if (cost(n) is better than cost(m))
> >                        remove m from consideration
> >
> >      In the pseudo-code above, cost(n) is a function which returns the
> >      cost of the path (interior distance) to the address given in the
> >      NEXT_HOP attribute of the route.
> >
> >      c) If at least one of the candidate routes was received from an
> >      external peer in a neighboring autonomous system, remove from
> >      consideration all routes which were received from internal peers.
> >
> >      d) Remove from consideration all routes other than the route that
> >      was advertised by the BGP speaker whose BGP Identifier has the
> >      lowest value.
> 
> There is no mention here of breaking ties based on AS Path length,
> or Origin type, both of which are widely deployed methods of
> breaking ties.  I propose that these be added as the first step
> of the tie-breaking process:
> 
> 	a) Remove from consideration all routes which are not tied
> 	for having the smallest number of AS numbers present in their
> 	AS_PATH attributes.
> 
> 	b) Remove from consideration all routes which are not tied
> 	for having the lowest Origin number in their Origin attribute.

In the absence of any objections from the folks on the list by
10/11 I'll add (a) and (b), as you suggested.

Yakov.

content-class: urn:content-classes:message
Subject: RE: Data part of ERROR_CODE 2 and SUBCODE 4.
Date: Thu, 4 Oct 2001 13:28:17 +0530
From: "deepak_srivastava" <[email-masked]>
To: "deepak_srivastava" <[email-masked]>, <[email-masked]>
Sender: [email-masked]

This is a multi-part message in MIME format.

------_=_NextPart_001_01C14CAA.5372715F
Content-Type: text/plain;
	charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

I got some personal replies on this saying NOTIFICATION error subcode
should be set to 5 (Authentication Failure) if the speaker doesn't
support authentication.

As per my understanding a speaker is supposed to set sub-code as :

  4- when we dont support authenthication.

  5- When we do support authentication but it gets failed=20
     due to wrong data from the peer.

Anyway my suggestion was generic. If in future there are some other
optional parameters in OPEN message then how do we know for which
parameter we got notification as "unsupported open optional parameter".

Since presently we dont use "data" field of NOTIFICATION message for
unsupported open optional parameter, we can use that to indicate the
type of parameter not supported by the speaker. This will allow the peer
to resend the open message with all ohter optional parameters except
that particular parameter.

I would really appreciate if someone can clarify it as my implementation
of capabilities is somewhat dependent on it.

DEEPAK SRIVASTAVA
COMMUNICATIONS GROUP
INFOSYS TECHNOLOGIES LTD.

-----Original Message-----
From:	deepak_srivastava
Sent:	Wed 10/3/2001 5:27 PM
To:	[email-masked]
Cc:=09
Subject:	Data part of ERROR_CODE 2 and SUBCODE 4.

Hi All,

According to new bgp draft (draft-ietf-idr-bgp4-13.txt) and RFC-1771,
data portion of NOTIFICATION message for error code 2 (OPEN Message
Error) with subcode 4 (Unsupported Optional Parameter) is NOT defined.

Will it not be better to send the TYPE of optional parameter which is
unsupported on the local speaker along with the message (encoded in data
portion of notification message).

For capabilities (RFC 2842), one needs to resend the open message
without capabilities option if a notification with error code 2 and
sub-code 4 is received from peer.

My question is how can a local speaker be sure of which optional
parameter is not supported by the peer.

For example if a peer doesn't support authentication then it will send a
notification message as "unsupported optional parameter" even if it
supports capabilities. The local speaker will see this notification and
will resend its open message without capabilities as optional parameter,
which would be wrong.

DEEPAK SRIVASTAVA,
COMMUNICATION GROUP,
INFOSYS TECHNOLOGIES LTD.

------_=_NextPart_001_01C14CAA.5372715F
Content-Type: application/ms-tnef;
	name="winmail.dat"
Content-Transfer-Encoding: base64

------_=_NextPart_001_01C14CAA.5372715F--

content-class: urn:content-classes:message
Subject: Data part of ERROR_CODE 2 and SUBCODE 4.
Date: Wed, 3 Oct 2001 17:27:38 +0530
From: "deepak_srivastava" <[email-masked]>
To: <[email-masked]>
Sender: [email-masked]

Hi All,

According to new bgp draft (draft-ietf-idr-bgp4-13.txt) and RFC-1771,
data portion of NOTIFICATION message for error code 2 (OPEN Message
Error) with subcode 4 (Unsupported Optional Parameter) is NOT defined.

Will it not be better to send the TYPE of optional parameter which is
unsupported on the local speaker along with the message (encoded in data
portion of notification message).

For capabilities (RFC 2842), one needs to resend the open message
without capabilities option if a notification with error code 2 and
sub-code 4 is received from peer.

My question is how can a local speaker be sure of which optional
parameter is not supported by the peer.

For example if a peer doesn't support authentication then it will send a
notification message as "unsupported optional parameter" even if it
supports capabilities. The local speaker will see this notification and
will resend its open message without capabilities as optional parameter,
which would be wrong.

DEEPAK SRIVASTAVA,
COMMUNICATION GROUP,
INFOSYS TECHNOLOGIES LTD.

Date: Tue, 2 Oct 2001 19:34:28 -0400
To: [email-masked]
From: "Howard C. Berkowitz" <[email-masked]>
Subject: Re: BGP TTL (was Re: draft-ietf-idr-bgp4-13.txt
Sender: [email-masked]

>Guys,
>
>Cisco's implementation has numerous checks in it to insure that your EBGP
>neighbor is adjacent to you in addressing and in TTL.  Again, these are
>implementation decisions with the goal of helping customers not shoot
>themselves in the foot and cause EBGP routing loops.  The knob is to allow
>customers to aim the gun downwards.
>
>My amendment to Postel's Law:
>Be liberal in what you accept, conservative in what you send, and add a
>knob so that you can interoperate even if the other guy blows it.
>
>Tony

If nothing else, Tony, I'm glad I swallowed before reading this. Thanks.

Although isn't there a class of customers where less damage would be 
done if they aimed the gun at their brains?

>
>
>Howard C. Berkowitz writes:
>  | Sue,
>  |
>  |
>  | Tony, of course, has a history on this that I don't.  When I worked
>  | on Ciscos, I used ebgp-multihop in scenarios such as:
>  |
>  |
>  |         Router 1  s0.....................S0 Router 2
>  |         Loopback----------------------------Loopback
>  |                   s1.....................S1
>  |
>  | where ------ is the BGP/TCP connection and ..... the actual IP
>  | connection.  I've also seen uses where the TCP connection was
>  | essentially a tunnel through multiple hops.
>  |
>  | My question came up when a developer asked me about the circumstances
>  | under which eBGP multihop should be used, and I said I'd check the
>  | standards.  I had always assumed it was required, since I had seen it
>  | discussed in non-Cisco references as well. When I didn't find it in
>  | any RFC or draft, I got curious and made the post.
>  |
>  | This may just be an artifact that shouldn't be worried about. But, if
>  | not, it might affect interoperability depending on the way other
>  | implementers have interpreted it.
>  |
>  |
>  | >Sue Hares wrote,
>  |
>  |
>  |
>  | >Tony and Howard:
>  | >
>  | >Are you imply the following scenario where we had incidents of an
>  | >implementation that caused a bit of a loop on a TTL that was 
>greater than one.
>  | >               link a
>  | >     router1 --- router 2 ------- router 4 ---- Internet2 --- router3
>  | >       | |
>  | >        ------------------------------------------------------------------
>  | >                 link b
>  | >
>  | >When link a went down, the router 1 didn't want to talk to router 2
>  | >via the link b.
>  | >
>  | >Sue Hares
>  | >
>  | >At 12:54 PM 10/2/2001 -0700, Tony Li wrote:
>  | >
>  | >>Using a TTL of 1 for EBGP was an implementation decision and I don't
>  | >>believe that it requires standardization.
>  | >>
>  | >>The knob exists for a) testing and b) a particularly pathetic router
>  | >>implementation that would discard packets with a TTL of 1 before it
>  | >>examined the packet to see if it should receive it.
>  | >>
>  | >>Tony
>  | >
>  | >
>  | >
>  | >
>  | >>Howard C. Berkowitz writes:
>  | >>  | I've noticed that neither 1771, nor draft 13, nor the version 2 MIB
>  | >>  | mention any interaction between BGP and the IP TTL. It's my
>  | >>  | impression that several implementations do have a knob to control
>  | >>  | this (e.g., Cisco ebgp-multihop).  Is this a potential
>  | >>  | interoperability issue that should be made explicit?
>  | >>  |
>  | >>  | Howard Berkowitz
>  | >>  | Nortel

From: Tony Li <[email-masked]>
Date: Tue, 2 Oct 2001 15:34:22 -0700
To: "Howard C. Berkowitz" <[email-masked]>
Cc: [email-masked]
Subject: BGP TTL (was Re: draft-ietf-idr-bgp4-13.txt
Sender: [email-masked]

Guys,

Cisco's implementation has numerous checks in it to insure that your EBGP
neighbor is adjacent to you in addressing and in TTL.  Again, these are
implementation decisions with the goal of helping customers not shoot
themselves in the foot and cause EBGP routing loops.  The knob is to allow
customers to aim the gun downwards.

My amendment to Postel's Law:
Be liberal in what you accept, conservative in what you send, and add a
knob so that you can interoperate even if the other guy blows it.

Tony

Howard C. Berkowitz writes:
 | Sue,
 | 
 | 
 | Tony, of course, has a history on this that I don't.  When I worked 
 | on Ciscos, I used ebgp-multihop in scenarios such as:
 | 
 | 
 |         Router 1  s0.....................S0 Router 2
 |         Loopback----------------------------Loopback
 |                   s1.....................S1
 | 
 | where ------ is the BGP/TCP connection and ..... the actual IP 
 | connection.  I've also seen uses where the TCP connection was 
 | essentially a tunnel through multiple hops.
 | 
 | My question came up when a developer asked me about the circumstances 
 | under which eBGP multihop should be used, and I said I'd check the 
 | standards.  I had always assumed it was required, since I had seen it 
 | discussed in non-Cisco references as well. When I didn't find it in 
 | any RFC or draft, I got curious and made the post.
 | 
 | This may just be an artifact that shouldn't be worried about. But, if 
 | not, it might affect interoperability depending on the way other 
 | implementers have interpreted it.
 | 
 | 
 | >Sue Hares wrote,
 | 
 | 
 | 
 | >Tony and Howard:
 | >
 | >Are you imply the following scenario where we had incidents of an
 | >implementation that caused a bit of a loop on a TTL that was greater than one.
 | >               link a
 | >     router1 --- router 2 ------- router 4 ---- Internet2 --- router3
 | >       | |
 | >        ------------------------------------------------------------------
 | >                 link b
 | >
 | >When link a went down, the router 1 didn't want to talk to router 2
 | >via the link b.
 | >
 | >Sue Hares
 | >
 | >At 12:54 PM 10/2/2001 -0700, Tony Li wrote:
 | >
 | >>Using a TTL of 1 for EBGP was an implementation decision and I don't
 | >>believe that it requires standardization.
 | >>
 | >>The knob exists for a) testing and b) a particularly pathetic router
 | >>implementation that would discard packets with a TTL of 1 before it
 | >>examined the packet to see if it should receive it.
 | >>
 | >>Tony
 | >
 | >
 | >
 | >
 | >>Howard C. Berkowitz writes:
 | >>  | I've noticed that neither 1771, nor draft 13, nor the version 2 MIB
 | >>  | mention any interaction between BGP and the IP TTL. It's my
 | >>  | impression that several implementations do have a knob to control
 | >>  | this (e.g., Cisco ebgp-multihop).  Is this a potential
 | >>  | interoperability issue that should be made explicit?
 | >>  |
 | >>  | Howard Berkowitz
 | >>  | Nortel

From: Tony Li <[email-masked]>
Date: Tue, 2 Oct 2001 15:29:34 -0700
To: Eric Gray <[email-masked]>
Cc: Tony Li <[email-masked]>, "Howard C. Berkowitz" <[email-masked]>, [email-masked]
Subject: Re: draft-ietf-idr-bgp4-13.txt
Sender: [email-masked]

 |     I think such an implementation as you describe (dropping packets
 | with a TTL of 1 before looking at the destination) is worse than pathetic
 | - it's not in compliance with router requirements.  See section 4.2.2.9,
 | fourth paragraph in RFC 1812...

The good news is a) that pathetic vendor no longer makes routers and b) has
been acquired many times over.

Tony

Date: Tue, 2 Oct 2001 18:17:44 -0400
To: [email-masked]
From: "Howard C. Berkowitz" <[email-masked]>
Subject: BGP TTL (was Re: draft-ietf-idr-bgp4-13.txt
Sender: [email-masked]

Sue,

Tony, of course, has a history on this that I don't.  When I worked 
on Ciscos, I used ebgp-multihop in scenarios such as:

        Router 1  s0.....................S0 Router 2
        Loopback----------------------------Loopback
                  s1.....................S1

where ------ is the BGP/TCP connection and ..... the actual IP 
connection.  I've also seen uses where the TCP connection was 
essentially a tunnel through multiple hops.

My question came up when a developer asked me about the circumstances 
under which eBGP multihop should be used, and I said I'd check the 
standards.  I had always assumed it was required, since I had seen it 
discussed in non-Cisco references as well. When I didn't find it in 
any RFC or draft, I got curious and made the post.

This may just be an artifact that shouldn't be worried about. But, if 
not, it might affect interoperability depending on the way other 
implementers have interpreted it.

>Sue Hares wrote,

>Tony and Howard:
>
>Are you imply the following scenario where we had incidents of an
>implementation that caused a bit of a loop on a TTL that was greater than one.
>               link a
>     router1 --- router 2 ------- router 4 ---- Internet2 --- router3
>       | |
>        ------------------------------------------------------------------
>                 link b
>
>When link a went down, the router 1 didn't want to talk to router 2
>via the link b.
>
>Sue Hares
>
>At 12:54 PM 10/2/2001 -0700, Tony Li wrote:
>
>>Using a TTL of 1 for EBGP was an implementation decision and I don't
>>believe that it requires standardization.
>>
>>The knob exists for a) testing and b) a particularly pathetic router
>>implementation that would discard packets with a TTL of 1 before it
>>examined the packet to see if it should receive it.
>>
>>Tony
>
>
>
>
>>Howard C. Berkowitz writes:
>>  | I've noticed that neither 1771, nor draft 13, nor the version 2 MIB
>>  | mention any interaction between BGP and the IP TTL. It's my
>>  | impression that several implementations do have a knob to control
>>  | this (e.g., Cisco ebgp-multihop).  Is this a potential
>>  | interoperability issue that should be made explicit?
>>  |
>>  | Howard Berkowitz
>>  | Nortel

Date: Tue, 02 Oct 2001 17:41:07 -0400
To: Tony Li <[email-masked]>
From: Susan Hares <[email-masked]>
Subject: Re: draft-ietf-idr-bgp4-13.txt
Cc: "Howard C. Berkowitz" <[email-masked]>, [email-masked]
Sender: [email-masked]

Tony and Howard:

Are you imply the following scenario where we had incidents of an
implementation that caused a bit of a loop on a TTL that was greater than one.
               link a
     router1 --- router 2 ------- router 4 ---- Internet2 --- router3
       | 
|
        ------------------------------------------------------------------
                 link b

When link a went down, the router 1 didn't want to talk to router 2
via the link b.

Sue Hares

At 12:54 PM 10/2/2001 -0700, Tony Li wrote:

>Using a TTL of 1 for EBGP was an implementation decision and I don't
>believe that it requires standardization.
>
>The knob exists for a) testing and b) a particularly pathetic router
>implementation that would discard packets with a TTL of 1 before it
>examined the packet to see if it should receive it.
>
>Tony

>Howard C. Berkowitz writes:
>  | I've noticed that neither 1771, nor draft 13, nor the version 2 MIB
>  | mention any interaction between BGP and the IP TTL. It's my
>  | impression that several implementations do have a knob to control
>  | this (e.g., Cisco ebgp-multihop).  Is this a potential
>  | interoperability issue that should be made explicit?
>  |
>  | Howard Berkowitz
>  | Nortel

Date: Tue, 02 Oct 2001 17:28:24 -0400
From: Eric Gray <[email-masked]>
To: Tony Li <[email-masked]>
Cc: "Howard C. Berkowitz" <[email-masked]>, [email-masked]
Subject: Re: draft-ietf-idr-bgp4-13.txt
Sender: [email-masked]

Tony,

    I think such an implementation as you describe (dropping packets
with a TTL of 1 before looking at the destination) is worse than pathetic
- it's not in compliance with router requirements.  See section 4.2.2.9,
fourth paragraph in RFC 1812...

--
Eric Gray

You wrote:

> Using a TTL of 1 for EBGP was an implementation decision and I don't
> believe that it requires standardization.
>
> The knob exists for a) testing and b) a particularly pathetic router
> implementation that would discard packets with a TTL of 1 before it
> examined the packet to see if it should receive it.
>
> Tony
>
> Howard C. Berkowitz writes:
>  | I've noticed that neither 1771, nor draft 13, nor the version 2 MIB
>  | mention any interaction between BGP and the IP TTL. It's my
>  | impression that several implementations do have a knob to control
>  | this (e.g., Cisco ebgp-multihop).  Is this a potential
>  | interoperability issue that should be made explicit?
>  |
>  | Howard Berkowitz
>  | Nortel

--
Eric Gray (mailto:[email-masked])
http://www.mindspring.com/~ewgray

Date: Tue, 2 Oct 2001 16:03:49 -0400
From: Mathew Richardson <[email-masked]>
To: Enke Chen <[email-masked]>
Cc: [email-masked]
Subject: Re: draft-ietf-idr-bgp4-13.txt
Sender: [email-masked]

> Enke Chen <[email-masked]> [Tue, Oct 02, 2001 at 11:21:29AM -0700]:
>Hi, Mathew:
>
>> Date: Tue, 2 Oct 2001 13:42:09 -0400
>> From: Mathew Richardson <[email-masked]>
>> To: [email-masked]
>> Subject: draft-ietf-idr-bgp4-13.txt
>> Message-ID: <[email-masked]>
>> Mime-Version: 1.0
>
>[snip]
>
>> >   When a BGP speaker originates a route then:
>> >
>> >      a) the originating speaker shall include its own AS number in the
>> >      AS_PATH attribute of all UPDATE messages sent to an external peer.
>> >      (In this case, the AS number of the originating speaker's
>> >      autonomous system will be the only entry in the AS_PATH
>> >      attribute).
>> 
>> This doesn't mention what kind of segment your AS number is in, nor
>> does it cover AS Path stuffing.  I suggest rewording as follows:
>> 
>>       a) the originating speaker shall include its own AS number at least
>>       once in a path segment of type AS_SEQUENCE.  This segment shall
>>       be the leftmost element of the AS_PATH.  (In this case, the AS number
>>       of the originating speaker's autonomous system will be the only entry
>>       in the AS_PATH attribute).      
>> 
>
>As this paragraph a) talks about sending update to an EBGP peer, we should
>keep the original text of "send to an external peer".

You are absolutely correct.  This was an oversite on my part.

>Also, instead of enumerating the senarios for AS stuffing in multiple places,
>we could add a couple of sentences in the section that describes the AS-PATH
>attribute.

<snip>

While I agree that it may be appropriate to place text in the section that
describes AS_PATH attributes, I think that the section of the spec where
the AS_PATH modification rules are enumerated needs to talk about all of
the legal actions...

mrr

From: Tony Li <[email-masked]>
Date: Tue, 2 Oct 2001 12:54:28 -0700
To: "Howard C. Berkowitz" <[email-masked]>
Cc: [email-masked]
Subject: Re: draft-ietf-idr-bgp4-13.txt
Sender: [email-masked]

Using a TTL of 1 for EBGP was an implementation decision and I don't
believe that it requires standardization.  

The knob exists for a) testing and b) a particularly pathetic router
implementation that would discard packets with a TTL of 1 before it
examined the packet to see if it should receive it.

Tony

Howard C. Berkowitz writes:
 | I've noticed that neither 1771, nor draft 13, nor the version 2 MIB 
 | mention any interaction between BGP and the IP TTL. It's my 
 | impression that several implementations do have a knob to control 
 | this (e.g., Cisco ebgp-multihop).  Is this a potential 
 | interoperability issue that should be made explicit?
 | 
 | Howard Berkowitz
 | Nortel

Date: Tue, 2 Oct 2001 14:53:10 -0400
To: [email-masked]
From: "Howard C. Berkowitz" <[email-masked]>
Subject: Re: draft-ietf-idr-bgp4-13.txt
Sender: [email-masked]

I've noticed that neither 1771, nor draft 13, nor the version 2 MIB 
mention any interaction between BGP and the IP TTL. It's my 
impression that several implementations do have a knob to control 
this (e.g., Cisco ebgp-multihop).  Is this a potential 
interoperability issue that should be made explicit?

Howard Berkowitz
Nortel

To: Mathew Richardson <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: draft-ietf-idr-bgp4-13.txt 
Date: Tue, 02 Oct 2001 11:21:29 -0700
From: Enke Chen <[email-masked]>
Sender: [email-masked]

Hi, Mathew:

> Date: Tue, 2 Oct 2001 13:42:09 -0400
> From: Mathew Richardson <[email-masked]>
> To: [email-masked]
> Subject: draft-ietf-idr-bgp4-13.txt
> Message-ID: <[email-masked]>
> Mime-Version: 1.0

[snip]

> >   When a BGP speaker originates a route then:
> >
> >      a) the originating speaker shall include its own AS number in the
> >      AS_PATH attribute of all UPDATE messages sent to an external peer.
> >      (In this case, the AS number of the originating speaker's
> >      autonomous system will be the only entry in the AS_PATH
> >      attribute).
> 
> This doesn't mention what kind of segment your AS number is in, nor
> does it cover AS Path stuffing.  I suggest rewording as follows:
> 
>       a) the originating speaker shall include its own AS number at least
>       once in a path segment of type AS_SEQUENCE.  This segment shall
>       be the leftmost element of the AS_PATH.  (In this case, the AS number
>       of the originating speaker's autonomous system will be the only entry
>       in the AS_PATH attribute).      
> 

As this paragraph a) talks about sending update to an EBGP peer, we should
keep the original text of "send to an external peer".

Also, instead of enumerating the senarios for AS stuffing in multiple places,
we could add a couple of sentences in the section that describes the AS-PATH
attribute.

-- Enke

Date: Tue, 2 Oct 2001 13:42:09 -0400
From: Mathew Richardson <[email-masked]>
To: [email-masked]
Subject: draft-ietf-idr-bgp4-13.txt
Sender: [email-masked]

I've put together a few of my comments/concerns on draft 13.  I've
tried to leave out anything dealing exclusively with grammar/
formatting/etc., and just deal with those places where I feel the
draft is misleading, contradictory, or wrong.

<snip>

>3. Summary of Operation
>
>   Two systems form a transport protocol connection between one another.
>   They exchange messages to open and confirm the connection parameters.
>
>   The initial data flow is the entire BGP routing table. Incremental
>   updates are sent as the routing tables change. BGP does not require
>   periodic refresh of the entire BGP routing table. Therefore, a BGP
>   speaker must retain the current version of the entire BGP routing
>   tables of all of its peers for the duration of the connection.
 ---
>                                                                   If
>   the implementation decides to not store the routes that have been
>   received from a peer, but have been filtered out according to
>   configured local policy, the BGP Route Refresh option [12] may be
>   used to request the full set of routes from a peer without resetting
>   the BGP session when the local policy configuration changes.
 ---

This seems to imply that it's OK, with vanilla BGP, to not store all
learned routes.  I propose either striking this section, or rewording
it to say something like:

    Optional extensions to BGP may be used to relax this restriction.

I don't personally like the idea of mentioning specific optional documents
in the base specification, but if others feel differently, it could
even be rewritten as:

    Optional extensions to BGP (such as the BGP Route Refresh option [12])
    may be used to relax this restriction.

<snip>

>4.3 UPDATE Message Format

<snip>

>   and withdraw multiple unfeasible routes from service. The UPDATE
>   message always includes the fixed-size BGP header, and can optionally
>   include the other fields as shown below:
>
>
>      +-----------------------------------------------------+
>      |   Withdrawn Routes Length (2 octets)                |
>      +-----------------------------------------------------+

Withdrawn Routes length is not an optional field...

>      |   Withdrawn Routes (variable)                       |
>      +-----------------------------------------------------+
>      |   Total Path Attribute Length (2 octets)            |
>      +-----------------------------------------------------+

Neither is total Path Attribute Length...

>      |   Path Attributes (variable)                        |
>      +-----------------------------------------------------+
>      |   Network Layer Reachability Information (variable) |
>      +-----------------------------------------------------+

Perhaps reword the sentence as:
                    
      An UPDATE message also includes other fields, as shown below
      (note, some of the shown fields are not present in every UPDATE
      message):

<snip>

>4.5 NOTIFICATION Message Format

<snip>

The diagram of a notification message doesn't make it clear that the
Data field is of a variable length:

>       0                   1                   2                   3
>       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>       | Error code    | Error subcode |           Data                |
>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               +
>       |                                                               |
>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

<snip>

Perhaps change the diagram to:

       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       | Error code    | Error subcode |     Data (variable length)    |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

<snip>

>5.1.2 AS_PATH

<snip>

>      a) When a given BGP speaker advertises the route to an internal
>      peer, the advertising speaker shall not modify the AS_PATH
>      attribute associated with the route.
>
>      b) When a given BGP speaker advertises the route to an external
>      peer, then the advertising speaker shall update the AS_PATH
>      attribute as follows:
>
>         1) if the first path segment of the AS_PATH is of type
>         AS_SEQUENCE, the local system shall prepend its own AS number
>         as the last element of the sequence (put it in the leftmost
>         position)
>
>         2) if the first path segment of the AS_PATH is of type AS_SET,
>         the local system shall prepend a new path segment of type
>         AS_SEQUENCE to the AS_PATH, including its own AS number in that
>         segment.

This doesn't cover AS Path stuffing.  Perhaps reword this as follows:

         1) if the first path segment of the AS_PATH is of type
         AS_SEQUENCE, the local system shall prepend its own AS number
         as the last element of the sequence (put it in the leftmost
         position) one, or more, times.

         2) if the first path segment of the AS_PATH is of type AS_SET,
         the local system shall prepend a new path segment of type
         AS_SEQUENCE to the AS_PATH, including its own AS number in that
         segment, at least once.      

>   When a BGP speaker originates a route then:
>
>      a) the originating speaker shall include its own AS number in the
>      AS_PATH attribute of all UPDATE messages sent to an external peer.
>      (In this case, the AS number of the originating speaker's
>      autonomous system will be the only entry in the AS_PATH
>      attribute).

This doesn't mention what kind of segment your AS number is in, nor
does it cover AS Path stuffing.  I suggest rewording as follows:

      a) the originating speaker shall include its own AS number at least
      once in a path segment of type AS_SEQUENCE.  This segment shall
      be the leftmost element of the AS_PATH.  (In this case, the AS number
      of the originating speaker's autonomous system will be the only entry
      in the AS_PATH attribute).      

<snip>

>9. UPDATE Message Handling

<snip>

>   iii) If the new route has identical path attributes to an earlier
>   route contained in the Adj-RIB-In, and is more specific (see 9.1.4)
>   than the earlier route, no further actions are necessary.

This appears to be wrong, because of the ATOMIC_AGGREGATE attribute.
According to section 4.3, page 14:

        "ATOMIC_AGGREGATE ... is used by a BGP speaker to inform other
        BGP speakers that the local system selected a less specific
        route without selecting a more specific route which is included
        in it."

Then, in section 5.1.3, page 24:

        "If a BGP speaker, when presented with a set of overlapping
        routes from one of its peers ... selects the less specific route
        without selecting the more specific one, then the local system
        MUST attach the ATOMIC_AGGREGATE attribute to the route when
        propagating it to other BGP speakers ..."

So, when we receive a more specific route, we have to continue on and
decide whether to select it or not... then, if we choose not to select
it, we may need to readvertise the less specific route with the
ATOMIC_AGGREGATE attribute.

I propose simply striking this paragraph.

>9.1.2 Phase 2: Route Selection

<snip>

>   Unfeasible routes SHALL be removed from the Loc-RIB and the routing
>   table. However, corresponding unfeasible routes SHOULD be kept in the
>   Adj-RIBs-In.

<snip>

I'm not sure what is considered an unfeasible route for this section.
Because we're keeping them in the Adj-RIBs-In, I suspect that they
are routes which are not selected by the decision process, or, possibly,
routes which are not considered by the decision process because of
unresolvable nexthops.

If this is the case, then the SHOULD should be a MUST, shouldn't it?

Either way, I think that more information on which routes this statement
pertains to needs to be included...

9.1.2.2 Breaking Ties (Phase 2)       

<snip>

>      a) Remove from consideration routes with less-preferred
>      MULTI_EXIT_DISC attributes. MULTI_EXIT_DISC is only comparable
>      between routes learned from the same neighboring AS. Routes which
>      do not have the MULTI_EXIT_DISC attribute are considered to have
>      the highest possible MULTI_EXIT_DISC value.
>
>      This is also described in the following procedure:
>
>            for m = all routes still under consideration
>                for n = all routes still under consideration
>                    if (neighborAS(m) == neighborAS(n)) and (MED(n) < MED(m))
>                        remove route m from consideration
>
>      In the pseudo-code above, MED(n) is a function which returns the
>      value of route n's MULTI_EXIT_DISC attribute. If route n has no
>      MULTI_EXIT_DISC attribute, the function returns the highest
>      possible MULTI_EXIT_DISC value, i.e. 2^32-1.
>
>      Similarly, neighborAS(n) is a function which returns the neighbor
>      AS from which the route was received.
>
>      b) Remove from consideration any routes with less-preferred
>      interior cost.  The interior cost of a route is determined by
>      calculating the metric to the next hop for the route using the
>      Routing Table. If the next hop for a route is reachable, but no
>      cost can be determined, then this step should be skipped
>      (equivalently, consider all routes to have equal costs).
>
>      This is also described in the following procedure.
>
>            for m = all routes still under consideration
>                for n = all routes in still under consideration
>                    if (cost(n) is better than cost(m))
>                        remove m from consideration
>
>      In the pseudo-code above, cost(n) is a function which returns the
>      cost of the path (interior distance) to the address given in the
>      NEXT_HOP attribute of the route.
>
>      c) If at least one of the candidate routes was received from an
>      external peer in a neighboring autonomous system, remove from
>      consideration all routes which were received from internal peers.
>
>      d) Remove from consideration all routes other than the route that
>      was advertised by the BGP speaker whose BGP Identifier has the
>      lowest value.

There is no mention here of breaking ties based on AS Path length,
or Origin type, both of which are widely deployed methods of
breaking ties.  I propose that these be added as the first step
of the tie-breaking process:

	a) Remove from consideration all routes which are not tied
	for having the smallest number of AS numbers present in their
	AS_PATH attributes.

	b) Remove from consideration all routes which are not tied
	for having the lowest Origin number in their Origin attribute.

<snip>

Comments?

mrr

Date: Tue, 2 Oct 2001 12:34:27 -0400
From: Mathew Richardson <[email-masked]>
To: "Abdallah, Shukri" <[email-masked]>
Cc: "[email-masked]'" <[email-masked]>
Subject: Re: Attributes of an aggregated route
Sender: [email-masked]

> Abdallah, Shukri <[email-masked]> [Tue, Oct 02, 2001 at 09:58:29AM -0400]:
>Given a router R in a confederation setup that received two routes P1 and P2
>with AS_PATH containing the confed sequences of AS1, AS3 and AS1, AS4
>respectively. Assume that router R aggregates P1 and P2 into a route P. What
>should be the AS_PATH of P?

I would expect it to be Sequence AS1, Set AS3 AS4.  Assuming the box isn't
configured to truncate aggregated AS Paths.

>When checking this case using a router of a major vendor, I found out:
>1- the router terminates a confed external peering upon receiving an UPDATE
>message with AS_PATH containing a CONFED_SET.

By confed external, do you mean a peering session with an external peer
not in the same confederation, or a peering session with an external peer
in the same confederation ?

>2- When determining the AS_PATH attribute of an aggregate route, the router
>ignores  CONFED_SEQ values in the component routes if the CONFED_SEQ were
>not identical in all component routes.(Thus it never generates a CONFED_SET)
>
>Is this the correct behavior?

<snip>

I do not believe this behaviour to be correct.

mrr

Date: Tue, 02 Oct 2001 17:34:51 +0200
From: Hans DE VLEESCHOUWER <[email-masked]>
To: BGP mailing list <[email-masked]>
Subject: Policy filtering and route aggregation on IBGP.
Sender: [email-masked]

Hi,

After following the discussions related to the BGP-draft, I got the
impression that it is generally NOT a good idea to apply policies (in
and out) on IBGP updates.

Is this a correct assumption, and if so is it a recommendation not to do
it, or a defintie must; also  does it equally apply to route
summarisation? I do not find back any direct answer in the RFC.

Any feedback is appreciated.

Hans.

From: "Abdallah, Shukri" <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Cc: "Abdallah, Shukri" <[email-masked]>
Subject: Attributes of an aggregated route
Date: Tue, 2 Oct 2001 09:58:29 -0400 
Sender: [email-masked]

Given a router R in a confederation setup that received two routes P1 and P2
with AS_PATH containing the confed sequences of AS1, AS3 and AS1, AS4
respectively. Assume that router R aggregates P1 and P2 into a route P. What
should be the AS_PATH of P?

When checking this case using a router of a major vendor, I found out:
1- the router terminates a confed external peering upon receiving an UPDATE
message with AS_PATH containing a CONFED_SET.
2- When determining the AS_PATH attribute of an aggregate route, the router
ignores  CONFED_SEQ values in the component routes if the CONFED_SEQ were
not identical in all component routes.(Thus it never generates a CONFED_SET)

Is this the correct behavior?

Shukri Abdallah

To: "Galecki, Piotr" <[email-masked]>
Cc: Anoop Ghanwani <[email-masked]>, [email-masked]
Subject: Re: I-D ACTION:draft-chen-bgp-cease-subcode-00.txt 
Date: Mon, 01 Oct 2001 11:40:37 -0700
From: Enke Chen <[email-masked]>
Sender: [email-masked]

Galecki,
We tried. But the editors of the BGP spec kept reminding us that the base
BGP spec is supposed to document only the existing implementation (so that
the base spec can move forward), and suggested a separate document for the
subcodes.

-- Enke

> Message-ID: <[email-masked]>
> From: "Galecki, Piotr" <[email-masked]>
> To: "'Enke Chen'" <[email-masked]>,
> 	Anoop Ghanwani <[email-masked]>
> Cc: [email-masked]
> Subject: RE: I-D ACTION:draft-chen-bgp-cease-subcode-00.txt 
> Date: Mon, 1 Oct 2001 14:24:00 -0400 
> 
> Enke,
> 
> It seems a little awkward to me that this is a separate document
> and not the update to BGP spec.
> Should the new subcodes be rather included in the BGP spec?
> 
> Regards,
> Piotr
> 
> > -----Original Message-----
> > From: Enke Chen [mailto:[email-masked]]
> > Sent: Monday, October 01, 2001 2:14 PM
> > To: Anoop Ghanwani
> > Cc: [email-masked]; [email-masked]
> > Subject: Re: I-D ACTION:draft-chen-bgp-cease-subcode-00.txt 
> > 
> > 
> > Hi, Anoop:
> > 
> > > Message-ID: 
> > <[email-masked]>
> > > From: Anoop Ghanwani <[email-masked]>
> > > To: "[email-masked]'" <[email-masked]>
> > > Cc: [email-masked]
> > > Subject: RE: I-D ACTION:draft-chen-bgp-cease-subcode-00.txt
> > > Date: Mon, 1 Oct 2001 10:35:56 -0700 
> > > 
> > > 
> > > Enke,
> > > 
> > > A minor nit...
> > > 
> > > What's the difference between "Peer Unconfigured" and 
> > > "Connection Rejected".  It seems like both of them
> > > happen because "Local configuration for peer does not exist".
> > 
> > There is some difference as described in the draft:
> > 
> > ----------
> >    If a BGP speaker decides to unconfigure a peer, then the speaker
> >    should send a NOTIFICATION message with the Error Code 
> > Cease, and the
> >    Error Subcode "Peer Unconfigured".
> > 
> >    If a BGP speaker decides to dis-allow a BGP connection (e.g., the
> >    peer is not configured locally) after the speaker accepts 
> > a transport
> >    protocol connection, then the BGP speaker should send a 
> > NOTIFICATION
> >    message with the Error Code Cease, and the Error Subcode 
> > "Connection
> >    Rejected".
> > -----------
> > 
> > Say we have speaker A and B:
> > 
> > A would send "Peer Unconfigured" when its peer to B is un-configured
> > (this is an one time event). After that, A would send "Connection
> > Rejected" in response to a connection request from B.
> > 
> > The subcode of "Peer Unconfigured" is defined as it seems there is
> > value for the remote end to be explicitly informed about the peer
> > deletion.
> > 
> > -- Enke
> > 
> > > 
> > > -Anoop
> > > 
> > > > -----Original Message-----
> > > > From: Enke Chen [mailto:[email-masked]]
> > > > Sent: Friday, September 21, 2001 9:02 AM
> > > > To: [email-masked]; [email-masked]
> > > > Cc: [email-masked]; [email-masked]
> > > > Subject: Re: I-D ACTION:draft-chen-bgp-cease-subcode-00.txt
> > > > 
> > > > 
> > > > Hi, Yakov and Sue:
> > > > Here is a draft that formalizes the idea of defining several Cease
> > > > Subcodes (discussed on the IDR mailing list without any 
> > objection).
> > > > 
> > > > Could you accept it as an IDR Working Group document?
> > > > 
> > > > Thanks. -- Enke
> > > > 
> > > > ------- Forwarded Message
> > > > 
> > > > To: IETF-Announce: ;
> > > > From: [email-masked]
> > > > Reply-To: [email-masked]
> > > > Subject: I-D ACTION:draft-chen-bgp-cease-subcode-00.txt
> > > > Date: Fri, 21 Sep 2001 07:04:13 -0400
> > > > Sender: [email-masked]
> > > > 
> > > > - --NextPart
> > > > 
> > > > A New Internet-Draft is available from the on-line 
> > > > Internet-Drafts directories.
> > > > 
> > > > 
> > > > 	Title		: Subcodes for BGP Cease Notification Message
> > > > 	Author(s)	: E. Chen, V.Gillet
> > > > 	Filename	: draft-chen-bgp-cease-subcode-00.txt
> > > > 	Pages		: 4
> > > > 	Date		: 20-Sep-01
> > > > 	
> > > > This document defines several subcodes for the BGP Cease 
> > NOTIFICATION
> > > > message that would provide more information to aid 
> > network operators
> > > > in co-relating network events and diagnosing BGP peering issues.
> > > > 
> > > > A URL for this Internet-Draft is:
> > > > http://www.ietf.org/internet-drafts/draft-chen-bgp-cease-subco
> > > de-00.txt
> > > 
> > > ------- End of Forwarded Message
> > 

To: Anoop Ghanwani <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: I-D ACTION:draft-chen-bgp-cease-subcode-00.txt 
Date: Mon, 01 Oct 2001 11:13:44 -0700
From: Enke Chen <[email-masked]>
Sender: [email-masked]

Hi, Anoop:

> Message-ID: <[email-masked]>
> From: Anoop Ghanwani <[email-masked]>
> To: "[email-masked]'" <[email-masked]>
> Cc: [email-masked]
> Subject: RE: I-D ACTION:draft-chen-bgp-cease-subcode-00.txt
> Date: Mon, 1 Oct 2001 10:35:56 -0700 
> 
> 
> Enke,
> 
> A minor nit...
> 
> What's the difference between "Peer Unconfigured" and 
> "Connection Rejected".  It seems like both of them
> happen because "Local configuration for peer does not exist".

There is some difference as described in the draft:

----------
   If a BGP speaker decides to unconfigure a peer, then the speaker
   should send a NOTIFICATION message with the Error Code Cease, and the
   Error Subcode "Peer Unconfigured".

   If a BGP speaker decides to dis-allow a BGP connection (e.g., the
   peer is not configured locally) after the speaker accepts a transport
   protocol connection, then the BGP speaker should send a NOTIFICATION
   message with the Error Code Cease, and the Error Subcode "Connection
   Rejected".
-----------

Say we have speaker A and B:

A would send "Peer Unconfigured" when its peer to B is un-configured
(this is an one time event). After that, A would send "Connection
Rejected" in response to a connection request from B.

The subcode of "Peer Unconfigured" is defined as it seems there is
value for the remote end to be explicitly informed about the peer
deletion.

-- Enke

> 
> -Anoop
> 
> > -----Original Message-----
> > From: Enke Chen [mailto:[email-masked]]
> > Sent: Friday, September 21, 2001 9:02 AM
> > To: [email-masked]; [email-masked]
> > Cc: [email-masked]; [email-masked]
> > Subject: Re: I-D ACTION:draft-chen-bgp-cease-subcode-00.txt
> > 
> > 
> > Hi, Yakov and Sue:
> > Here is a draft that formalizes the idea of defining several Cease
> > Subcodes (discussed on the IDR mailing list without any objection).
> > 
> > Could you accept it as an IDR Working Group document?
> > 
> > Thanks. -- Enke
> > 
> > ------- Forwarded Message
> > 
> > To: IETF-Announce: ;
> > From: [email-masked]
> > Reply-To: [email-masked]
> > Subject: I-D ACTION:draft-chen-bgp-cease-subcode-00.txt
> > Date: Fri, 21 Sep 2001 07:04:13 -0400
> > Sender: [email-masked]
> > 
> > - --NextPart
> > 
> > A New Internet-Draft is available from the on-line 
> > Internet-Drafts directories.
> > 
> > 
> > 	Title		: Subcodes for BGP Cease Notification Message
> > 	Author(s)	: E. Chen, V.Gillet
> > 	Filename	: draft-chen-bgp-cease-subcode-00.txt
> > 	Pages		: 4
> > 	Date		: 20-Sep-01
> > 	
> > This document defines several subcodes for the BGP Cease NOTIFICATION
> > message that would provide more information to aid network operators
> > in co-relating network events and diagnosing BGP peering issues.
> > 
> > A URL for this Internet-Draft is:
> > http://www.ietf.org/internet-drafts/draft-chen-bgp-cease-subco
> de-00.txt
> 
> ------- End of Forwarded Message

To: Dan Massey <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: Did the use of LOCAL_PREF change in draft-ietf-idr-bgp4-13? 
Date: Mon, 01 Oct 2001 05:10:45 -0700
From: Yakov Rekhter <[email-masked]>
Sender: [email-masked]

Dan,

> Section 9.1.1, 4th Paragraph:
> 
> | For the newly received or replacement feasible route, the local BGP
> | speaker shall determine a degree of preference.  If the route is
> | learned from an internal peer, the value of the LOCAL_PREF attribute
> | shall be taken as the degree of preference.  ....
> 
> This seems to be a change from RFC 1771 which gives an option of 
> computing the degree of preference based on local policy.  From the 
> same section in RFC 1771:
> 
> | For each newly received or replacement feasible route, the local BGP
> | speaker shall determine a degree of preference. If the route is
> | learned from a BGP speaker in the local autonomous system, either the
> | value of the LOCAL_PREF attribute shall be taken as the degree of
> | preference, or the local system shall compute the degree of
>               ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> | preference of the route based on preconfigured policy information.
>   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

This change from RFC1771 does *not* reflect the deployed implementations.
Therefore I would suggest we'll go back to the rfc1771 text here.

As Tony pointed out, inconsistent LOCAL_PREF could lead to routing
loops, so perhaps we should just add some text to make this clear.

Yakov.