Subject: Re: A question about Route Reflector
From: Enke Chen <[email-masked]>
To: "Ken Rosenfeld" <[email-masked]>
Cc: Yuping Li <[email-masked]>, [email-masked]
Date: Fri, 28 Sep 2001 13:23:21 -0700

> Message-ID: <[email-masked]>
> Date: Fri, 28 Sep 2001 14:57:24 -0400
> From: "Ken Rosenfeld" <[email-masked]>
> Organization: Nortel Networks
> X-Mailer: Mozilla 4.72C-CCK-MCD CUE 6.2H or 8S [en] (X11; U; SunOS 5.6 sun4u)
> X-Accept-Language: en
> MIME-Version: 1.0
> To: Enke Chen <[email-masked]>
> Cc: Yuping Li <[email-masked]>, [email-masked]
> Subject: Re: A question about Route Reflector
> References: <[email-masked]>
> Content-Type: text/plain; charset=us-ascii
> Content-Transfer-Encoding: 7bit
> X-Orig: <[email-masked]>
> 
> Isn't this a problem for redundant RRs?
> 
> Suppose A and B are RRs in cluster 0.0.0.1.
> 
> Suppose A and B are peers, A as a client of B
> and B as a client of A.
> 
> Now A reflects a route to B.  If A prepends
> the cluster id then B will ignore the route.

The fact that A and B are configured with the same cluster-id
implies that they must have the same set of peers (that is a
prerequisite). In that case B does not need the routes reflected
from A.

> 
> The peering between A and B becomes useless.

The peering is used to exchange non-reflected routes (e.g.,
locally sourced or EBGP routes). 

-- Enke

> 
> Thanks,
> 
> Ken
> 
> Enke Chen wrote:
> > 
> > > Message-ID: <[email-masked]>
> > > From: "Yuping Li" <[email-masked]>
> > > To: <[email-masked]>
> > > Subject: A question about Route Reflector
> > > Date: Thu, 27 Sep 2001 15:22:23 -0400
> > > MIME-Version: 1.0
> > >
> > > In RFC1966 section 7, it says
> > >
> > > When a RR reflects a route from its Clients to a Non-Client peer, it
> > > must append the local CLUSTER_ID to the CLUSTER_LIST.
> > >
> > > Then in RFC2796 which updates RFC1966, it says
> > >
> > > When a RR reflects a route, it must prepend the local CLUSTER_ID to
> > > the CLUSTER_LIST.
> > >
> > >
> > > Does it mean that no matter the RR reflects a route from its Clients to =
> > > Clients or to Non-Clients,
> > > it must prepend the local CLUSTER_ID to the CLUSTER_LIST?
> > 
> > Yes.  -- Enke
> > 
> > >
> > >
> > > Thanks.
> > >
> > > Yuping
> > >

Date: Fri, 28 Sep 2001 09:21:26 -0700 (PDT)
From: Dan Pei <[email-masked]>
To: <[email-masked]>
Subject: One comment regarding the AGGREGATOR attribute
Sender: [email-masked]

Hi,

One comment regarding the AGGREGATOR attribute.
Section 9.2.4.2:

| AGGREGATOR: All AGGREGATOR attributes of all routes to be
| aggregated should be ignored.

This is very clear on how to remove any existing AGGREGATOR attributes
present in the more specific routes.  But it did not seem clear that
a new AGGREGATOR attribute could be added at this point.  How about
adding a comment about setting a new AGGREGATOR attribute:

 AGGREGATOR: All AGGREGATOR attributes of all routes to be
 aggregated should be ignored.  The BGP speaker performing
 the route aggregation may attach a new AGGREGATOR attribute which
 shall contain the BGP speaker's own AS number and IP address. The
 IP address should be the same as the BGP Identifier of the speaker.

Thanks,

Dan Massey and Dan Pei

To: "Yuping Li" <[email-masked]>
Cc: [email-masked]
Subject: Re: A question about Route Reflector 
Date: Thu, 27 Sep 2001 13:39:46 -0700
From: Enke Chen <[email-masked]>
Sender: [email-masked]

> Message-ID: <[email-masked]>
> From: "Yuping Li" <[email-masked]>
> To: <[email-masked]>
> Subject: A question about Route Reflector
> Date: Thu, 27 Sep 2001 15:22:23 -0400
> MIME-Version: 1.0
> 
> In RFC1966 section 7, it says
> 
> When a RR reflects a route from its Clients to a Non-Client peer, it
> must append the local CLUSTER_ID to the CLUSTER_LIST.
> 
> Then in RFC2796 which updates RFC1966, it says
> 
> When a RR reflects a route, it must prepend the local CLUSTER_ID to
> the CLUSTER_LIST.=20
> 
> 
> Does it mean that no matter the RR reflects a route from its Clients to =
> Clients or to Non-Clients,
> it must prepend the local CLUSTER_ID to the CLUSTER_LIST?

Yes.  -- Enke

> 
> 
> Thanks.
> 
> Yuping
> 

From: "Yuping Li" <[email-masked]>
To: <[email-masked]>
Subject: A question about Route Reflector
Date: Thu, 27 Sep 2001 15:22:23 -0400
Sender: [email-masked]

This is a multi-part message in MIME format.

------=_NextPart_000_0177_01C14768.350D00A0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

In RFC1966 section 7, it says

When a RR reflects a route from its Clients to a Non-Client peer, it
must append the local CLUSTER_ID to the CLUSTER_LIST.

Then in RFC2796 which updates RFC1966, it says

When a RR reflects a route, it must prepend the local CLUSTER_ID to
the CLUSTER_LIST.=20

Does it mean that no matter the RR reflects a route from its Clients to =
Clients or to Non-Clients,
it must prepend the local CLUSTER_ID to the CLUSTER_LIST?

Thanks.

Yuping

------=_NextPart_000_0177_01C14768.350D00A0
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.4522.1800" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial>In RFC1966 section 7, it says</FONT></DIV>
<DIV><FONT face=3DArial></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial>When a RR reflects a route <STRONG>from its =
Clients to a=20
Non-Client peer</STRONG>, it<BR>must append the local CLUSTER_ID to the=20
CLUSTER_LIST.</FONT></DIV>
<DIV><FONT face=3DArial></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial>Then in RFC2796 which updates RFC1966, it=20
says</FONT></DIV>
<DIV><FONT face=3DArial></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial>When a RR reflects a route, it must prepend the =
local=20
CLUSTER_ID to<BR>the CLUSTER_LIST.&nbsp;</FONT></DIV>
<DIV><FONT face=3DArial></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial>Does it mean that no matter the RR reflects a =
route from=20
its Clients to Clients or to Non-Clients,</FONT></DIV>
<DIV><FONT face=3DArial>it must prepend the local CLUSTER_ID to the=20
CLUSTER_LIST?</FONT></DIV>
<DIV><FONT face=3DArial></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial>Thanks.</FONT></DIV>
<DIV><FONT face=3DArial></FONT>&nbsp;</DIV>
<DIV><FONT face=3DArial>Yuping</FONT></DIV>
<DIV><FONT face=3DArial></FONT>&nbsp;</DIV></BODY></HTML>

------=_NextPart_000_0177_01C14768.350D00A0--

From: Tony Li <[email-masked]>
Date: Wed, 26 Sep 2001 14:47:31 -0700
To: Dan Massey <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Did the use of LOCAL_PREF change in draft-ietf-idr-bgp4-13?
Sender: [email-masked]

Dan,

Inconsistent values of LOCAL_PREF leads immediately to internal routing
loops.  This was deemed a really bad idea.

LOCAL_PREF is a four octet unsigned integer.  All implementations MUST be
prepared to receive all such values.

Tony

Dan Massey writes:
 | 
 | 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.
 |   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
 | 
 | Doesn't removing the option to over-ride the advertised LOCAL_PREF
 | attribute raise new problems with the use of LOCAL_PREF and degree
 | of preference?
 | 
 | In particular, router configurations allow you to set the LOCAL_PREF
 | for both incoming iBGP and eBGP routes. Won't this make those (currently 
 | valid) router configurations non-compliant with the spec?
 | 
 | Also, from a more abstract perspective, what happens in the following
 | scenario:
 | 
 |   router A from vendor A is iBGP peered with a router B from vendor B.
 |   Vendor A uses 0 to 1000 for its range of degree of preference values.
 |   Vendor B uses 0 to 500 for its range of degree of preference values.
 | 
 |   Router A sends router B an iBGP update with a local preference of 700.
 |   According to the draft, router B shall take 700 as the degree of 
 |   preference for the route, even though 700 is not a valid degree of 
 |   preference value on router B??
 | 
 | Dan Pei and Dan Massey

Date: Wed, 26 Sep 2001 17:26:03 -0400
From: Dan Massey <[email-masked]>
To: [email-masked]
Cc: [email-masked], [email-masked]
Subject: Did the use of LOCAL_PREF change in draft-ietf-idr-bgp4-13?
Mail-Followup-To: [email-masked], [email-masked]
Sender: [email-masked]

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

Doesn't removing the option to over-ride the advertised LOCAL_PREF
attribute raise new problems with the use of LOCAL_PREF and degree
of preference?

In particular, router configurations allow you to set the LOCAL_PREF
for both incoming iBGP and eBGP routes. Won't this make those (currently 
valid) router configurations non-compliant with the spec?

Also, from a more abstract perspective, what happens in the following
scenario:

  router A from vendor A is iBGP peered with a router B from vendor B.
  Vendor A uses 0 to 1000 for its range of degree of preference values.
  Vendor B uses 0 to 500 for its range of degree of preference values.

  Router A sends router B an iBGP update with a local preference of 700.
  According to the draft, router B shall take 700 as the degree of 
  preference for the route, even though 700 is not a valid degree of 
  preference value on router B??

Dan Pei and Dan Massey

From: Randy Bush <[email-masked]>
To: Yakov Rekhter <[email-masked]>
Cc: [email-masked]
Subject: Re: interoperability report for 2842
Date: Wed, 26 Sep 2001 12:41:49 -0700
Sender: [email-masked]

note that this is supposed to be feature-by-feature, i.e. for every
feature, two implementations must interoperate.  this does not imply
that all implementations must implement all features.  nor does it
imply that all which implement some feature must interoperate, though
that latter would be *very* desirable.

the thinking here is that this is testing that the spec is clear enough
that two separate implementors [mis-]interpreted it in a consistent
fashion.  it is NOT a test of implementations.  it is common practice,
to say which implementations participated in the testing, but in the
details of the results to use "implementation A," "implementation B,"
etc.

randy

To: [email-masked]
Subject: interoperability report for 2842
Date: Wed, 26 Sep 2001 12:34:00 -0700
From: Yakov Rekhter <[email-masked]>
Sender: [email-masked]

Folks,

As part of advancing BGP Capabilities Advertisement to Draft Standard
we need to have a list of vendors who implemented this, and the
information on interoperability (please note that this information
needs to be public).

With this in mind I would greatly appreciate if vendors who implemented
2842 would send me an e-mail stating that they implemented it, and
also whether their implementation interoperates with other
implementations (please list the other implementations). I'll compile
this information and make it available as an implementation report
(along the lines of other implementation reports 
http://www.ietf.org/IESG/implementation.html)

The deadline for this information is Oct 9.

Yakov.
------- Forwarded Message

Date:    Tue, 25 Sep 2001 12:41:37 -0700
From:    Yakov Rekhter <[email-masked]>
To:      [email-masked]
Subject: 2842 to Draft Standard

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

Yakov.

------- End of Forwarded Message

Date: Wed, 26 Sep 2001 14:29:58 -0400
From: Dan Massey <[email-masked]>
To: [email-masked]
Subject: Re: revised Internet Draft
Mail-Followup-To: [email-masked]
Sender: [email-masked]

On Sunday, September 23, 2001 at 07:57AM, Yakov Rekhter wrote:
| > Page 29, Paragraph 1:
| > 
| > |    Semantic correctness applies only to the external BGP links.
| > |    It means that the interface associated with the IP address, as
| > |    specified in the NEXT_HOP attribute, shares a common subnet with the
| > |    receiving BGP speaker (unless the speaker has been configured to run
| > |    the external BGP session over multiple IP hops), and is not the IP
| > |    address of the receiving BGP speaker.  ....
| > 
| > Multiple hop BGP is not discussed prior to this and the wording differs
| > from how the NEXT_HOP was described in 5.1.3.  We were concerned that there
| > may be some rare cases where the NEXT_HOP attribute is valid according to
| > section 5.1.3 but will be ignored according to this rule.  To make the
| > wording consistent, we suggest:
| > 
| >      Semantic correctness applies only to the external BGP links.
| >      To be semantically correct, the IP address in the NEXT_HOP must
| >      not be the IP address of the receiving speaker and the NEXT_HOP IP
| >      address must either be the sender's IP address (used to establish the
| >      BGP session) or the interface associated with the NEXT_HOP IP address
| >      must share a common subnet with the receiving BGP speaker. ...
| 
| I don't think this is exactly correct, as in the case of
| multihop eBGP, the address carried in the NEXT HOP may be neither
| the sender's address, nor an address that shares a common subnet
| with the receiring BGP speaker.
| 

What is an allowable next hop for multihop eBGP?

Looking at section 5.1.3, there are 4 possibilities for setting NEXT_HOP
when sending to external peer X (multihop or single hop).  The first three
all include variations of "provided that peer X shares a common subnet
with the NEXT_HOP address".  The fourth condition is that the NEXT_HOP can
be the sender's IP address.  (Dan Pei and I had considered the multihop case
and thought the 4th condition was mostly intended to handle this...)

Anyway, no objections to your statement about other possible NEXT_HOPs for
multihop eBGP, but then 5.1.3 should be revised to allow this.

Thanks,
Dan

Date: Tue, 25 Sep 2001 16:18:08 -0700 (PDT)
From: Edward Crabbe <[email-masked]>
To: Dan Pei <[email-masked]>
Cc: Antal Sasvari <[email-masked]>, [email-masked]
Subject: Re: revised Internet Draft
Sender: [email-masked]

> So in this context, does an "unfeasible route" equal to an "unresolvable
> route" defined in 9.1.2.1?

ya.

> If so, would it be clearer to change the wording from:
> 
> (page 41, section 9.1.2 last paragraph)
> 
> !   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.
> 
> to wording like the following to avoid any confusion?
> 
>     If a BGP route in Loc-RIB becomes unresolvable, it SHALL be removed
>     from the Loc-RIB and the routing table. However, the corresponding
>     unresolvable route SHOULD be kept in the Adj-RIB-In.

With the use of 'unfeasible' in 4.3 as a description of a withdrawn
route it might be less confusing for implementors (allthough it 
seems clear to me in the current wording).

s/unfeasible/unresolvable in the above text for agreement
with 9.1.2.1?

Date: Tue, 25 Sep 2001 15:19:55 -0700 (PDT)
From: Dan Pei <[email-masked]>
To: Edward Crabbe <[email-masked]>
Cc: Antal Sasvari <[email-masked]>, <[email-masked]>
Subject: Re: revised Internet Draft
Sender: [email-masked]

Hi, Ed,

>
> Hi Antal.
>
>
> > Another question I would like to ask is:
> >
> > At the end of 9.1.2. Phase 2:
> > >   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.
> >
> > But I think the unfeasible routes were removed from the Adj-RIB-In
> > during Internal updates (9.2.1), which occurs after Phase 1:
> > >   When a BGP speaker receives an UPDATE message with a non-empty
> > >   WITHDRAWN ROUTES field, it shall remove from its Adj-RIB-In all
> > >   routes whose destinations were carried in this field (as IP
> > >   prefixes).
>
> I think you/we are confusing withdrawn routes with nh invalid
> routes.  A withdrawn route is one that is to be removed explicitly
> as indicated  by its presence in the withdrawn routes field of the
> update message. an unfeasible route in THIS context is one who's
> nexthop is not known or is invalid, and is thus ineligible for entry
> into loc-rib, .
>

So in this context, does an "unfeasible route" equal to an "unresolvable
route" defined in 9.1.2.1?

If so, would it be clearer to change the wording from:

(page 41, section 9.1.2 last paragraph)

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

to wording like the following to avoid any confusion?

    If a BGP route in Loc-RIB becomes unresolvable, it SHALL be removed
    from the Loc-RIB and the routing table. However, the corresponding
    unresolvable route SHOULD be kept in the Adj-RIB-In.

Thanks,
--
Dan

To: [email-masked]
Subject: 2842 to Draft Standard
Date: Tue, 25 Sep 2001 12:41:37 -0700
From: Yakov Rekhter <[email-masked]>
Sender: [email-masked]

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

Yakov.

Date: Tue, 25 Sep 2001 14:15:33 +0200
From: Antal Sasvari <[email-masked]>
To: [email-masked]
Subject: Re: revised Internet Draft, decision process
Sender: [email-masked]

Hi!

Thanks for the answers, Ed!

Another point, which is unclear for me about the decision process is, that
the Internal  Update Process is executed at the end of Phase 1, and the
External Update Process at the end of Phase 3. Why are they separated like
this? As I understood the mechanism, the internal updates cannot be sent
until the best routes are selected in Phase 2, and installed into the
Loc-RIB, because the entries into the Adj-RIBs-Out for both the internal and
external peers are selected from the Loc-RIB (at least logically). Why aren't
both internal and external updates made after Phase 3?
Thanks a lot in advance,
Anthony

Edward Crabbe wrote:

> I think you/we are confusing withdrawn routes with nh invalid
> routes.  A withdrawn route is one that is to be removed explicitly
> as indicated  by its presence in the withdrawn routes field of the
> update message. an unfeasible route in THIS context is one who's
> nexthop is not known or is invalid, and is thus ineligible for entry
> into loc-rib, .
>
> I think I can see the cause for confusion as the term unfeasible is
> applied elsewhere to routes advertised in the withdrawn routes field,
> esp in  4.3.  This is valid terminology, applicable to both
> situations.
> ...

>
> my prolix 1c.
>
>         -ed

Date: Mon, 24 Sep 2001 16:37:57 -0700
From: Ben Black <[email-masked]>
To: Jeffrey Haas <[email-masked]>
Cc: Yakov Rekhter <[email-masked]>, Dan Pei <[email-masked]>, [email-masked], [email-masked]
Subject: Re: revised Internet Draft
Sender: [email-masked]

On Mon, Sep 24, 2001 at 07:51:27PM -0400, Jeffrey Haas wrote:
> On Mon, Sep 24, 2001 at 04:07:39PM -0700, Ben Black wrote:
> > Wouldn't the suggested changes be obviated by simply saying that exactly
> > one of the 3 methods for withdrawing a route may be used for given NLRI?
> 
> 1   - declare this invalid and send a notify
> 2   - assume the withdraw takes precedence
> 3   - assume the advertisement takes precedence
> 

Sorry, ambiguity on my part.  The 3 methods to which I was referring
are those used for withdrawing a route, not the 3 options presented for
handling questionable updates.

> 
> "The withdrawn routes field must be processed before the NLRI."
> 

I've suggested this same change in private email, but I don't like it now.  I
think it assumes a certain, specific problem in the packet format.  I prefer
your language as it does not assume much about an implementation.

Ben

Date: Mon, 24 Sep 2001 16:32:34 -0700
From: Ben Black <[email-masked]>
To: Jeffrey Haas <[email-masked]>
Cc: Yakov Rekhter <[email-masked]>, Dan Pei <[email-masked]>, [email-masked], [email-masked]
Subject: Re: revised Internet Draft
Sender: [email-masked]

Rather, specifying behavior on receipt of such an UPDATE is only half the
equation, as there is no language prohibiting generation of these messages.

Something like the following would take care of this:

***************
*** 280,286 ****
     BGP provides mechanisms by which a BGP speaker can inform its peer
     that a previously advertised route is no longer available for use.
     There are three methods by which a given BGP speaker can indicate
!    that a route has been withdrawn from service:
  
        a) the IP prefix that expresses the destination for a previously
        advertised route can be advertised in the WITHDRAWN ROUTES field
--- 280,287 ----
     BGP provides mechanisms by which a BGP speaker can inform its peer
     that a previously advertised route is no longer available for use.
     There are three methods by which a given BGP speaker can indicate
!    that a route has been withdrawn from service, exactly one of which
!    must be used to withdraw a given route:
  
        a) the IP prefix that expresses the destination for a previously
        advertised route can be advertised in the WITHDRAWN ROUTES field

On Mon, Sep 24, 2001 at 04:07:39PM -0700, Ben Black wrote:
> Wouldn't the suggested changes be obviated by simply saying that exactly
> one of the 3 methods for withdrawing a route may be used for given NLRI?
> 
> 
> Ben
> 

Date: Mon, 24 Sep 2001 19:51:27 -0400
From: Jeffrey Haas <[email-masked]>
To: Ben Black <[email-masked]>
Cc: Yakov Rekhter <[email-masked]>, Dan Pei <[email-masked]>, [email-masked], [email-masked]
Subject: Re: revised Internet Draft
Sender: [email-masked]

On Mon, Sep 24, 2001 at 04:07:39PM -0700, Ben Black wrote:
> Wouldn't the suggested changes be obviated by simply saying that exactly
> one of the 3 methods for withdrawing a route may be used for given NLRI?

1   - declare this invalid and send a notify
2   - assume the withdraw takes precedence
3   - assume the advertisement takes precedence

I believe we've (collectively) decided that 1 is evil.

2 implies that you process withdraws last, always.
3 is equivalent in eventual action to the suggested wording changes.

My suggested changes were also an attempt to indicate that the
entire UPDATE PDU should be processed before sending UPDATEs based on
that.  Matt Richardson (also with NextHop) just suggested that it
may be cleaner to just say something along the lines of:

"The withdrawn routes field must be processed before the NLRI."

This means it is just as valid to send an UPDATE containing a WITHDRAW
and another update with reachability in sequence although it would
mean transient unreachability and more route flapping.

I admit my wording is awkward.  Any suggestions?

> Ben

-- 
Jeff Haas 
NextHop Technologies

Date: Mon, 24 Sep 2001 16:07:39 -0700
From: Ben Black <[email-masked]>
To: Jeffrey Haas <[email-masked]>
Cc: Yakov Rekhter <[email-masked]>, Dan Pei <[email-masked]>, [email-masked], [email-masked]
Subject: Re: revised Internet Draft
Sender: [email-masked]

Wouldn't the suggested changes be obviated by simply saying that exactly
one of the 3 methods for withdrawing a route may be used for given NLRI?

Ben

On Mon, Sep 24, 2001 at 07:14:47PM -0400, Jeffrey Haas wrote:
> On Sun, Sep 23, 2001 at 07:57:37AM -0700, Yakov Rekhter wrote:
> > > What is the appropriate action if the same NLRI is listed in both
> > > the withdrawn and feasible routes.  In this case, should the peer
> > > 
> > >   - declare this invalid and send a notify
> > >   - assume the withdraw takes precedence
> > >   - assume the advertisement takes precedence
> > 
> > Let me poll the implementors to see how this case is handled
> > by the existing implementations. 
> 
> GateD will first process the withdraw and then the NLRI.  As we process
> the entire BGP PDU before sending UPDATEs, the effect is the same
> as if we had just received the NLRI in the feasible routes section.
> 
> I suggest the following wording change to the specification:
> 
> ***************
> *** 986,996 ****
>      context of the BGP speaker - BGP speaker connection to which it has
>      been previously advertised.
>   
> !    An UPDATE message may advertise only routes to be withdrawn from
>      service, in which case it will not include path attributes or Network
>      Layer Reachability Information. Conversely, it may advertise only a
>      feasible route, in which case the WITHDRAWN ROUTES field need not be
>      present.
>   
>   
>   4.4 KEEPALIVE Message Format
> --- 986,1002 ----
>      context of the BGP speaker - BGP speaker connection to which it has
>      been previously advertised.
>   
> !    An UPDATE message might advertise only routes to be withdrawn from
>      service, in which case it will not include path attributes or Network
>      Layer Reachability Information. Conversely, it may advertise only a
>      feasible route, in which case the WITHDRAWN ROUTES field need not be
>      present.
> + 
> +    An UPDATE message should not include the same destination in the
> +    WITHDRAWN ROUTES and Network Layer Reachability Information fields,
> +    however a BGP speaker must be able to process UPDATE messages in this
> +    form.  A BGP speaker should treat an UPDATE message of this form as if
> +    it contained only the destination to be advertised.
> 
> The first wording change removes the ambiguity of "may" as possibly
> meaning "ought to" or "must"
> 
> > Yakov.
> 
> -- 
> Jeff Haas 
> NextHop Technologies

Date: Mon, 24 Sep 2001 19:18:38 -0400
From: Jeffrey Haas <[email-masked]>
To: Dan Pei <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: revised Internet Draft
Sender: [email-masked]

Minor change suggested:

On Fri, Sep 21, 2001 at 04:40:39PM -0700, Dan Pei wrote:
> The initial data flow is the portion of the BGP routing table that is
> allowed by the export policy.  

Change to:

: The initial data flow is the portion of the BGP routing table that is
: allowed by the export policy, called the Adj-Ribs-Out (see 3.2.c).

-- 
Jeff Haas 
NextHop Technologies

Date: Mon, 24 Sep 2001 19:14:47 -0400
From: Jeffrey Haas <[email-masked]>
To: Yakov Rekhter <[email-masked]>
Cc: Dan Pei <[email-masked]>, [email-masked], [email-masked]
Subject: Re: revised Internet Draft
Sender: [email-masked]

On Sun, Sep 23, 2001 at 07:57:37AM -0700, Yakov Rekhter wrote:
> > What is the appropriate action if the same NLRI is listed in both
> > the withdrawn and feasible routes.  In this case, should the peer
> > 
> >   - declare this invalid and send a notify
> >   - assume the withdraw takes precedence
> >   - assume the advertisement takes precedence
> 
> Let me poll the implementors to see how this case is handled
> by the existing implementations. 

GateD will first process the withdraw and then the NLRI.  As we process
the entire BGP PDU before sending UPDATEs, the effect is the same
as if we had just received the NLRI in the feasible routes section.

I suggest the following wording change to the specification:

***************
*** 986,996 ****
     context of the BGP speaker - BGP speaker connection to which it has
     been previously advertised.
  
!    An UPDATE message may advertise only routes to be withdrawn from
     service, in which case it will not include path attributes or Network
     Layer Reachability Information. Conversely, it may advertise only a
     feasible route, in which case the WITHDRAWN ROUTES field need not be
     present.

  4.4 KEEPALIVE Message Format
--- 986,1002 ----
     context of the BGP speaker - BGP speaker connection to which it has
     been previously advertised.
  
!    An UPDATE message might advertise only routes to be withdrawn from
     service, in which case it will not include path attributes or Network
     Layer Reachability Information. Conversely, it may advertise only a
     feasible route, in which case the WITHDRAWN ROUTES field need not be
     present.
+ 
+    An UPDATE message should not include the same destination in the
+    WITHDRAWN ROUTES and Network Layer Reachability Information fields,
+    however a BGP speaker must be able to process UPDATE messages in this
+    form.  A BGP speaker should treat an UPDATE message of this form as if
+    it contained only the destination to be advertised.

The first wording change removes the ambiguity of "may" as possibly
meaning "ought to" or "must"

> Yakov.

-- 
Jeff Haas 
NextHop Technologies

Date: Mon, 24 Sep 2001 10:05:45 -0700 (PDT)
From: Edward Crabbe <[email-masked]>
To: Antal Sasvari <[email-masked]>
Cc: [email-masked]
Subject: Re: revised Internet Draft
Sender: [email-masked]

Hi Antal.

> Another question I would like to ask is:
> 
> At the end of 9.1.2. Phase 2:
> >   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.
> 
> But I think the unfeasible routes were removed from the Adj-RIB-In
> during Internal updates (9.2.1), which occurs after Phase 1:
> >   When a BGP speaker receives an UPDATE message with a non-empty
> >   WITHDRAWN ROUTES field, it shall remove from its Adj-RIB-In all
> >   routes whose destinations were carried in this field (as IP
> >   prefixes).

I think you/we are confusing withdrawn routes with nh invalid 
routes.  A withdrawn route is one that is to be removed explicitly 
as indicated  by its presence in the withdrawn routes field of the 
update message. an unfeasible route in THIS context is one who's 
nexthop is not known or is invalid, and is thus ineligible for entry 
into loc-rib, .  

I think I can see the cause for confusion as the term unfeasible is 
applied elsewhere to routes advertised in the withdrawn routes field, 
esp in  4.3.  This is valid terminology, applicable to both
situations.

esp. since:

in section 9:

   If the UPDATE message contains a non-empty WITHDRAWN ROUTES field,
   the previously advertised routes whose destinations (expressed as IP
   prefixes) contained in this field shall be removed from the Adj-RIB-
   In.  This BGP speaker shall run its Decision Process since the
   previously advertised route is no longer available for use.

and context may be derived from two preceding paragraphs:

   The local speaker MUST determine the immediate next hop to the
   address depicted by the NEXT_HOP attribute of the selected route by
   performing a best matching route lookup in the Routing Table and
   selecting one of the possible paths (if multiple best paths to the
   same prefix are available). If the route to the address depicted by
   the NEXT_HOP attribute changes such that the immediate next hop or
   the IGP cost to the NEXT_HOP (if the NEXT_HOP is resolved through an
   IGP route) changes, route selection should be recalculated as
   specified above.

   Notice that even though BGP routes do not have to be installed in the
   Routing Table with the immediate next hop(s), implementations must
   take care that before any packets are forwarded along a BGP route,
   it's associated NEXT_HOP address is resolved to the immediate
   (directly connected) next-hop address and this address (or multiple
   addresses) is finally used for actual packet forwarding.

   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.

my prolix 1c.

	-ed

Date: Mon, 24 Sep 2001 10:17:38 -0400 (EDT)
From: Susan Harris <[email-masked]>
To: Ben Black <[email-masked]>
Cc: [email-masked]
Subject: Re: archives for 1999 and 2000?
Sender: [email-masked]

Give this a try:

	ftp://ftp.ietf.org/ietf-mail-archive/idr/

On Sun, 23 Sep 2001, Ben Black wrote:

> Where might I find the archives for this list for previous years?  I see
> only archives from the last 5 months or so on ftp.merit.edu.
> 
> 
> Thanks,
> Ben
> 
> 

Date: Mon, 24 Sep 2001 13:14:52 +0200
From: Antal Sasvari <[email-masked]>
To: [email-masked]
Subject: Re: revised Internet Draft
Sender: [email-masked]

Hi!

I would like to ask some questions regarding the decision process:

In 9.2.1 is written that:

> When a BGP speaker receives a new route from an external peer, it
> MUST advertise that route to all other internal peers by means of an
> UPDATE message if this route will be installed in its Loc-RIB
> according to the route selection rules in 9.1.2.

The "Breaking Ties (Internal Updates)" chapter isn't mentioned any more,
and also for me, it seems logical to say "if the will be installed in
its Loc-RIB". But, why do we need the "9.2.1.1 Breaking Ties (Internal
Updates)" chapter than? If I see the Decision Process correctly, then
the best route selection algorithm is described in "9.1.2.2 Breaking
Ties (Phase 2)", and in Phase 1 I have to propagate the best route to
the internal peers, that will be selected in Phase 2.
It also sounds a bit weird for me, that I should advertise the
externally received route for the internal peers (in Phase 1), if it
will be selected as the best route in Phase 2. So, does the best route
selection actually happen during Phase 1, internal updates?

Another question I would like to ask is:

At the end of 9.1.2. Phase 2:
>   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.

But I think the unfeasible routes were removed from the Adj-RIB-In
during Internal updates (9.2.1), which occurs after Phase 1:
>   When a BGP speaker receives an UPDATE message with a non-empty
>   WITHDRAWN ROUTES field, it shall remove from its Adj-RIB-In all
>   routes whose destinations were carried in this field (as IP
>   prefixes).
Did I misunderstand something, or which one is correct?

Thaks a lot in advance,
    Anthony

Date: Sun, 23 Sep 2001 17:36:13 -0700
From: Ben Black <[email-masked]>
To: [email-masked]
Subject: archives for 1999 and 2000?
Sender: [email-masked]

Where might I find the archives for this list for previous years?  I see
only archives from the last 5 months or so on ftp.merit.edu.

Thanks,
Ben

Date: Sun, 23 Sep 2001 20:27:16 -0400
To: Ben Black <[email-masked]>
From: Susan Hares <[email-masked]>
Subject: Re: revised Internet Draft
Cc: Yakov Rekhter <[email-masked]>, Dan Pei <[email-masked]>, [email-masked], [email-masked]
Sender: [email-masked]

Ben:

         Your comments and other people comments caused
         Yakov's call in August was to have everyone who had
         made these comments to submit specific changes
         to him.    That was your cue to put in your suggested changes to
         the document.

         As to the specific topic, I believe other people from my company
         have raised this as an  implementation issues as well.   We will 
be responding to
         Yakov's question from our NextHop GateD implementation of BGP.

Sue

At 01:50 PM 9/23/2001 -0700, Ben Black wrote:
>On Sun, Sep 23, 2001 at 07:57:37AM -0700, Yakov Rekhter wrote:
> > >
> > > What is the appropriate action if the same NLRI is listed in both
> > > the withdrawn and feasible routes.  In this case, should the peer
> > >
> > >   - declare this invalid and send a notify
> > >   - assume the withdraw takes precedence
> > >   - assume the advertisement takes precedence
> >
> > Let me poll the implementors to see how this case is handled
> > by the existing implementations.
> >
>
>I raised this exact issue with Sue in Minneapolis.  Did it get blackholed?
>
>
>Ben

Date: Sun, 23 Sep 2001 13:50:58 -0700
From: Ben Black <[email-masked]>
To: Yakov Rekhter <[email-masked]>
Cc: Dan Pei <[email-masked]>, [email-masked], [email-masked]
Subject: Re: revised Internet Draft
Sender: [email-masked]

On Sun, Sep 23, 2001 at 07:57:37AM -0700, Yakov Rekhter wrote:
> > 
> > What is the appropriate action if the same NLRI is listed in both
> > the withdrawn and feasible routes.  In this case, should the peer
> > 
> >   - declare this invalid and send a notify
> >   - assume the withdraw takes precedence
> >   - assume the advertisement takes precedence
> 
> Let me poll the implementors to see how this case is handled
> by the existing implementations. 
> 

I raised this exact issue with Sue in Minneapolis.  Did it get blackholed?

Ben

To: [email-masked]
Cc: Dan Pei <[email-masked]>
Subject: withdraw and announce in the same update
Date: Sun, 23 Sep 2001 08:01:05 -0700
From: Yakov Rekhter <[email-masked]>
Sender: [email-masked]

Folks,

Dan Pei asked the following questions:

  What is the appropriate action if the same NLRI is listed in both
  the withdrawn and feasible routes.  In this case, should the peer

  - declare this invalid and send a notify
  - assume the withdraw takes precedence
  - assume the advertisement takes precedence

I would greatly appreciate if folks who implemented BGP4
would drop me a note describing how their implementation
handles this case, so that I could document the existing
practice in the next revision of bgp4 spec.

Yakov.

To: Dan Pei <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: revised Internet Draft 
Date: Sun, 23 Sep 2001 07:57:37 -0700
From: Yakov Rekhter <[email-masked]>
Sender: [email-masked]

Dan,

> Hi,
> 	Here are some of our comments on the draft.
> 
> Thanks!
> 
> Dan Pei and Dan Massey
> ------------------------------------
> 
> Page 4, Paragraph 2:
> 
> |   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.
> 
> We are concerned with the term "entire BGP routing table".  In fact,
> "the entire BGP routing table" is never known or exchanged since
> the peer's policy may limit what routes are sent. Perhaps the
> following text better reflects this:
> 
> The initial data flow is the portion of the BGP routing table that is
> allowed by the export policy.  Incremental updates are sent as the
> routing tables change.  BGP does not require periodic refresh of the
> routing table.  Therefore, A BGP speaker must retain the current version
> of the routes advertised by all of its peers for the duration of the
> connection.

Fixed.

> Page 23, Bullet 3:
> 
> | By default (if none of the above conditions apply), the BGP
> | speaker should use in the NEXT_HOP attribute the IP address
> | that is used to establish the BGP session.
> 
> The "IP address that is used to establish the BGP session" might
> be taken to mean two things.  It could mean the IP address of the
> peer (say from "neighbor IP_Address remote-as #").  Or it could mean
> the IP address of the local interface used to reach the peer.  In
> this context, the second meaning is what is intended, we think :)
> To avoid confusion, how about the wording:
> 
> By default (if none of the above conditions apply), the BGP
> speaker should use in the NEXT_HOP attribute the local IP address
> of the interface that is used to establish the BGP session to peer X.

Fixed.

> Page 29, Paragraph 1:
> 
> |    Semantic correctness applies only to the external BGP links.
> |    It means that the interface associated with the IP address, as
> |    specified in the NEXT_HOP attribute, shares a common subnet with the
> |    receiving BGP speaker (unless the speaker has been configured to run
> |    the external BGP session over multiple IP hops), and is not the IP
> |    address of the receiving BGP speaker.  ....
> 
> Multiple hop BGP is not discussed prior to this and the wording differs
> from how the NEXT_HOP was described in 5.1.3.  We were concerned that there
> may be some rare cases where the NEXT_HOP attribute is valid according to
> section 5.1.3 but will be ignored according to this rule.  To make the
> wording consistent, we suggest:
> 
>      Semantic correctness applies only to the external BGP links.
>      To be semantically correct, the IP address in the NEXT_HOP must
>      not be the IP address of the receiving speaker and the NEXT_HOP IP
>      address must either be the sender's IP address (used to establish the
>      BGP session) or the interface associated with the NEXT_HOP IP address
>      must share a common subnet with the receiving BGP speaker. ...

I don't think this is exactly correct, as in the case of
multihop eBGP, the address carried in the NEXT HOP may be neither
the sender's address, nor an address that shares a common subnet
with the receiring BGP speaker.

> Section 9, Paragraphs 4 and 5:
> 
> |   If the UPDATE message contains a non-empty WITHDRAWN ROUTES field,
> |   the previously advertised routes whose destinations (expressed as IP
> |   prefixes) contained in this field shall be removed from the Adj-RIB-
> |   In.  This BGP speaker shall run its Decision Process since the
> |   previously advertised route is no longer available for use.
> |
> |   If the UPDATE message contains a feasible route, it shall be placed
> |   in the appropriate Adj-RIB-In, and the following additional actions
> |   shall be taken:
> 
> What is the appropriate action if the same NLRI is listed in both
> the withdrawn and feasible routes.  In this case, should the peer
> 
>   - declare this invalid and send a notify
>   - assume the withdraw takes precedence
>   - assume the advertisement takes precedence

Let me poll the implementors to see how this case is handled
by the existing implementations. 

Yakov.

To: Xiaoliang Zhao <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: BGP community attribute questions, please help 
Date: Sun, 23 Sep 2001 07:33:50 -0700
From: Yakov Rekhter <[email-masked]>
Sender: [email-masked]

Xiaoliang,

> Hi, we have a couple of questions about BGP community attribute, can
> you help us to clarify?
> 
> In draft-ietf-idr-bgp-ext-communities-01.txt, is it mandatory to
> propogate an extended communities attribute that has the transitive
> bit set?

According to the current spec this is *not* mandatory. 

Yakov.

Date: Fri, 21 Sep 2001 16:40:39 -0700 (PDT)
From: Dan Pei <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Subject: Re: revised Internet Draft
Sender: [email-masked]

Hi,
	Here are some of our comments on the draft.

Thanks!

Dan Pei and Dan Massey
------------------------------------

Page 4, Paragraph 2:

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

We are concerned with the term "entire BGP routing table".  In fact,
"the entire BGP routing table" is never known or exchanged since
the peer's policy may limit what routes are sent. Perhaps the
following text better reflects this:

The initial data flow is the portion of the BGP routing table that is
allowed by the export policy.  Incremental updates are sent as the
routing tables change.  BGP does not require periodic refresh of the
routing table.  Therefore, A BGP speaker must retain the current version
of the routes advertised by all of its peers for the duration of the
connection.

Page 23, Bullet 3:

| By default (if none of the above conditions apply), the BGP
| speaker should use in the NEXT_HOP attribute the IP address
| that is used to establish the BGP session.

The "IP address that is used to establish the BGP session" might
be taken to mean two things.  It could mean the IP address of the
peer (say from "neighbor IP_Address remote-as #").  Or it could mean
the IP address of the local interface used to reach the peer.  In
this context, the second meaning is what is intended, we think :)
To avoid confusion, how about the wording:

By default (if none of the above conditions apply), the BGP
speaker should use in the NEXT_HOP attribute the local IP address
of the interface that is used to establish the BGP session to peer X.

Page 29, Paragraph 1:

|    Semantic correctness applies only to the external BGP links.
|    It means that the interface associated with the IP address, as
|    specified in the NEXT_HOP attribute, shares a common subnet with the
|    receiving BGP speaker (unless the speaker has been configured to run
|    the external BGP session over multiple IP hops), and is not the IP
|    address of the receiving BGP speaker.  ....

Multiple hop BGP is not discussed prior to this and the wording differs
from how the NEXT_HOP was described in 5.1.3.  We were concerned that there
may be some rare cases where the NEXT_HOP attribute is valid according to
section 5.1.3 but will be ignored according to this rule.  To make the
wording consistent, we suggest:

     Semantic correctness applies only to the external BGP links.
     To be semantically correct, the IP address in the NEXT_HOP must
     not be the IP address of the receiving speaker and the NEXT_HOP IP
     address must either be the sender's IP address (used to establish the
     BGP session) or the interface associated with the NEXT_HOP IP address
     must share a common subnet with the receiving BGP speaker. ...

Section 9, Paragraphs 4 and 5:

|   If the UPDATE message contains a non-empty WITHDRAWN ROUTES field,
|   the previously advertised routes whose destinations (expressed as IP
|   prefixes) contained in this field shall be removed from the Adj-RIB-
|   In.  This BGP speaker shall run its Decision Process since the
|   previously advertised route is no longer available for use.
|
|   If the UPDATE message contains a feasible route, it shall be placed
|   in the appropriate Adj-RIB-In, and the following additional actions
|   shall be taken:

What is the appropriate action if the same NLRI is listed in both
the withdrawn and feasible routes.  In this case, should the peer

  - declare this invalid and send a notify
  - assume the withdraw takes precedence
  - assume the advertisement takes precedence

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

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

Date: 21 Sep 2001 13:33:32 MDT
From: Curtis Call <[email-masked]>
To: "proto man" <[email-masked]>
Subject: Re: [Re: [connect -> openSent]]
Cc: [email-masked]
Sender: [email-masked]

You're right.  I am assuming that this was just an oversight and that it was
intended for it to happen the same whether it transitions from Connect to
OpenSent or Active to OpenSent.  This line in the description of OpenSent
leads me to believe this:

The Hold Timer, which was originally set to a large value (see above), is
replaced with the negotiated Hold Time value (see section 4.2).

It didn't make a distinction between Active or Connect in this situation, just
that the Hold Timer had been set to a large value.

"proto man" <[email-masked]> wrote:
> Hi,
> The draft states that for transition from active to openSent,
> but does not explicitly state for connection to openSent..
> 
> Priya.
> 
> 
> >From: Curtis Call <[email-masked]>
> >To: "proto man" <[email-masked]>
> >CC: [email-masked]
> >Subject: Re: [connect -> openSent]
> >Date: 21 Sep 2001 12:51:04 MDT
> >
> >The Hold timer is started (and set to a higher value, like 4 minutes or
> >whatever the implementors decide).  If it expires then the peer session 
> >goes
> >back to Idle.
> >
> >
> >"proto man" <[email-masked]> wrote:
> > > Folks,
> > >   Upon transitioning from connect to openSent state, no timer
> > >   seems to be started. Is it possible to get stuck in openSent
> > >   state should the remote end die.
> > >
> > >   Or a TCP disconnect is expected under all circumstances?
> > >
> > > Thanks,
> > > Priya Moniker.
> > >
> > > _________________________________________________________________
> > > Get your FREE download of MSN Explorer at 
> >http://explorer.msn.com/intl.asp
> > >
> >
> 
> 
> _________________________________________________________________
> Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp
> 

From: "proto man" <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Subject: Re: [connect -> openSent]
Date: Fri, 21 Sep 2001 19:23:00 +0000
Sender: [email-masked]

Hi,
The draft states that for transition from active to openSent,
but does not explicitly state for connection to openSent..

Priya.

>From: Curtis Call <[email-masked]>
>To: "proto man" <[email-masked]>
>CC: [email-masked]
>Subject: Re: [connect -> openSent]
>Date: 21 Sep 2001 12:51:04 MDT
>
>The Hold timer is started (and set to a higher value, like 4 minutes or
>whatever the implementors decide).  If it expires then the peer session 
>goes
>back to Idle.
>
>
>"proto man" <[email-masked]> wrote:
> > Folks,
> >   Upon transitioning from connect to openSent state, no timer
> >   seems to be started. Is it possible to get stuck in openSent
> >   state should the remote end die.
> >
> >   Or a TCP disconnect is expected under all circumstances?
> >
> > Thanks,
> > Priya Moniker.
> >
> > _________________________________________________________________
> > Get your FREE download of MSN Explorer at 
>http://explorer.msn.com/intl.asp
> >
>

_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp

Date: 21 Sep 2001 12:51:04 MDT
From: Curtis Call <[email-masked]>
To: "proto man" <[email-masked]>
Subject: Re: [connect -> openSent]
Cc: [email-masked]
Sender: [email-masked]

The Hold timer is started (and set to a higher value, like 4 minutes or
whatever the implementors decide).  If it expires then the peer session goes
back to Idle.

"proto man" <[email-masked]> wrote:
> Folks,
>   Upon transitioning from connect to openSent state, no timer
>   seems to be started. Is it possible to get stuck in openSent
>   state should the remote end die.
> 
>   Or a TCP disconnect is expected under all circumstances?
> 
> Thanks,
> Priya Moniker.
> 
> _________________________________________________________________
> Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp
> 

From: "proto man" <[email-masked]>
To: [email-masked]
Subject: connect -> openSent
Date: Fri, 21 Sep 2001 17:37:49 +0000
Sender: [email-masked]

Folks,
  Upon transitioning from connect to openSent state, no timer
  seems to be started. Is it possible to get stuck in openSent
  state should the remote end die.

  Or a TCP disconnect is expected under all circumstances?

Thanks,
Priya Moniker.

_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp

Date: Fri, 21 Sep 2001 12:21:22 -0400 (EDT)
From: Xiaoliang Zhao <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Subject: BGP community attribute questions, please help
Sender: [email-masked]

Hi, we have a couple of questions about BGP community attribute, can
you help us to clarify?

In draft-ietf-idr-bgp-ext-communities-01.txt, is it mandatory to
propogate an extended communities attribute that has the transitive
bit set?

We think this would be a useful requirement.  For example, suppose 
we would like to attach a transitive extended communities attribute 
at the origin AS and have this attribute propoagate along with the
route to remote ASes.  Our concern is that some intermediate ASes 
will drop our attribute.  

In practice, this can happen with the current communities attribute.  
For example, if an an intermediate router is configured with:
 set communities X:Y
it would remove our communities attributes and add X:Y.  

Also, does anyone have data on how widely existing communities 
attributes propogate in the internet?

Thanks
x.zhao

+-----------------------------------------------------------------+
|                      Xiaoliang Zhao                             |
|^ - ^ - ^ - ^ - ^ - ^ - ^ - ^ - ^ - ^ - ^ - ^ - ^ - ^ - ^ - ^ - ^|
|   Tel : (919)513-1894	       | Dept. of Computer Science        |
| Email : [email-masked] | Box 7550, NCSU Centennial Campus |
|   URL : www4.ncsu.edu/~xzhao | Raleigh, NC 27695                |
+-----------------------------------------------------------------+

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

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

To: [email-masked]
Cc: [email-masked]
Subject: revised Internet Draft
Date: Fri, 21 Sep 2001 06:42:12 -0700
From: Yakov Rekhter <[email-masked]>
Sender: [email-masked]

Folks,

As was agreed at the last IETF, here is the revised Internet Draft.
Unless there are any objections, I would like to issue the WG Last
Call on this document by Oct 5. With this in mind, I would greatly
appreciate review/comments before Oct 5th.

Yakov.
------- Forwarded Message

Date:    Fri, 21 Sep 2001 07:03:22 -0400
From:    [email-masked]
To:      IETF-Announce: ;
cc:      [email-masked] (subscribed members only)
Subject: I-D ACTION:draft-ietf-idr-bgp4-13.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-13.txt
	Pages		: 60
	Date		: 20-Sep-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-13.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-13.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-13.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-13.txt

- --OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-idr-bgp4-13.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

Date: Tue, 18 Sep 2001 18:06:57 +0200
From: Antal =?iso-8859-1?Q?Sasv=E1ri?= <[email-masked]>
To: [email-masked]
Subject: BGP 4 draft
Sender: [email-masked]

Hi!

I saw some parts of the BGP-4 draft posted on this list.
Could someone mail me the full draft, or tell me where can I download
it?
Thanks in advace!
    Anthony

Date: Mon, 17 Sep 2001 17:46:03 -0400
From: Jeffrey Haas <[email-masked]>
To: [email-masked]
Subject: Re: bgp4PathAttrBest MIB object
Sender: [email-masked]

I have no clue why this was done in the previous MIB.
The v2 MIB that is in progress uses the standard TruthValue textual
convention.

On Mon, Sep 17, 2001 at 09:52:07AM -0400, Chatterjee, Antu wrote:
> Hi,  
> 
> > I have a query regarding the bgp4PathAttrBest MIB object.
> > In RFC 1657 this has been defined to have two values false(1) and true(2).
> > 
> > Normally true is defined to have value 1 and false to have value 2.
> > 
> > Can anybody comment on this about the correct values for this MIB object.
> > 
> > -Antu
> 

-- 
Jeff Haas 
NextHop Technologies

From: "Chatterjee, Antu" <[email-masked]>
To: "[email-masked]'" <[email-masked]>
Subject: bgp4PathAttrBest MIB object
Date: Mon, 17 Sep 2001 09:52:07 -0400
Sender: [email-masked]

Hi,  

> I have a query regarding the bgp4PathAttrBest MIB object.
> In RFC 1657 this has been defined to have two values false(1) and true(2).
> 
> Normally true is defined to have value 1 and false to have value 2.
> 
> Can anybody comment on this about the correct values for this MIB object.
> 
> -Antu

From: Katia Linker <[email-masked]>
To: [email-masked], [email-masked], [email-masked]
Subject: Controlling routing traffic overhead
Date: Mon, 17 Sep 2001 11:46:14 +0200
Sender: [email-masked]

Hi, all!
I did read RFC 1771, but I still don't have complete understanding
of the meaning and use of the following two timers:
- MinRouteAdvertisement
- MinAsOrigination
Please, help me to understand what is the difference between these 
two timers, when are we using them.
Regards the first timer RFC 1771says that from the one hand this 
timer should be applied to some common set of destinations, but on
the other handit says, that it would be unwarranted overhead to keep
a separate timer for each common set of deestinations. So, what is 
the solution?
    Waiting for your reply.
        Thanks in advance.
              Katya

Date: Thu, 13 Sep 2001 19:30:58 +0200
From: Vincent Gillet <[email-masked]>
To: Jacques Caron <[email-masked]>
Cc: Alex Zinin <[email-masked]>, Jeffrey Haas <[email-masked]>, [email-masked]
Subject: Re: Suggested changes to bgp4 draft for maximum prefix error handling
Sender: [email-masked]

Bonjour Jacques,
Nice to see you still at Psi !

> I see two options which could be considered here:
> 1. Mark a peer that was previously shut down due to exceeding maximum 
> number of prefixes as "SUSPECT". Then, when the router next tries to bring 
> up the session, it will receive the prefixes, but not use or redistribute 
> them until it is reasonably sure everything's fine (e.g. arms a timer 
> everytime it receives a prefix that actually increases the number of 
> prefixes received from the peer -- a new prefix, not a replacement -- and 
> considers the peer OK when the timer expires).

If there is no route flap from this peer, it should work !

> When the peer is marked OK, then start considering all the prefixes 
> received from that peer as candidates for inclusion in the routing table 
> and redistribution.

This option is good, but we have to think about this timer and the rules
to consider the peer "safe".

> 2. Instead of shutting down the session when max-prefixes is exceeded, just 
> stop accepting any new prefixes (accept updates for existing prefixes, 
> including deletions that might make it accept new prefixes again), and 
> log/trap/yell/whatever. This has advantages and drawbacks, though.
> 
> Advantages include less disruption, especially if you have very strict 
> max-prefix settings (e.g. set very closely to the exact number of routes 
> you're supposed to get from the peer) and any changes are "soft" (i.e. the 
> peer starts advertising too many prefixes without resetting the session), 
> as chances are you'll keep the "right" prefixes, and discard the others.
> 
> On the other hand, it can be very dangerous, as it might some unwanted 
> routes to be accepted from a peer for long period of times (i.e. in all 
> other cases than the above).

Other 2 drawbacks :

. route leaker is not aware of the problem he is originating.
  BGP session down is easy to monitor. How to know that peer consider
  you as a "suspect" one and put your updates on-hold ?
  We need a feature to inform the peer that he is considered "suspect" one.

. Similar problem on the other side ... how to inform NMS that box is
  receiving suspsect route leaking and "freeze" updates from the peer.
  Folks are very used to see BGP "up or down".
  Freeze state would be very new state people are not used.
  Beside, i am not sure that "stop accepting any new prefixes" state is
  compliant to BGP4 vanilla specs !!

> I guess I prefer option 1 :-) Note however that this is purely an internal 
> implementation matter, which could be addressed as a suggested behaviour in 
> some RFC (it does affect global routing updates/flaps), it does not affect 
> interoperability (other than a notification mechanism within BGP so that 
> the router detecting the problem tells so to the offending router which 
> should then trap/log, rather than have someone in the "victim" noc need to 
> send e-mail or pick up a phone...).

Option 2 may be the smartest one, but i also prefer option 1 for the internal
matter !!

Option 1 may be time to start a draft. I will think about that !

Thanks for your inputs,

V

From: Katia Linker <[email-masked]>
To: [email-masked], [email-masked], [email-masked]
Subject:  Decision Process for external updates
Date: Thu, 13 Sep 2001 19:00:13 +0200
Sender: [email-masked]

> Hi !
> Though I read carefully all section 9.1 in RFC 1771 regrading Decision
> process, I couldn't find an answer to my following question:
> What is , in details, the decision process when an Update message arrives
> from another BGP peer in my AS ?
> Asides of the fact that this message most be sent to my other external BGP
> peers, the RFC doesn't specify which of the Phases 1-3 mentioned in
> sections 9.1.1 - 9.1.3 is relevant (correct if I'm wrong).
> 
> Regards,
> 
> Amnon Even Zohar
> Atidim Technological Park, Bldg.4
> Tel-Aviv 61131, Israel
> Tel: 972-3-645-8595
> Fax: 972-3-648-7368
> E-mail: [email-masked]
> 
> 

Date: Tue, 11 Sep 2001 18:22:51 -0700
From: Alex Zinin <[email-masked]>
Reply-To: Alex Zinin <[email-masked]>
Organization: Nexsi Systems
To: Vincent Gillet <[email-masked]>
Cc: Jeffrey Haas <[email-masked]>, [email-masked]
Subject: Re: Suggested changes to bgp4 draft for maximum prefix error handling
Sender: [email-masked]

Vincent,

>>   The way I see it is we might be interested in a) a non-disruptive
>>   notification mechanism, that would allow peers to exchange
>>   messages reflecting some local decisions/conditions (i.e.,
>>   something that would give one side a clue when/why the other side
>>   did something); and b) a mechanism that would allow a BGP session
>>   to be "parked" in a state until explicit user intervention.
>>   a) does not necessarily mean b), but some a) messages may lead
>>   to b) (like prefix limit).

> non-disruptive notification mechanism may be useful but cannot be part
> of BGP4 new draft.

Probably not.

> It may be part of a new capabilities.
> Route Refresh Capability is an exemple of "non-disruptive mechanism".

> Beside, what message could be notified ?
> Do you think we should have a list of "well known" notification (admin filter
> changed, out-of-memory, ...) and/or a free string peer may populate to
> reflect its own change ?

I'd say codes would be better than messages, so that we can
easily link this notification mechanism to the other (park state)
if necessary, without a string comparison.

> "States" are very related to BGP4 specs (Finite State Machine).
> It looks hard to include a new "parked state".

I guess the support for the new state would have to be negotiated.
Aside from that, the new state should be stub, i.e., the session
should only get out of it upon user intervention or a reset, so we
interfere with the standard FSM (if it stays in the BGP spec)
as less as possible.

>>   Defining the reason codes for cease is a good idea, but I believe
>>   that just allowing a session that exhausted the prefix limit to be
>>   ceased with a specific code may not be good enough, as it may lead to
>>   long periods of session flaps leading to route instabilities (if the

> Some vendors already do that.
> Juniper try to restart BGP again and again.
> It leads to routes flaps but i guess that after some flaps, routes are
> dampened by the box hence updates for this route are not propagated.

> As soon as BGP is stable, routes stop flaping hence are reused.

> Juniper implementation has some pros and cons.
> Good point is the ability to restart routes advertisement as soon as flaps
> are over.
> Bad point is flaps propagated outside during the firsts attemps.

Not trying to argue about a specific implementation, I personally
believe that, in general, there's no reason to automatically retry
a connection that was shut down because it requires some admin's
attention, without having an evidence that the user actually did that;
and when the admin pays attention to the problem, it shouldn't be
too much to restart the connection.

To me, the fact that consequences of something are softened
by route dampening, does make that something that causes session &
route flapping look like a good idea.

Alex.

Date: Tue, 11 Sep 2001 16:43:08 +0200
From: Vincent Gillet <[email-masked]>
To: Alex Zinin <[email-masked]>
Cc: Jeffrey Haas <[email-masked]>, [email-masked]
Subject: Re: Suggested changes to bgp4 draft for maximum prefix error handling
Sender: [email-masked]

[email-masked] disait :

> Jeffrey,
> 
>   I share your feeling here.
> 
>   The way I see it is we might be interested in a) a non-disruptive
>   notification mechanism, that would allow peers to exchange
>   messages reflecting some local decisions/conditions (i.e.,
>   something that would give one side a clue when/why the other side
>   did something); and b) a mechanism that would allow a BGP session
>   to be "parked" in a state until explicit user intervention.
>   a) does not necessarily mean b), but some a) messages may lead
>   to b) (like prefix limit).

non-disruptive notification mechanism may be useful but cannot be part
of BGP4 new draft. It may be part of a new capabilities.
Route Refresh Capability is an exemple of "non-disruptive mechanism".

Beside, what message could be notified ?
Do you think we should have a list of "well known" notification (admin filter
changed, out-of-memory, ...) and/or a free string peer may populate to
reflect its own change ?

"States" are very related to BGP4 specs (Finite State Machine).
It looks hard to include a new "parked state".

>   Defining the reason codes for cease is a good idea, but I believe
>   that just allowing a session that exhausted the prefix limit to be
>   ceased with a specific code may not be good enough, as it may lead to
>   long periods of session flaps leading to route instabilities (if the

Some vendors already do that.
Juniper try to restart BGP again and again.
It leads to routes flaps but i guess that after some flaps, routes are
dampened by the box hence updates for this route are not propagated.

As soon as BGP is stable, routes stop flaping hence are reused.

Juniper implementation has some pros and cons.
Good point is the ability to restart routes advertisement as soon as flaps
are over.
Bad point is flaps propagated outside during the firsts attemps.

V

Date: Tue, 11 Sep 2001 11:18:00 -0400
From: Jeffrey Haas <[email-masked]>
To: Katia Linker <[email-masked]>
Cc: [email-masked]
Subject: Re: Sending the whole Routing table
Sender: [email-masked]

In general, packing UPDATES is a good thing.  It reduces decoding
time of the packet.  However, it does increase the time in
building packets since all prefixes that have common outgoing
path attributes must be collected.

On Tue, Sep 11, 2001 at 01:39:11PM +0200, Katia Linker wrote:
> I have a question and I'll appreciate all of your suggestions.
> When BGP speakers transforms to the established state, 
> they are exchanging all of their routing tables.
> So, my question is when the whole routing table is sent at
> the beginning, should we try to collect routes with the same 
> attributes and send them in common UPDATE message or
> may be attributes doesn't have any difference at the beginning.
>          Katya
> 

-- 
Jeff Haas 
NextHop Technologies

From: Katia Linker <[email-masked]>
To: [email-masked], [email-masked], "[email-masked]'" <[email-masked]>
Subject: Sending the whole Routing table
Date: Tue, 11 Sep 2001 13:39:11 +0200
Sender: [email-masked]

Hi,
I have a question and I'll appreciate all of your suggestions.
When BGP speakers transforms to the established state, 
they are exchanging all of their routing tables.
So, my question is when the whole routing table is sent at
the beginning, should we try to collect routes with the same 
attributes and send them in common UPDATE message or
may be attributes doesn't have any difference at the beginning.
         Katya

Date: Mon, 10 Sep 2001 15:51:41 -0700
From: Alex Zinin <[email-masked]>
Reply-To: Alex Zinin <[email-masked]>
Organization: Nexsi Systems
To: Jeffrey Haas <[email-masked]>
Cc: [email-masked]
Subject: Re: Suggested changes to bgp4 draft for maximum prefix error handling
Sender: [email-masked]

Jeffrey,

  I share your feeling here.

  The way I see it is we might be interested in a) a non-disruptive
  notification mechanism, that would allow peers to exchange
  messages reflecting some local decisions/conditions (i.e.,
  something that would give one side a clue when/why the other side
  did something); and b) a mechanism that would allow a BGP session
  to be "parked" in a state until explicit user intervention.
  a) does not necessarily mean b), but some a) messages may lead
  to b) (like prefix limit).

  Defining the reason codes for cease is a good idea, but I believe
  that just allowing a session that exhausted the prefix limit to be
  ceased with a specific code may not be good enough, as it may lead to
  long periods of session flaps leading to route instabilities (if the
  implementation calculates best paths and propagates updates as it
  receives them during the initial update from the peer). We should either
  say that such a connection should not be retried until user intervention
  or explicitly go with b) above.

-- 
Alex Zinin

Friday, September 07, 2001, 3:23:28 PM, Jeffrey Haas wrote:

> On Fri, Sep 07, 2001 at 02:14:39PM -0700, Enke Chen wrote:
>> Also, some network operators might be hesitant to disclose the Pfx-limit
>> configured to their BGP peers. So this has to be optional.
>> 
>> If one insists on including the counters in the "data" field, then it
>> needs to be defined precisely, and the multiple address families
>> must be taken into account.

> As suggested on NANOG and (I think) briefly mentioned here, finding
> a "soft" way of failing in bad situations is something we should be
> considered.  For example, in the case of prefix limits, not clearing
> the peering session would be nice, but a true "notification" system
> needs to be implemented.  This would tell the peer "stop sending me
> updates, I'm ignoring everything else you're telling me".

> Perhaps even capability negotiated "soft" failure state.  For example,
> you tell your peer that you support soft failure on prefixes and
> that when this happens, you want them to discard this AFI/SAFI to
> make room for everything else.  For this example, dynamically
> changing the capabilities to remove an AFI/SAFI would suffice
> along with a route-refresh on retained AFI/SAFI's, or a graceful restart.

> For all of the vendors I can think of, its an excess of route
> instances that causes the issue - not a particular AFI/SAFI set.
> That may change with rfc2547 flooding multiple copies of the
> Internet's tables to your overlay peers. :-)

>> -- Enke

To: Vincent Gillet <[email-masked]>
Cc: [email-masked]
Subject: Re: Suggested changes to bgp4 draft for maximum prefix error handling 
Date: Fri, 07 Sep 2001 15:32:20 -0700
From: Enke Chen <[email-masked]>
Sender: [email-masked]

Hi, Vincent:

> Date: Sat, 8 Sep 2001 00:08:02 +0200
> From: Vincent Gillet <[email-masked]>
> To: Enke Chen <[email-masked]>
> Cc: [email-masked]
> Subject: Re: Suggested changes to bgp4 draft for maximum prefix error handling
> Message-ID: <[email-masked]>
> References: <[email-masked]> <[email-masked]> <[email-masked]>
> 

[snip]

> > 
> > It seems to me that the counters in the "data" field is something that
> > we can live without. When the "CEASE/PfxLimit" NOTIFICATION is received,
> > it should be pretty clear that administrative action needs to be taken.
> 
> Definitly. Peer may be interested to know if cease ceased because normal operation
> is near the limit or because he had large route leaking.
> 
> > Also, some network operators might be hesitant to disclose the Pfx-limit
> > configured to their BGP peers. So this has to be optional.
> 
> Non disclosure is a good argument. IDR community, how do operators feel about that ?
> 
> > If one insists on including the counters in the "data" field, then it
> > needs to be defined precisely, and the multiple address families
> > must be taken into account.
> 
> Do you think that BGP4 really need to define counters used ?
> Vendor may choose counter they want for threshold. This is not mandatory
> for BGP4 specs.

True. What I meant is that the format in the data field needs to be
defined precisely, something like: <afi, safi, count>, if this info
is optional included.

-- Enke

Date: Fri, 7 Sep 2001 18:23:28 -0400
From: Jeffrey Haas <[email-masked]>
To: [email-masked]
Subject: Re: Suggested changes to bgp4 draft for maximum prefix error handling
Sender: [email-masked]

On Fri, Sep 07, 2001 at 02:14:39PM -0700, Enke Chen wrote:
> Also, some network operators might be hesitant to disclose the Pfx-limit
> configured to their BGP peers. So this has to be optional.
> 
> If one insists on including the counters in the "data" field, then it
> needs to be defined precisely, and the multiple address families
> must be taken into account.

As suggested on NANOG and (I think) briefly mentioned here, finding
a "soft" way of failing in bad situations is something we should be
considered.  For example, in the case of prefix limits, not clearing
the peering session would be nice, but a true "notification" system
needs to be implemented.  This would tell the peer "stop sending me
updates, I'm ignoring everything else you're telling me".

Perhaps even capability negotiated "soft" failure state.  For example,
you tell your peer that you support soft failure on prefixes and
that when this happens, you want them to discard this AFI/SAFI to
make room for everything else.  For this example, dynamically
changing the capabilities to remove an AFI/SAFI would suffice
along with a route-refresh on retained AFI/SAFI's, or a graceful restart.

For all of the vendors I can think of, its an excess of route
instances that causes the issue - not a particular AFI/SAFI set.
That may change with rfc2547 flooding multiple copies of the
Internet's tables to your overlay peers. :-)

> -- Enke

-- 
Jeff Haas 
NextHop Technologies

Date: Sat, 8 Sep 2001 00:08:02 +0200
From: Vincent Gillet <[email-masked]>
To: Enke Chen <[email-masked]>
Cc: [email-masked]
Subject: Re: Suggested changes to bgp4 draft for maximum prefix error handling
Sender: [email-masked]

Hi Enke,

> > As Jeffrey stated, peer deletion is included in configuration changed.
> > Beside, it may be hard for implementation to distinguish between both cases.
> 
> The last one should be re-phrase as "Other Configuration Change" as
> suggested by Eric Gray privately.

OK.

> > About maximum prefixes, Jeffrey raised me a mistake.
> > Adj-Ribs-In is the table to monitor and not Loc-RIB.
> > 
> > Vendors used to monitor prefixes that are "Active candidates" only.
> > Prefixes administratively filtered are not included in the count to cease BGP but may be
> > in Adj-Ribs-In.
> > 
> > For that reason, i suggest to not refer to any Ribs and let vendors
> > decide counter they want to use. Also, they SHOULD put the counter in
> > "data" field of error code.
> 
> It seems to me that the counters in the "data" field is something that
> we can live without. When the "CEASE/PfxLimit" NOTIFICATION is received,
> it should be pretty clear that administrative action needs to be taken.

Definitly. Peer may be interested to know if cease ceased because normal operation
is near the limit or because he had large route leaking.

> Also, some network operators might be hesitant to disclose the Pfx-limit
> configured to their BGP peers. So this has to be optional.

Non disclosure is a good argument. IDR community, how do operators feel about that ?

> If one insists on including the counters in the "data" field, then it
> needs to be defined precisely, and the multiple address families
> must be taken into account.

Do you think that BGP4 really need to define counters used ?
Vendor may choose counter they want for threshold. This is not mandatory
for BGP4 specs.

V

To: Vincent Gillet <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: Suggested changes to bgp4 draft for maximum prefix error handling 
Date: Fri, 07 Sep 2001 14:14:39 -0700
From: Enke Chen <[email-masked]>
Sender: [email-masked]

> Date: Fri, 7 Sep 2001 22:45:30 +0200
> From: Vincent Gillet <[email-masked]>
> To: Enke Chen <[email-masked]>
> Cc: [email-masked]
> Subject: Re: Suggested changes to bgp4 draft for maximum prefix error handling
> Message-ID: <[email-masked]>
> References: <[email-masked]> <[email-masked]> <[email-masked]>
> 
> [email-masked] disait :
> 
> > Vincent:
> > I like your idea of defining some subcode for "CEASE". It will greatly help 
> > trouble shooting, and does not introduce any backward compatibility issue.
> 
> Right. Backward compatibility is key point.
> 
> [...]
> >         o Peer deletion
> >  
> >         o Configuration change
> 
> As Jeffrey stated, peer deletion is included in configuration changed.
> Beside, it may be hard for implementation to distinguish between both cases.

The last one should be re-phrase as "Other Configuration Change" as
suggested by Eric Gray privately.

> 
> About maximum prefixes, Jeffrey raised me a mistake.
> Adj-Ribs-In is the table to monitor and not Loc-RIB.
> 
> Vendors used to monitor prefixes that are "Active candidates" only.
> Prefixes administratively filtered are not included in the count to cease BGP but may be
> in Adj-Ribs-In.
> 
> For that reason, i suggest to not refer to any Ribs and let vendors
> decide counter they want to use. Also, they SHOULD put the counter in
> "data" field of error code.

It seems to me that the counters in the "data" field is something that
we can live without. When the "CEASE/PfxLimit" NOTIFICATION is received,
it should be pretty clear that administrative action needs to be taken.
Also, some network operators might be hesitant to disclose the Pfx-limit
configured to their BGP peers. So this has to be optional.

If one insists on including the counters in the "data" field, then it
needs to be defined precisely, and the multiple address families
must be taken into account.

-- Enke

Date: Fri, 7 Sep 2001 22:45:30 +0200
From: Vincent Gillet <[email-masked]>
To: Enke Chen <[email-masked]>
Cc: [email-masked]
Subject: Re: Suggested changes to bgp4 draft for maximum prefix error handling
Sender: [email-masked]

[email-masked] disait :

> Vincent:
> I like your idea of defining some subcode for "CEASE". It will greatly help 
> trouble shooting, and does not introduce any backward compatibility issue.

Right. Backward compatibility is key point.

[...]
>         o Peer deletion
>  
>         o Configuration change

As Jeffrey stated, peer deletion is included in configuration changed.
Beside, it may be hard for implementation to distinguish between both cases.

About maximum prefixes, Jeffrey raised me a mistake.
Adj-Ribs-In is the table to monitor and not Loc-RIB.

Vendors used to monitor prefixes that are "Active candidates" only.
Prefixes administratively filtered are not included in the count to cease BGP but may be
in Adj-Ribs-In.

For that reason, i suggest to not refer to any Ribs and let vendors
decide counter they want to use. Also, they SHOULD put the counter in
"data" field of error code.

V

Date: Thu, 6 Sep 2001 20:19:46 -0400
From: Jeffrey Haas <[email-masked]>
To: [email-masked]
Subject: Re: Breaking ties:RFC1771 different from cisco?
Sender: [email-masked]

On Thu, Sep 06, 2001 at 03:47:18PM -0700, Ben Black wrote:
> The use of AS_PATH length as a tie-breaking metric for BGP is not specified
> in RFC1771 (or any of the drafts).

The first appearance of path length for route selection that I'm
aware of is RFC1164, page 16:

: The simplest way to assign a degree of preference to a particular
: path is to use the number of ASs in the AS path as the degree of
: preference.  This approach reflects the heuristic that shorter paths
: are usually better than longer ones.

> identical tie-breaking processes, and vendors have added a large number of
> steps to their tie-breaking processes.  Operators love knobs.

Operators are also fond of rope. :-)

> Ben

-- 
Jeff Haas 
NextHop Technologies

Date: Thu, 6 Sep 2001 15:47:18 -0700
From: Ben Black <[email-masked]>
To: Dan Pei <[email-masked]>
Cc: [email-masked]
Subject: Re: Breaking ties:RFC1771 different from cisco?
Sender: [email-masked]

On Thu, Sep 06, 2001 at 02:14:54PM -0700, Dan Pei wrote:
> 
> Another question is:
>         Where is the rule to prefer shortest AS path(at some point) in
> RFC1771? There is such a rule in both cisco's website and the book,
> but I can not find it in RFC1771?
>         (Is it because this rule is skippable by configuration in cisco
>         according to http://www.cisco.com/warp/public/459/25.shtml?)
> 

The use of AS_PATH length as a tie-breaking metric for BGP is not specified
in RFC1771 (or any of the drafts).  BGP speakers are not required to have
identical tie-breaking processes, and vendors have added a large number of
steps to their tie-breaking processes.  Operators love knobs.

Ben

Date: Thu, 06 Sep 2001 18:56:45 -0400
From: Eric Gray <[email-masked]>
To: Susan Harris <[email-masked]>
Cc: Dashin Lee <[email-masked]>, [email-masked]
Subject: Re: Where can I find IDR mail archives before June 2001?
Sender: [email-masked]

Susan,

    You can also find some dating from 1996 through 1998 at

        ftp://ftp.ietf.org/ietf-mail-archive/idr

All the files located there starting with September, 1998 are empty.

--
Eric Gray

You wrote:

> > I found only 4 mail archives under ftp://ftp.merit.edu/mail.archives/idr,
> > which started from June 2001. Where can I find the previous ones?
>
> Sorry, but the June 2001 messages are the earliest we have.
>
>         --Susan Harris

Date: Thu, 6 Sep 2001 18:47:06 -0400 (EDT)
From: Susan Harris <[email-masked]>
To: Dashin Lee <[email-masked]>
Cc: [email-masked]
Subject: Re: Where can I find IDR mail archives before June 2001?
Sender: [email-masked]

> I found only 4 mail archives under ftp://ftp.merit.edu/mail.archives/idr,
> which started from June 2001. Where can I find the previous ones?

Sorry, but the June 2001 messages are the earliest we have.

	--Susan Harris

To: Jeffrey Haas <[email-masked]>
Cc: [email-masked]
Subject: Re: Suggested changes to bgp4 draft for maximum prefix error handling 
Date: Thu, 06 Sep 2001 14:59:52 -0700
From: Enke Chen <[email-masked]>
Sender: [email-masked]

> Date: Thu, 6 Sep 2001 17:55:01 -0400
> From: Jeffrey Haas <[email-masked]>
> To: [email-masked]
> Subject: Re: Suggested changes to bgp4 draft for maximum prefix error handling
> Message-ID: <[email-masked]>
> References: <[email-masked]> <[email-masked]>
> Mime-Version: 1.0
> Content-Type: text/plain; charset=us-ascii
> Content-Disposition: inline
> User-Agent: Mutt/1.2.5i
> In-Reply-To: <[email-masked]>; from [email-masked] on Thu, Sep 06, 2001 at 02:00:52PM -0700
> Sender: [email-masked]
> Precedence: bulk
> 
> On Thu, Sep 06, 2001 at 02:00:52PM -0700, Enke Chen wrote:
> > In addition to the "Prefix limit exceed" subcode you are propsing, I would
> > like to suggest a few more subcodes:
> >  
> 
> [...]
> 
> >         o Peer deletion
> >  
> >         o Configuration change
> 
> How are these two distinguished?

To clarify:

            o Peer deletion

            o Configuration change (other than peer deletion)

-- Enke

Date: Thu, 6 Sep 2001 17:55:01 -0400
From: Jeffrey Haas <[email-masked]>
To: [email-masked]
Subject: Re: Suggested changes to bgp4 draft for maximum prefix error handling
Sender: [email-masked]

On Thu, Sep 06, 2001 at 02:00:52PM -0700, Enke Chen wrote:
> In addition to the "Prefix limit exceed" subcode you are propsing, I would
> like to suggest a few more subcodes:
>  

[...]

>         o Peer deletion
>  
>         o Configuration change

How are these two distinguished?

> -- Enke

-- 
Jeff Haas 
NextHop Technologies

Date: Thu, 6 Sep 2001 14:14:54 -0700 (PDT)
From: Dan Pei <[email-masked]>
To: <[email-masked]>
Subject: Breaking ties:RFC1771 different from cisco?
Sender: [email-masked]

Hi,

 In:
         - http://www.cisco.com/warp/public/459/25.shtml   and
         - Internet Routing Architectures(Halabi)
the order to break ties when comparing paths is:
        ...
        -prefer eBGP paths over iBGP paths
        -prefer lowest IGP metric to the BGP next hop.
        ...

But RFC1771 and <draft-ietf-idr-bgp4-12.txt> 9.1.2.1, the order is:
        ...
        -prefer lowest internal cost to BGP nexthop;
        -prefer eBGP paths over iBGP paths.
        ..

Does these mean difference or it doesn't matter for some reason?

Another question is:
        Where is the rule to prefer shortest AS path(at some point) in
RFC1771? There is such a rule in both cisco's website and the book,
but I can not find it in RFC1771?
        (Is it because this rule is skippable by configuration in cisco
        according to http://www.cisco.com/warp/public/459/25.shtml?)

Thanks!

----
Dan

To: Vincent Gillet <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: Suggested changes to bgp4 draft for maximum prefix error handling 
Date: Thu, 06 Sep 2001 14:00:52 -0700
From: Enke Chen <[email-masked]>
Sender: [email-masked]

Vincent:
I like your idea of defining some subcode for "CEASE". It will greatly help 
trouble shooting, and does not introduce any backward compatibility issue.

In addition to the "Prefix limit exceed" subcode you are propsing, I would
like to suggest a few more subcodes:
 
        o Admin shutdown
 
        o Admin reset
 
        o Peer deletion
 
        o Configuration change

-- Enke

> Date: Wed, 5 Sep 2001 13:49:23 +0200
> From: Vincent Gillet <[email-masked]>
> To: [email-masked]
> Subject: Suggested changes to bgp4 draft for maximum prefix error handling
> Message-ID: <[email-masked]>
> 
> Hi,
> 
> I would like to bring up an operationnal issue that we may add to next bgp4
> draft (-12 expired ?!).
> 
> Many Carriers use "maximum prefix limit" feature implemented by the biggest
> vendors. This is a software protection mechanism against route leaking .
> 
> Vendors implement this feature in similar way (Juniper and Cisco are the only
> ones I know) :
> 
> . Count prefixes in Loc-RIB.
> . Cease BGP session when counters reach configured threshold.
> . Raise a warning flag (mostly available via CLI or SYSLOG) when counter
>   is over x percent.
> 
> In case of "Maximul prefixes exceeded", BGP session is closed without any
> specific
> Error Code.
> 
> Some vendors (Juniper) restart BGP after a configured idle timing.
> Other vendors (Cisco) freeze the BGP session until a manual restart.
> 
> I do not want to talk about implementation differences nor route leaking
> protection !!
> 
> My concern is to find a way we can inform both parties that BGP session has
> ceased
> because of this feature.
> 
> I propose to decicate "Cease" Subcode for this purpose and use Data field
> to report reached value.
> 
> This feature would be very useful for Operations people of the originating route
> leaking network
> as this enables them to know exactly the reason why BGP is Off.
> 
> Below is the diff :
> 
> *** draft-ietf-idr-bgp4-12.txt.orig     Sun Sep  2 13:09:16 2001
> --- draft-ietf-idr-bgp4-12.txt  Sun Sep  2 13:22:12 2001
> ***************
> *** 1106,1111 ****
> --- 1106,1115 ----
>                                 10 - Invalid Network Field.
>                                 11 - Malformed AS_PATH.
> 
> +          Cease subcodes:
> +
> +                                1  - Maximum prefixes reached in Loc-RIB.
> +
>         Data:
> 
>            This variable-length field is used to diagnose the reason for
> ***************
> *** 1716,1721 ****
> --- 1720,1734 ----
>      by sending the NOTIFICATION message with Error Code Cease.  However,
>      the Cease NOTIFICATION message must not be used when a fatal error
>      indicated by this section does exist.
> +
> +    If BGP speaker decides to cease connection because of too many entries in
> +    the Loc-RIB Table, then the Error Subcode must be set to Maximum prefixes
> +    reached in Loc-RIB. The Data field should contain the number of
> +    Loc-RIB entries when this error occurs.
> +    This subcode neither implies nor requires that an implementation must
> +    have feature to cease BGP connection based on prefixes counter in Loc-RIB.
> +    If implementation has this feature, this subcode must be used.
> +
> 
> 
>   6.8 Connection collision detection.
> 
> 
> ============================
> 
> Some related issues may also be considered/included in this draft :
> 
> . Can we include other subcode for "Cease" (out of memory, manual cancel, ....)
> 
> and outside draft-ietf-idr-bgp4-12.txt :
> 
> . New capability to inform each BGP speaker about maximum prefix
>   configured on each side. It could be the starting point for a new draft.
> 
> Thoughts from IDR community welcome.
> 
> V

From: "Dashin Lee" <[email-masked]>
To: [email-masked]
Subject: Where can I find IDR mail archives before June 2001?
Date: Thu, 06 Sep 2001 11:01:03 +0800
Sender: [email-masked]

Hi, all,

I found only 4 mail archives under ftp://ftp.merit.edu/mail.archives/idr,
which started from June 2001. Where can I find the previous ones?

Thank you.

Lee Dashin

_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp

Date: Wed, 05 Sep 2001 17:15:29 +0200
From: Antal =?iso-8859-1?Q?Sasv=E1ri?= <[email-masked]>
To: [email-masked]
Subject: multiple prefixes in NLRI
Sender: [email-masked]

Hi!

As in 9.1.4, RFC 1711 is written:
>Since BGP encodes NLRI using IP prefixes, overlap
>will always exhibit subset relationships.

Does this mean, that if I have an update message with multiple prefixes
in the NLRI, I should treat it (logically) as multiple update messages
with the same attributes, each NLRI containing only 1 prefix?
Generally, when the RFC says "a route" , and "set of destinations", then

should I mean only one of the prefixes in the NLRI?

For example in 9.1.2:
>   For each set of destinations for which a feasible route exists in
the
             ^^^^^^^^^^^^^^^^^^^
                               |does this mean only 1 prefix, or the
whole NLRI (multiple prefixes)

>   Adj-RIBs-In, the local BGP speaker shall identify the route that
has:
>
>      a) the highest degree of preference of any route to the same set
                                                                    ^^^
>      of destinations, or
       ^^^^^^^^^^^^^^^
>
>      b) is the only route to that destination, or
                                    ^^^^^^^^^^^
>
>      c) is selected as a result of the Phase 2 tie breaking rules
>      specified in 9.1.2.1.

Thanks:
    Anthony

Date: Wed, 5 Sep 2001 16:14:08 +0200
From: Vincent Gillet <[email-masked]>
To: Jeffrey Haas <[email-masked]>
Cc: [email-masked]
Subject: Re: Suggested changes to bgp4 draft for maximum prefix error handling
Sender: [email-masked]

[email-masked] disait :

> On Wed, Sep 05, 2001 at 01:49:23PM +0200, Vincent Gillet wrote:
> > Many Carriers use "maximum prefix limit" feature implemented by the biggest
> > vendors. This is a software protection mechanism against route leaking .
> 
> [...]
> 
> > . Count prefixes in Loc-RIB.
> 
> Throughout your document, I think you really mean Adj-Ribs-In, correct?

Oops, Yes.

I had in mind that Adj-Rib-In contains received routes BEFORE adminitrative filter,
and Loc-RIB contains routes AFTER filters and available for decision process.
I was wrong.
Adj-Rib-In contains routes AFTER adminitrative filter and BEFORE Route Selection.

Adj-Ribs-In counter is the one we are interested in.

> > . Raise a warning flag (mostly available via CLI or SYSLOG) when counter
> >   is over x percent.
> 
> I would note for the general IDR community that having this in the
> base BGP spec makes it pretty simple for us to include this also in
> the BGP MIB (v2).  This lets us provide traps.
> 
> This makes operators happy. :-)

That was my very first concern !

> > . New capability to inform each BGP speaker about maximum prefix
> >   configured on each side. It could be the starting point for a new draft.
> 
> Dynamic capability updates would be handy for this.

Indeed. Threshold can change at anytime during session.

V

Date: Wed, 5 Sep 2001 09:35:58 -0400
From: Jeffrey Haas <[email-masked]>
To: [email-masked]
Subject: Re: Suggested changes to bgp4 draft for maximum prefix error handling
Sender: [email-masked]

On Wed, Sep 05, 2001 at 01:49:23PM +0200, Vincent Gillet wrote:
> Many Carriers use "maximum prefix limit" feature implemented by the biggest
> vendors. This is a software protection mechanism against route leaking .

[...]

> . Count prefixes in Loc-RIB.

Throughout your document, I think you really mean Adj-Ribs-In, correct?

> . Raise a warning flag (mostly available via CLI or SYSLOG) when counter
>   is over x percent.

I would note for the general IDR community that having this in the
base BGP spec makes it pretty simple for us to include this also in
the BGP MIB (v2).  This lets us provide traps.

This makes operators happy. :-)

> . New capability to inform each BGP speaker about maximum prefix
>   configured on each side. It could be the starting point for a new draft.

Dynamic capability updates would be handy for this.

> V

-- 
Jeff Haas 
NextHop Technologies

Date: Wed, 5 Sep 2001 13:49:23 +0200
From: Vincent Gillet <[email-masked]>
To: [email-masked]
Subject: Suggested changes to bgp4 draft for maximum prefix error handling
Sender: [email-masked]

Hi,

I would like to bring up an operationnal issue that we may add to next bgp4
draft (-12 expired ?!).

Many Carriers use "maximum prefix limit" feature implemented by the biggest
vendors. This is a software protection mechanism against route leaking .

Vendors implement this feature in similar way (Juniper and Cisco are the only
ones I know) :

. Count prefixes in Loc-RIB.
. Cease BGP session when counters reach configured threshold.
. Raise a warning flag (mostly available via CLI or SYSLOG) when counter
  is over x percent.

In case of "Maximul prefixes exceeded", BGP session is closed without any
specific
Error Code.

Some vendors (Juniper) restart BGP after a configured idle timing.
Other vendors (Cisco) freeze the BGP session until a manual restart.

I do not want to talk about implementation differences nor route leaking
protection !!

My concern is to find a way we can inform both parties that BGP session has
ceased
because of this feature.

I propose to decicate "Cease" Subcode for this purpose and use Data field
to report reached value.

This feature would be very useful for Operations people of the originating route
leaking network
as this enables them to know exactly the reason why BGP is Off.

Below is the diff :

*** draft-ietf-idr-bgp4-12.txt.orig     Sun Sep  2 13:09:16 2001
--- draft-ietf-idr-bgp4-12.txt  Sun Sep  2 13:22:12 2001
***************
*** 1106,1111 ****
--- 1106,1115 ----
                                10 - Invalid Network Field.
                                11 - Malformed AS_PATH.

+          Cease subcodes:
+
+                                1  - Maximum prefixes reached in Loc-RIB.
+
        Data:

           This variable-length field is used to diagnose the reason for
***************
*** 1716,1721 ****
--- 1720,1734 ----
     by sending the NOTIFICATION message with Error Code Cease.  However,
     the Cease NOTIFICATION message must not be used when a fatal error
     indicated by this section does exist.
+
+    If BGP speaker decides to cease connection because of too many entries in
+    the Loc-RIB Table, then the Error Subcode must be set to Maximum prefixes
+    reached in Loc-RIB. The Data field should contain the number of
+    Loc-RIB entries when this error occurs.
+    This subcode neither implies nor requires that an implementation must
+    have feature to cease BGP connection based on prefixes counter in Loc-RIB.
+    If implementation has this feature, this subcode must be used.
+

  6.8 Connection collision detection.

============================

Some related issues may also be considered/included in this draft :

. Can we include other subcode for "Cease" (out of memory, manual cancel, ....)

and outside draft-ietf-idr-bgp4-12.txt :

. New capability to inform each BGP speaker about maximum prefix
  configured on each side. It could be the starting point for a new draft.

Thoughts from IDR community welcome.

V

From: "Mareline Sheldon" <[email-masked]>
To: <[email-masked]>
Subject: BGP Marker Field
Date: Tue, 4 Sep 2001 14:54:58 +0530
Sender: [email-masked]

Hi,
There is a marker in the BGP Message header which is a 16 octet field which
is either used for authentication or to detect loss of syncronization
between the pair of BGP peers. My question is that why do we need this field
for authentication because we generally use md5 for authenticating BGP
peers. I dont know if anybody ever uses this marker for authentication
purposes. Secondly how can it help in synchronizing .. dont the layers down
below already take care of it. If such is the case then these 16 bytes are
nothing but an overhead and why is nothing done to do away with it.

What purpose are these bytes serving us.

Regards,
Mary
---
The grass is high,
The fields are ripe,
It's the springtime of my life.

_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com

From: Katia Linker <[email-masked]>
To: "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject: Degree of preference
Date: Tue, 4 Sep 2001 10:24:47 +0200 
Sender: [email-masked]

Hi,
My answer is regards route selection process again.
In RFC 1771 section 9.1.1 there is a term named
"degree of preference". I understood that it is a local
matter, but still can you give me any suggestions
how to calculate degree of preference, local preference
and multi-exit descriminator.
      Thanks in advance
          Katya

From: Katia Linker <[email-masked]>
To: "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>, "[email-masked]'" <[email-masked]>
Subject:  Route selection process
Date: Mon, 3 Sep 2001 10:56:43 +0200 
Sender: [email-masked]

Hi,
Regards my previous question:

> which route is preferable the more
> specific or the less specific?

>From the emails I got, the answer is 
more specific. But if we're doing an 
aggregation what is it done for if we're
selection the more specific route ?

And also in RFC 1771 section 9 in v)
I understood that we're selecting a less
specific...

From: Katia Linker <[email-masked]>
To: [email-masked], [email-masked], [email-masked]
Subject:  Route selection process
Date: Mon, 3 Sep 2001 10:54:11 +0200 
Sender: [email-masked]

Hi,
Regards my previous question:

> which route is preferable the more
> specific or the less specific?

>From the emails I got, the answer is 
more specific. But if we're doing an 
aggregation what is it done for if we're
selection the more specific route ?

Date: Mon, 03 Sep 2001 00:52:29 -0700
From: Kunihiro Ishiguro <[email-masked]>
To: Katia Linker <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked]
Subject: Re: [zebra 10316] Route selection process
Sender: [email-masked]

>Regards route selection process:
>which route is preferable the more
>specific or the less specific?

Most comprehensive information is on Cisco's web site.

http://www.cisco.com/warp/public/459/25.shtml

Actually, this is the today's industry standard BGP path selection
mechanism.
-- 
Kunihiro Ishiguro

From: Katia Linker <[email-masked]>
To: [email-masked], [email-masked], [email-masked]
Subject: Route selection process
Date: Mon, 3 Sep 2001 10:41:12 +0200 
Sender: [email-masked]

Hi,
Regards route selection process:
which route is preferable the more
specific or the less specific?
    Katya

Date: Sun, 2 Sep 2001 08:31:25 -0400 (EDT)
From: Jennifer Rexford <[email-masked]>
To: [email-masked]
Cc: [email-masked], [email-masked], [email-masked]
Subject: Re: Breaking Ties - Internal Updates Process
Sender: [email-masked]

> So, what route selection process is the right one ?

See also 

  - http://www.cisco.com/warp/public/459/25.shtml

  - http://arachne3.juniper.net/techpubs/software/junos42/swconfig-routing42/html/protocols-overview4.html#1045417

  - http://www.foundrynet.com/services/documentation/SRguide/FoundryManual_BGP4.html

for the route selection process for Cisco, Juniper, and Foundry.  They
seem to follow the same de facto standard, which is also described in
the Halabi book on "Internet Routing Architectures"...

-- Jen

From: Katia Linker <[email-masked]>
To: [email-masked], [email-masked], "[email-masked]'" <[email-masked]>
Subject: Breaking Ties - Internal Updates Process
Date: Sun, 2 Sep 2001 10:08:04 +0200 
Sender: [email-masked]

Hello, all !
My question is regards breaking ties in case that Adj-RIBs-In 
contains several equally preferable routes to the same destination.
In RFC 1771 section 9.2.1.1 there are 3 rules for the selection
however in the book “BGP4 Inter-Domain Routing in the Internet” by
 John W. Stewart section 2.6, pp.57-58 there are 6 steps in the BGP route 
selection process. 
So, what route selection process is the right one ?
Which one of them should I use ?
    Thanks in advance.
          Katya