Subject: [Idr] comments on idr-bgp4-20

From: Pekka Savola <[email-masked]>
Date: Wed, 24 Sep 2003 10:50:26 +0300 (EEST)

Hi,

[note, I'm not subscribed to the idr list]

Alex solicited ops-dir for folks to review bgp4-20 spec.  After almost
half a year, I finally found the time to look at it.  Comments below.  I
tried to look at the issues list draft-ietf-idr-bgp-issues-01.txt, but at
least on the quick glance, I didn't find major overlaps.

Overview:
 - the spec is in pretty good shape, but I'm not sure if all the features
listed are really full standard material.. it might be better to separate
some of them (e.g. anything relating to aggregation) to a separate doc (so
that we'd have a much tigher and better real base spec), and recycle it at
DS, but that might be much more effort.. not sure if something like that
would be worth it.

General thoughts on going to full standard:
 - If we want to go for full standard, I have to question the usefulness of
several BGP features:
  - AS_SET AS_PATH attribute
  - whole route aggregation concept (nowadays, it seems to be causing 
more trouble than it's worth -- instead of proper advertisements, just 
automatically aggregate instead of fixing the advertisements to begin 
with).  Maybe pver 10 years ago it may have been relevant if all the edge 
BGP routers might not support BGP-4 or CIDR..
  - about N++ different cases of third-party nexthop usage.

As a general observation from the text:
 - I skipped section 8 on FSM, as it was really boring, and I'm not sure
whehter it's of any use keeping it in the base spec.
 - I got major headache when trying to read the aggregating rules
especially in section 9.2.2.2 (and that was supposed to be the _simple_
rules :-(!!!) and ended up skipping them.

substantial
-----------

1) Section 3 on Summary of the Operations, states:

   In the context of this document we assume that a BGP speaker adver-
   tises to its peers only those routes that it itself uses (in this
   context a BGP speaker is said to "use" a BGP route if it is the most
   preferred BGP route and is used in forwarding). All other cases are
   outside the scope of this document.

this "usability" requirement is in conflict with section 4.3 on UPDATE
message format:

   An UPDATE message is used to advertise feasible routes sharing common
   path attributes to a peer, [...]

==> in particular note that "feasible" is a superset of "only those routes
the router itself uses" (compare to "those routes the router itself _could_
use if they were the most preferred ones"), right?

==> also note that the former definition is (IMHO) operationally unsound.  
It prevents you from advertising P-t-P addresses and loopbacks (which also 
reside in IGP) using BGP, because the IGP distance is lower than BGP and 
"BGP route is never used in forwarding". (depending on how you interpret 
that).  IMHO, this really needs to be changed to be OK.

2) The OPEN message format is confusing.  Why on earth do you have those
empty bits there?  Are they null-padding or just a typographical convention
for the clarity of the diagram (the latter)?
                                                                                                     
       0                   1                   2                   3
       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
       +-+-+-+-+-+-+-+-+
       |    Version    |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |     My Autonomous System      |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |           Hold Time           |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                         BGP Identifier                        |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       | Opt Parm Len  |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       |                                                               |
       |             Optional Parameters (variable)                    |
       |                                                               |
       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

==> I strongly recommend to either:
 1) go back to standard format, or
 2) rephrase the message format similar with UPDATE messages, i.e., drop all
the pretense about field lengths, bits 0-31, etc.

3) there is significant confusion on what "locally originated" means.  It is
not clear whether this refers to "local to the BGP speaker (i.e., the same
system)" or "local to the routing domain (i.e., the same AS)".  This must be
clarified in the text below, and the text should be reviewed.

5.1.3 NEXT_HOP
                                                                                                     
   The NEXT_HOP is a well-known mandatory attribute that defines the IP
   address of the router that SHOULD be used as the next hop to the des-
   tinations listed in the UPDATE message. The NEXT_HOP attribute is
   calculated as follows.
                                                                                                     
      1) When sending a message to an internal peer, if the route is not
      locally originated the BGP speaker SHOULD NOT modify the NEXT_HOP
      attribute, unless it has been explicitly configured to announce
      its own IP address as the NEXT_HOP. When announcing a locally
      originated route to an internal peer, the BGP speaker SHOULD use
      as the NEXT_HOP the interface address of the router through which
      the announced network is reachable for the speaker; if the route
      is directly connected to the speaker, or the interface address of
      the router through which the announced network is reachable for
      the speaker is the internal peer's address, then the BGP speaker
      SHOULD use for the NEXT_HOP attribute its own IP address (the
      address of the interface that is used to reach the peer).

4) there appears to have been added some bogosities about inter-AS traffic
engineering in section 9.3:

      - If the local AS appears in the AS path of the new route being
      considered, then that new route can not be viewed as better than
      any other route (provided that the speaker is configured to accept
      such routes). If such a route were ever used, a routing loop could
      result.

and:

     The ability of a BGP speaker to include more than one instance of
      its own AS in the AS_PATH attribute for the purpose of inter-AS
      traffic engineering.

==> what do these have to do with base spec?  I don't think they're
operationally feasible or used.  Remove any indication that it's OK to
receive your own AS in the routes you receive!!

5) the reasoning for this section is not clear.  It seems to be two parts
(the second one starting at "These routes...").  It seems partially, at
least for the second part, a set of operational guidelines.. which probably
don't have anything to do with the BGP spec!

9.4 Originating BGP routes
                                                                                                  
   A BGP speaker may originate BGP routes by injecting routing informa-
   tion acquired by some other means (e.g. via an IGP) into BGP. A BGP
   speaker that originates BGP routes assigns the degree of preference
   to these routes by passing them through the Decision Process (see
   Section 9.1). These routes MAY also be distributed to other BGP
   speakers within the local AS as part of the update process (see Sec-
   tion 9.2). The decision whether to distribute non-BGP acquired routes
   within an AS via BGP or not depends on the environment within the AS
   (e.g. type of IGP) and SHOULD be controlled via configuration.

6) references; note that as the Security Consideration section is a bit
short, the vulnerability analysis should be a *NORMATIVE* reference. 
However, one must ask here and with RFC2385 as well whether normative
references are OK from Full Standard to a lower maturity level.  Unless
this has already been investigated, it may be worth checking with the ADs
that this is OK.

   BGP vulnerabilities analysis is discussed in [XXX].
                                                                                                
Normative References
                                                                                                
   [RFC2385] Heffernan, A., "Protection of BGP Sessions via the TCP MD5
   Signature Option", RFC2385, August 1998.
                                                                                                
Non-normative References
                                                                                                
   [XXX] Murphy, S., "BGP Security Vulnerabilities Analysis", draft-
   ietf-idr-bgp-vuln-00.txt, work in progress

semi-substantial
----------------

==> I'd add "Decision Process", "Routing Table", and "BGP route" in the
terminology. (Especially the last one is a bit shady, see more comments
later.)

   Adj-RIB-In
   Adj-RIBs-In
   Adj-RIB-Out
   Adj-RIBs-Out

 ==> in some places, one seems to use "Adj-RIBs-{In,Out}", in some others,
"Adj-RIB-{In,Out}".  The plural/singular form should be consistent.

   BGP speaker
      A router that implements BGP.

==> uhh, no.  Throughout the text "BGP speaker" is used to refer to
BGP-*enabled* routers.  Implementation is a required but not sufficient
condition to that.  Consider rewording to something like:

   BGP speaker
      A router that implements and has been configured to use BGP.

....

      BGP Identifier:
                                                                                                     
         This 4-octet unsigned integer indicates the BGP Identifier of
         the sender. A given BGP speaker sets the value of its BGP Iden-
         tifier to an IP address assigned to that BGP speaker.  The
         value of the BGP Identifier is determined on startup and is the
         same for every local interface and every BGP peer.

==> the last sentence is confusing "same for every local interface".. yeah,
right, but interfaces are irrelevant here.  Also, this ignores the fact
that it's perfectly legal to change BGP identifiers after startup but prior
to establishing a BGP session.  Consider rewording to something
like:

         This 4-octet unsigned integer indicates the BGP Identifier of
         the sender. A given BGP speaker sets the value of its BGP Iden-
         tifier to an IP address assigned to that BGP speaker.  The
         value of the BGP Identifier is determined prior to establishing
         BGP sessions and is the same for every session the BGP speaker.

...

      Path Attributes:
                                                                                                     
         A variable length sequence of path attributes is present in
         every UPDATE message, except for an UPDATE message that carries
         only the withdrawn routes. Each path attribute is a triple
         <attribute type, attribute length, attribute value> of variable
         length.

==> should a simple diagram be added here, just like in section 4.2?

         The high-order bit (bit 0) of the Attribute Flags octet is the
         Optional bit. It defines whether the attribute is optional (if
         set to 1) or well-known (if set to 0).

==> this and the following descriptions on attributes are out of place if
you have not described the remaining categories (because they're used when
describing the attributes in the next page), that is, discretionary and
mandatory.  Consider rewording the above to something like:
	
         The high-order bit (bit 0) of the Attribute Flags octet is the
         Optional bit. It defines whether the attribute is optional (if
         set to 1) or well-known (if set to 0).  Well-known attributes can
         be either mandatory (MUST be included in every UPDATE message that
         contains NLRI), or discretionary (inclusion not required).

...

   All well-known attributes MUST be passed along (after proper updat-
   ing, if necessary) to other BGP peers.

==> LOCAL-PREF is an exception here.  I also note that the BGP's definition
of "transitive" is different ("unrecognized optional attributes are only
passed onward when the transitive bit is set, but recognized optional
attributes are always passed onward") from the apparent language ("always passed
along"), and might use a bit of clarification.

...

      b) When a given BGP speaker advertises the route to an external
      peer, then the advertising speaker updates the AS_PATH attribute
      as follows:
                                                                                                     
         1) if the first path segment of the AS_PATH is of type
         AS_SEQUENCE, the local system prepends its own AS number as the
         last element of the sequence (put it in the leftmost position).
         If the act of prepending will cause an overflow in the AS_PATH
         segment, i.e. more than 255 ASs, it is legal to prepend a new
         segment of type AS_SEQUENCE and prepend its own AS number to
         this new segment.
                                                                                                     
         2) if the first path segment of the AS_PATH is of type AS_SET,
         the local system prepends a new path segment of type
         AS_SEQUENCE to the AS_PATH, including its own AS number in that
         segment.
                                                                                                     
==> the text here seems confusing because it is not clear whether things are
added at the beginning or at the end of the segments, for example:

"the _last_ element sequence (put it in the _leftmost_ position)"

.. I think this requires more precise language on which end of the segment
these values are really inserted.  I.e., is it "physically" (in memory)
left-to-right (from more recent to more distant), or just interpreted that
way?  This has significant impact on the last sentence of section 1) in case
of overflows and the like.
 
   Whenever the modification of the AS_PATH attribute calls for includ-
   ing or prepending the AS number of the local system, the local system
   MAY include/prepend more than one instance of its own AS number in
   the AS_PATH attribute. This is controlled via local configuration.

==> what about prepending/adding someone else's AS?  Is this relevant enough
to be considered?

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

==> the second line seems out-of-place here.  I assume it means that the
router must not perform automatic de-aggregation, not that the router must
not have more specific routes to advertise.  In any case, a rewording might
be in order, e.g. like:

   A BGP speaker that receives a route with the ATOMIC_AGGREGATE
   attribute MUST NOT de-aggregate routes (as defined in 9.1.4); that is, 
   generating more specifics by de-aggregating a route is forbidden.

(note that this actually makes the statement stronger, and more in line of
9.1.4, that you should not do it even locally.)

   If the Length field of the message header is less than 19 or greater
   than 4096, or if the Length field of an OPEN message is less than the
   minimum length of the OPEN message, or if the Length field of an
   UPDATE message is less than the minimum length of the UPDATE message,
   or if the Length field of a KEEPALIVE message is not equal to 19, or
   if the Length field of a NOTIFICATION message is less than the mini-
   mum length of the NOTIFICATION message, then the Error Subcode is set
   to Bad Message Length. The Data field contains the erroneous Length
   field.

==> convert this to a bulleted list or something, so it's easier to read,
please! :-)

   The IP address in the NEXT_HOP MUST meet the following criteria to be
   considered semantically correct:
                                                                                                  
      a) It MUST NOT be the IP address of the receiving speaker
                                                                                                  
      b) In the case of an EBGP where the sender and receiver are one IP
      hop away from each other, either the IP address in the NEXT_HOP
      MUST be the sender's IP address (that is used to establish the BGP
      connection), or the interface associated with the NEXT_HOP IP
      address MUST share a common subnet with the receiving BGP speaker.

==> what's exactly the case for the first case of b)?  Couldn't thid be
cleaned a bit (it seems to me that the second case is a superset of the
first)?  In addition, I'd recommend rewording "one IP hop away" --
that begs the question whether you mean "direct neighbors" or "just one
transit router".  When thinking of it more, the former seems apparent, but a
different wording might flesh this out better.

   If a BGP speaker chooses to aggregate, then it SHOULD either include
   all AS used to form the aggreagate in an AS_SET or add the
   ATOMIC_AGGREGATE attribute to the route.  This attribute is now pri-
   marily informational.  With the elimination of IP routing protocols
   that do not support classless routing and the elimination of router
   and host implementations that do not support classless routing, there
   is no longer a need to deaggregate.  Routes SHOULD NOT be de-aggre-
   gated.  A route that carries ATOMIC_AGGREGATE attribute in particular
   MUST NOT be de-aggregated. That is, the NLRI of this route can not be
   made more specific. Forwarding along such a route does not guarantee
   that IP packets will actually traverse only ASs listed in the AS_PATH
   attribute of the route.

==> this is confusing, especially the end, beginning from "That is, ..." and
should be reworded a bit (does it cover only deaggregation or more specifics
in general?), like:

   If a BGP speaker chooses to aggregate, then it SHOULD either include
   all AS used to form the aggreagate in an AS_SET or add the
   ATOMIC_AGGREGATE attribute to the route.  This attribute is now pri-
   marily informational.  With the elimination of IP routing protocols
   that do not support classless routing and the elimination of router
   and host implementations that do not support classless routing, there
   is no longer a need to deaggregate.  

   Routes SHOULD NOT be de-aggregated.  A route that carries ATOMIC_AGGREGATE 
   attribute in particular MUST NOT be de-aggregated. That is, one must not
   generate more specifics of the NLRI of this route. Forwarding along 
   such a route does not guarantee
   that IP packets will actually traverse only ASs listed in the AS_PATH
   attribute of the route.  However, accepting more specific advertisments
   which an aggregate route covers is acceptable.

...

   A BGP speaker SHOULD NOT advertise a given feasible BGP route from
   its Adj-RIB-Out if it would produce an UPDATE message containing the
   same BGP route as was previously advertised.

==> and now we get back to the definition of "same BGP route"?  Identical prefix
carried over BGP?  Identical prefix carried over BGP with identical attributes?"
I'm assuming the former, otherwise (at least!) the above should be
clarified.

   Aggregation reduces the amount of information that a BGP speaker must
   store and exchange with other BGP speakers. Routes can be aggregated
   by applying the following procedure separately to path attributes of
   like type and to the Network Layer Reachability Information.

==> the last line sounds really weird; consider:
 - s/like/the same/ ?
 - add more text after the NLRI, like "NLRI field" ?

typos or other editorials
-------------------------

==> there should not be hyphenation at the linebreaks.

   This document specifies the base behavior of the BGP protocol. This
   behavior can and is modified by extention specifications.  When the
   protocol is extended the new behavior is fully documented in the
   extention specifications.

==> s/extention/extension/ (two places)

3.2 Routing Information Bases
                                                                                                     
  The Routing Information Base (RIB) within a BGP speaker consists of
   three distinct parts:

==> the subject is in plural form ("RIBs"), but the text begins as singular
("The RIB").  Consider which one to use?

         a)   ORIGIN (Type Code 1):
                                                                                                     
         b) AS_PATH (Type Code 2):
                                                                                                     
==> kill the extra spaces before ORIGIN and NEXT_HOP.

         1) if the first path segment of the AS_PATH is of type
         AS_SEQUENCE, the local system prepends its own AS number as the
         last element of the sequence (put it in the leftmost position).
 
==> rewrite the last one as:
         last element of the sequence, putting it in the leftmost position.

   A BGP speaker MUST IMPLEMENT a mechanism based on local configuration
 
==> s/IMPLEMENT/implement/

            used by a BGP speaker's decision process to discriminate
 
==> s/decision process/Decision Process/ (similar in a few other places?)

   attribute needs to be cognizant of the fact that the actual path to
 
==> s/cognizant/aware/

6. BGP Error Handling.
                                                                                                  
==> remove the periods from at the end of section titles, esp. in subctions
of section 6.

       issue a open collision dump [Event 23].  When the local
       system receives a open collision dump event [Event 23], the
 
==> s/a open/an open/ (two times)

   installed in LocRib and will be excluded from the next phase of route
  
==> s/LocRib/Loc-RIB/

   all AS used to form the aggreagate in an AS_SET or add the
 
==> s/aggreagate/aggregate/

   is no longer a need to deaggregate.  Routes SHOULD NOT be de-aggre-
   gated.  A route that carries ATOMIC_AGGREGATE attribute in particular
   MUST NOT be de-aggregated. That is, the NLRI of this route can not be
 
==> pick either "deaggregate" or "de-aggregate" and stick to that.

         have the origin attribute with the value EGP. In all other case
 
==> s/case/cases/

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

_______________________________________________
Idr mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/idr

---

From: "John G. Scudder" <[email-masked]>
Date: Wed, 24 Sep 2003 12:34:30 -0400

>General thoughts on going to full standard:

The process the IDR group has been following so far is to try to 
document the existing protocol rather than to tweak it.  In your 
first few comments you seem to be suggesting that the protocol as 
currently deployed isn't suitable for full standard and should be 
tweaked.  Is that what you meant to say?

>   - AS_SET AS_PATH attribute

I can imagine why you think this; however, given that AS_SET is 
already part of presumably all BGP implementations, I can't think of 
a reason to remove it.  On the other hand, I can think of various 
reasons to keep it, including but not limited to "if it ain't broke, 
don't fix it."

>BGP routers might not support BGP-4 or CIDR..

I honestly don't understand the point you're trying to make here.

>   - about N++ different cases of third-party nexthop usage.

Are you suggesting that third-party nexthop should be removed from 
the spec (and from implementations)?  If so, I think more 
justification will be needed.

>receive your own AS in the routes you receive!!

I beg to differ.  The former is not common practice but is not 
unknown either (it's historically there to allow a partitioned AS to 
be healed through an external path).  The latter (AS Path padding) is 
incredibly common.  The text should be left as is, except that I 
wouldn't object to the removal of the clause "for the purpose of 
inter-AS traffic engineering."

>    attribute needs to be cognizant of the fact that the actual path to

Why?

--John

---

From: "John G. Scudder" <[email-masked]>
Date: Wed, 24 Sep 2003 12:34:30 -0400

Why?

--John

---

From: Pekka Savola <[email-masked]>
Date: Thu, 25 Sep 2003 10:31:20 +0300 (EEST)

> tweaked.  Is that what you meant to say?

Yes.  

And moreover, there are certain aspects of the protocol which we may now
consider pretty obsolete.  Consider that we'd like to deprecate them in 3
years.  Doing that from inside Full Standard could be painful -- in
practice, to avoid the confusion, the spec should be re-issued.  However,
if they are in separate portions it would be easier.

What I'm trying to say is that the current base spec is very relevant for 
most parts, and likely continue to be so.  However, I see several parts 
(esp. relating to aggregation) which are no longer relevant, may get to be 
even more irrelevant, and may even turn out to be dangerous or harmful 
later on (considering sBGP/soBGP, for example).

To me, it would seem to be useful to be "proactive" before going to full 
standard, and take out those parts which we think do not have long-term 
usefullness as a full standard.
 
> reasons to keep it, including but not limited to "if it ain't broke, 

There are tradeoffs both ways, that's for sure.  I don't have a really 
strong opinion on this.
 
> I honestly don't understand the point you're trying to make here.

See above, in my first comment.  Automatic route aggregation *in the
protocol* (instead of *operationally*) is a very, very questionable 
concept.  Something we could very well live without...
 
> justification will be needed.

What I say that those scenarios could be moved to a separate spec, and 
accepting third-party nexthops might not be necessary for those who want 
plain next-hop behaviour only.  The code will probably stay as is for some 
time at least.
 
> >       such routes). If such a route were ever used, a routing loop could
[...]
> be healed through an external path).  

The whole point of the AS is that it's not partitioned.  I don't think 
this is needed, or useful at all.

> The latter (AS Path padding) is 

Sorry, I misread the comment (removed from above in clarity).  Prepending
your own AS is perfectly fine to me.

> >    attribute needs to be cognizant of the fact that the actual path to

Why use complex words when simpler ones suit just as well?

---

From: Pekka Savola <[email-masked]>
Date: Thu, 25 Sep 2003 10:31:20 +0300 (EEST)

Yes.  

 

 

[...]

---

From: Jeffrey Haas <[email-masked]>
Date: Thu, 25 Sep 2003 11:13:10 -0400

> concept.  Something we could very well live without...

Perhaps I am not seeing the same thing, but what "automatic" route
aggregation?  Every implementation I've worked with requires
explicit configuration.  The aggregation rules in the spec say what
to do when you do this.

> plain next-hop behaviour only.  The code will probably stay as is for some 

First-party nexthops introduce sub-optimal routing.  Why would we want
to introduce mandatory first party nexthops and optional third-party?

> this is needed, or useful at all.

Consider this rather simplified example:

........   ........
:      :   :      :
: AS 1 :---: AS 1 :
:......:   :......:
     \       /
      \     /
   (           )
  (  Internet   )
   (           )

AS 1 (no, I'm not picking on GTEI, e.g.) is a contiguous AS
with a single point of failure between two portions of itself.
In the case of failure of the link, it is possible to maintain
internal reachability via the Internet by allowing the Internet
Border Routers to ignore a looped condition.

This is *not* a normal circumstance, this is highly abnormal.
However, it can be darned handy.

Other mechanisms such as tunneling between the pieces of the 
partitioned AS have been done as well.

-- 
Jeff Haas 
NextHop Technologies

---

From: Jeffrey Haas <[email-masked]>
Date: Thu, 25 Sep 2003 11:13:10 -0400

........   ........
:      :   :      :
: AS 1 :---: AS 1 :
:......:   :......:
     \       /
      \     /
   (           )
  (  Internet   )
   (           )

-- 
Jeff Haas 
NextHop Technologies

---

From: Pekka Savola <[email-masked]>
Date: Thu, 25 Sep 2003 19:26:40 +0300 (EEST)

> explicit configuration.  The aggregation rules in the spec say what

"auto-summary" (in Cisco terms) has bitten us a couple of times.  It's
automatic.  But then again, I may be misremembering something (and I'm 
not 100% sure auto-summary is directly related to aggregation, but the 
concept is similar).

The problem with aggregation I see is that more often than not it does
nothing to reduce the number of advertisements (or anything useful for
that matter).  ISPs let through the more specifics in addition to the
aggregate (seems to be the default config too).  How is this useful?  I'm
having trouble figuring out real applicability for aggregation.

> to introduce mandatory first party nexthops and optional third-party?

Note, I'm discussing third-party nexthops in EBGP only (I'm not sure if I 
mentioned this explicitly, or if there's a need to).

Why would you need the optimal routing w/ third-party next-hops and EBGP?  
You can just go through the BGP speaker, period. (In case if you pass 
through an Internet Exchange more than once.)

> Consider this rather simplified example:

This is a bug, not feature.  Your internal connectivity just *isn't* meant 
to be routed through the Internet.
 
> partitioned AS have been done as well.

Right!

---

From: Pekka Savola <[email-masked]>
Date: Thu, 25 Sep 2003 19:26:40 +0300 (EEST)

Right!

---

From: "John G. Scudder" <[email-masked]>
Date: Thu, 25 Sep 2003 12:43:26 -0400

>having trouble figuring out real applicability for aggregation.

The BGP spec doesn't talk about auto-anything.  In the interests of 
moving the conversation forward, it would help if you cited specific 
language in the spec that you object to pertaining to aggregation.

>to be routed through the Internet.

You are welcome to arrange your internal connectivity however you 
like.  Not everyone agrees.  Since as specified, the behavior doesn't 
affect BGP's correctness it's not a bug in a formal sense.  No BGP 
implementation I'm aware of allows AS loops by default so it's not a 
bug in an operational sense either.

IMO there is no need to make the proposed change to the protocol.

--John

---

From: "John G. Scudder" <[email-masked]>
Date: Thu, 25 Sep 2003 12:43:26 -0400

--John

---

From: Pekka Savola <[email-masked]>
Date: Fri, 26 Sep 2003 12:44:01 +0300 (EEST)

> language in the spec that you object to pertaining to aggregation.

Most of sections 4.3 g), 5.1.7, and 9.2.2.2.
 
> IMO there is no need to make the proposed change to the protocol.

Vendors are also free to implement additional features than those listed 
in the BGP spec.

It is a bug in the specification sense because the spec does not include 
text that you should do loop prevention by discarding the path when it 
contains your own AS.

Further, there is no need to do anything of this sort if you get default 
routes from the Internet, or set up a backup (highest protocol distance) 
route towards the Internet.

But this is just one little issue, compared to some others.  If no one 
else feels this is something that shouldn't be in the spec, feel free to 
ignore the argument.

---

From: Pekka Savola <[email-masked]>
Date: Fri, 26 Sep 2003 12:44:01 +0300 (EEST)

---

From: Dennis Ferguson <[email-masked]>
Date: Fri, 26 Sep 2003 15:40:11 -0700

> text that you should do loop prevention by discarding the path when it 

The minimal theoretical requirement for loop termination (BGP doesn't
prevent loops which occur transiently, just guarantees they'll eventually
be stopped) is that you should discard the path when it includes your
own AS `N' times, for any `N' you care to choose.  While N=1, which you like,
will terminate loops, letting N=2 or N=5 or N=12 will terminate them
just fine as well (though you are wasting convergence time if you make
`N' larger than the number of inter-AS border routers you have, at most).
It hence isn't a bug to allow `N' to be set to a value other than 1 in
any theoretical sense.

> route towards the Internet.

I'm sure you don't mean that one or the other of those things is always
possible to do.  It is when neither of those things is possible that you
might want to set N>1 instead.

Dennis Ferguson

---

From: Dennis Ferguson <[email-masked]>
Date: Fri, 26 Sep 2003 15:40:11 -0700

Dennis Ferguson

---

From: Yakov Rekhter <[email-masked]>
Date: Mon, 29 Sep 2003 07:04:03 -0700

Pekka,

> least on the quick glance, I didn't find major overlaps.

I am replying only to the comments that haven't been addressed
by other folks who already replied to you.

>  - If we want to go for full standard, I have to question the usefulness of

At the present moment we are *not* going for full standard - we are
going for a draft standard.

[clipped..]

> whehter it's of any use keeping it in the base spec.

Please argue this issue with Routing ADs

> rules :-(!!!) and ended up skipping them.

The current text reflects consensus reached by the WG.

> the pretense about field lengths, bits 0-31, etc.

This is an editorial comment, and will be handled at the discretion
of the editors.

> clarified in the text below, and the text should be reviewed.

What makes you think that "locally originated" means "local to the routing
domain" ?

[clipped...]

> this has already been investigated, it may be worth checking with the ADs

I would leave it up to ADs to decide on this.

                   
                   
>    ietf-idr-bgp-vuln-00.txt, work in progress

The rest of the comments are editorial, and will be handled
at the discretion of the editors.

Yakov.

---

From: Yakov Rekhter <[email-masked]>
Date: Mon, 29 Sep 2003 07:04:03 -0700

Pekka,

[clipped..]

                        

[clipped...]

                   

Yakov.

---

From: Pekka Savola <[email-masked]>
Date: Tue, 30 Sep 2003 09:52:00 +0300 (EEST)

> It hence isn't a bug to allow `N' to be set to a value other than 1 in

I wouldn't call such an AS having a coherent routing plan.  If you allow 
AS > 1, you're abusing the term AS.

> might want to set N>1 instead.

Can you shown me a couple (or at least _one_) example where other methods 
are not possible and this is required?

---

From: Pekka Savola <[email-masked]>
Date: Tue, 30 Sep 2003 09:52:00 +0300 (EEST)

---

From: Pekka Savola <[email-masked]>
Date: Tue, 30 Sep 2003 10:10:49 +0300 (EEST)

Responding to two issues which seem may warrant further discussion from 
me..

> The current text reflects consensus reached by the WG.

Note that there are two issues here:
 1) the text is out-of-sync between sections 3 and 4.3, and
 2) that the current definition of BGP route used for forwarding is not 
really useful.

I take it that the comment 1) is still valid.

Has 2) -- which you were probably referring to -- been raised as an issue
in the spec?  Any pointers to the issue, discussion, and the conclusion
(the answer to the question "Why did the WG decide this way?")  I fail to
see why such a conclusion would be justified.. and if the relevant points 
haven't been raised already, I probably want to re-open that debate.

> What makes you think that "locally originated" means "local to the routing

The text:

     1) When sending a message to an internal peer, if the route is not
      locally originated the BGP speaker SHOULD NOT modify the NEXT_HOP
      attribute, unless it has been explicitly configured to announce
      its own IP address as the NEXT_HOP.

.. because, obviously, you do not _modify_ NEXT_HOP for any routes which 
you originate.  You _set_ it to be something.  Further, you use double 
negative in above, so it's pretty difficult to figure out what's the 
actual intent there...:

 - if the route is locally originated the BGP speaker ...
    a) <undefined> ?
    b) SHOULD modify NEXT_HOP (or something else) ?
 - if the route is not locally originated, the BGP speaker SHOULD NOT 
modify NEXT_HOP

So, I'd suggest rewording the start of that paragraph; perhaps e.g.:

      1) When sending a message to an internal peer, and the route is 
      not originated by the BGP speaker, the BGP speaker SHOULD keep the 
      NEXT_HOP attribute intact, unless it has been explicitly configured 
      to announce its own IP address as the NEXT_HOP.

---

From: Pekka Savola <[email-masked]>
Date: Tue, 30 Sep 2003 10:10:49 +0300 (EEST)

The text:

---

From: Yakov Rekhter <[email-masked]>
Date: Tue, 30 Sep 2003 05:55:56 -0700

Pekka,

[clipped...]

>       to announce its own IP address as the NEXT_HOP. 

The current text reflects the consensus of the WG (see 2.61 in
draft-ietf-idr-bgp-issues-01.txt).

Yakov.

---

From: Yakov Rekhter <[email-masked]>
Date: Tue, 30 Sep 2003 05:55:56 -0700

Pekka,

[clipped...]

Yakov.

---

From: Pekka Savola <[email-masked]>
Date: Tue, 30 Sep 2003 16:58:20 +0300 (EEST)

> draft-ietf-idr-bgp-issues-01.txt).

Looking at 2.61, it seems that issue made solely for the _next_ sentences, 
i.e., for the case of locally originated routes.  In both the old and the 
new text, the text I'd like to change seemed to be unchanged.

So, I'm not sure if I see that this proposal is an old, already
concensus-achieved issue ?

---

From: Pekka Savola <[email-masked]>
Date: Tue, 30 Sep 2003 16:58:20 +0300 (EEST)

---

From: Yakov Rekhter <[email-masked]>
Date: Tue, 30 Sep 2003 10:53:39 -0700

Pekka,

> > > rules :-(!!!) and ended up skipping them.

Could you point me to the text in the spec that said that "feasible" is 
a superset of "only those routes that the router itself uses" ?

> haven't been raised already, I probably want to re-open that debate.

From draft-ietf-idr-bgp-issues-01.txt:

   After some additional discussion (in the "issue 11.2" thread), we
   have come to a consensus on this text:
   
   In the context of this document we assume that a BGP speaker
   advertises to its peers only those routes that it itself uses (in
   this context a BGP speaker is said to "use" a BGP route if it is the 
   most preferred BGP route and is used in forwarding). All other cases
   are outside the scope of this document.
   
   This issue is at consensus.

So, the text in the spec represents consensus of the WG. Also note
the last sentence in the above paragraph.

Yakov.

---

From: Yakov Rekhter <[email-masked]>
Date: Tue, 30 Sep 2003 10:53:39 -0700

Pekka,

   

Yakov.

---

From: Dennis Ferguson <[email-masked]>
Date: Tue, 30 Sep 2003 12:28:43 -0700

> AS > 1, you're abusing the term AS.

I notice you've changed the subject from one of protocol correctness, i.e.
whether routing loops are guaranteed to terminate, to one of policy, i.e.
whether, in your opinion, it is a good idea to do this to solve routing
problems one might have when using the protocol.

As the people who originally responded to you implied, the BGP protocol
specification has always tried to limit itself to ensuring protocol
correctness while leaving policy to the users of the protocol.  I think
that's still appropriate.

> are not possible and this is required?
 
Suppose the operators of two multiply-connected networks agree to provide
backup routing to heal each other's partitions without offering transit
to the rest of "the Internet".  Here you need explicit routing for the
destinations being backed up (they may already default traffic to "the
Internet" to other providers), and you certainly can't have two guys
pointing default routes at each other in any case.

Or, suppose three operators have entered into a similar arrangement, with
the partitioned guy being allowed to split his load across the other two.
You can't have two default routes pointing at different guys (especially
if "the Internet" is in some other direction), and you generally need
explicit routes to get a predictable load split.

Of course these are only problems I can think of, there are likely
lots more problems that I can't imagine.  The latter is the reason the
BGP specification should limit itself to protocol correctness issues,
leaving policy issues to the protocol users who actually have the
problems to solve.

Dennis Ferguson

---

From: Dennis Ferguson <[email-masked]>
Date: Tue, 30 Sep 2003 12:28:43 -0700

Dennis Ferguson

To: Pekka Savola <[email-masked]>
cc: "John G. Scudder" <[email-masked]>, Jeffrey Haas <[email-masked]>, [email-masked]
Subject: Re: [Idr] comments on idr-bgp4-20 
From: Dennis Ferguson <[email-masked]>
Sender: [email-masked]
Date: Tue, 30 Sep 2003 12:28:43 -0700

 

Dennis Ferguson

To: Yakov Rekhter <[email-masked]>
From: "John G. Scudder" <[email-masked]>
Subject: Re: [Idr] Proposed change to 9.1.2.2
Cc: [email-masked]
Sender: [email-masked]
Date: Tue, 30 Sep 2003 14:21:49 -0400

At 11:15 AM -0700 9/30/03, Yakov Rekhter wrote:
>Do you have any objections if instead of the text proposed above
>we'll follow Enke's suggestion ? Namely, replace
>
>         If the route is learned via IBGP, and the other IBGP
>         speaker originated the route, it is the local AS.
>
>with
>          If the route is learned via IBGP, and the other IBGP
>          speaker originated the route or created the aggregate,
>          it is the local AS.
>
>(especially since Enke's text reflects several implementations)

As does mine for that matter, but I am fine with Enke's text.  For 
one thing, it accomplishes the job using fewer words, always a good 
thing.

>  > I suppose it might also be worth saying (somewhere else, e.g. under
>>  the discussion of aggregation) that if you create an aggregated route
>>  which has an AS_SET as the first element in its AS_PATH, then you
>>  SHOULD strip the MED out.  This is just belt and suspenders though,
>>  and I don't much care if we do it or not.
>
>In the absence of any objections I'll add this to the spec.

OK.

--John

To: "John G. Scudder" <[email-masked]>
cc: [email-masked]
Subject: Re: [Idr] Proposed change to 9.1.2.2 
From: Yakov Rekhter <[email-masked]>
Sender: [email-masked]
Date: Tue, 30 Sep 2003 11:15:47 -0700

John,

> Folks,
> 
> There is a minor bug in the MED-handling procedures (9.1.2.2) of the BGP spec
:
> 
>        c) Remove from consideration routes with less-preferred
>        MULTI_EXIT_DISC attributes. MULTI_EXIT_DISC is only comparable
>        between routes learned from the same neighboring AS (the neighbor-
>        ing AS is determined from the AS_PATH attribute). Routes which do
>        not have the MULTI_EXIT_DISC attribute are considered to have the
>        lowest possible MULTI_EXIT_DISC value.
> 
>        This is also described in the following procedure:
> 
>              for m = all routes still under consideration
>                  for n = all routes still under consideration
>                      if (neighborAS(m) == neighborAS(n)) and (MED(n) < MED(m)
)
>                          remove route m from consideration
> 
>        In the pseudo-code above, MED(n) is a function which returns the
>        value of route n's MULTI_EXIT_DISC attribute. If route n has no
>        MULTI_EXIT_DISC attribute, the function returns the lowest possi-
>        ble MULTI_EXIT_DISC value, i.e. 0.
> 
>        Similarly, neighborAS(n) is a function which returns the neighbor
>        AS from which the route was received.  If the route is learned via
>        IBGP, and the other IBGP speaker didn't originate the route, it is
>        the neighbor AS from which the other IBGP speaker learned the
>        route. If the route is learned via IBGP, and the other IBGP
>        speaker originated the route, it is the local AS.
> 
> This text assumes that it is always possible to unambiguously 
> determine a unique neighbor AS for any route.  However, in principle 
> this is not the case, as when a border router performs aggregation 
> towards IBGP, leading to a route whose AS path begins with an AS_SET.
> 
> To correct this I propose that the following paragraph be added 
> immediately following the text quoted above.
> 
>        In some cases it may not be possible to determine an unambiguous,
>        unique neighbor AS, such as when the AS_PATH attribute begins with
>        an AS_SET due to aggregation.  If the neighbor AS of a route cannot
>        be determined, the MULTI_EXIT_DISC MUST NOT be compared with the
>        MULTI_EXIT_DISC of any other route.  For the purposes of the pseudo-
>        code above, this can be accomplished by considering neighborAS(n)
>        to return a special distinguished "not found" value (which is not
>        equal to any AS value) and MED(n) to return 0 for such routes.

Do you have any objections if instead of the text proposed above
we'll follow Enke's suggestion ? Namely, replace

        If the route is learned via IBGP, and the other IBGP
        speaker originated the route, it is the local AS.

with
         If the route is learned via IBGP, and the other IBGP
         speaker originated the route or created the aggregate,
         it is the local AS.

(especially since Enke's text reflects several implementations)

> I suppose it might also be worth saying (somewhere else, e.g. under 
> the discussion of aggregation) that if you create an aggregated route 
> which has an AS_SET as the first element in its AS_PATH, then you 
> SHOULD strip the MED out.  This is just belt and suspenders though, 
> and I don't much care if we do it or not.

In the absence of any objections I'll add this to the spec.

Yakov.

To: Pekka Savola <[email-masked]>
cc: [email-masked]
Subject: Re: [Idr] comments on idr-bgp4-20 
From: Yakov Rekhter <[email-masked]>
Sender: [email-masked]
Date: Tue, 30 Sep 2003 10:53:39 -0700

Pekka,

   

Yakov.

To: "John G. Scudder" <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: [Idr] Proposed change to 9.1.2.2 
From: Enke Chen <[email-masked]>
Sender: [email-masked]
Date: Tue, 30 Sep 2003 09:01:55 -0700

John,

> Message-Id: <p06001a6fbb72786393ed@[64.101.214.208]>
> To: [email-masked]
> From: "John G. Scudder" <[email-masked]>
> Content-Type: text/plain; charset="us-ascii" ; format="flowed"
> Subject: [Idr] Proposed change to 9.1.2.2
> Sender: [email-masked]
> 
> Folks,
> 
> There is a minor bug in the MED-handling procedures (9.1.2.2) of the BGP spec:
> 
>        c) Remove from consideration routes with less-preferred
>        MULTI_EXIT_DISC attributes. MULTI_EXIT_DISC is only comparable
>        between routes learned from the same neighboring AS (the neighbor-
>        ing AS is determined from the AS_PATH attribute). Routes which do
>        not have the MULTI_EXIT_DISC attribute are considered to have the
>        lowest possible MULTI_EXIT_DISC value.
> 
>        This is also described in the following procedure:
> 
>              for m = all routes still under consideration
>                  for n = all routes still under consideration
>                      if (neighborAS(m) == neighborAS(n)) and (MED(n) < MED(m))
>                          remove route m from consideration
> 
>        In the pseudo-code above, MED(n) is a function which returns the
>        value of route n's MULTI_EXIT_DISC attribute. If route n has no
>        MULTI_EXIT_DISC attribute, the function returns the lowest possi-
>        ble MULTI_EXIT_DISC value, i.e. 0.
> 
>        Similarly, neighborAS(n) is a function which returns the neighbor
>        AS from which the route was received.  If the route is learned via
>        IBGP, and the other IBGP speaker didn't originate the route, it is
>        the neighbor AS from which the other IBGP speaker learned the
>        route. If the route is learned via IBGP, and the other IBGP
>        speaker originated the route, it is the local AS.
> 
> This text assumes that it is always possible to unambiguously 
> determine a unique neighbor AS for any route.  However, in principle 
> this is not the case, as when a border router performs aggregation 
> towards IBGP, leading to a route whose AS path begins with an AS_SET.

I believe that an aggregated route is treated the same as an originated
route in this regard by several implementations I am familiar with. Such
treatment does make sense - a route is originated when you aggregate.

If further clarification is desired in the spec, we could revise it
like the following:

         If the route is learned via IBGP, and the other IBGP
         speaker originated the route or created the aggregate,
                                      ++++++++++++++++++++++++
         it is the local AS.

Regards, 

-- Enke

> 
> 
> To correct this I propose that the following paragraph be added 
> immediately following the text quoted above.
> 
>        In some cases it may not be possible to determine an unambiguous,
>        unique neighbor AS, such as when the AS_PATH attribute begins with
>        an AS_SET due to aggregation.  If the neighbor AS of a route cannot
>        be determined, the MULTI_EXIT_DISC MUST NOT be compared with the
>        MULTI_EXIT_DISC of any other route.  For the purposes of the pseudo-
>        code above, this can be accomplished by considering neighborAS(n)
>        to return a special distinguished "not found" value (which is not
>        equal to any AS value) and MED(n) to return 0 for such routes.
> 
> I suppose it might also be worth saying (somewhere else, e.g. under 
> the discussion of aggregation) that if you create an aggregated route 
> which has an AS_SET as the first element in its AS_PATH, then you 
> SHOULD strip the MED out.  This is just belt and suspenders though, 
> and I don't much care if we do it or not.
> 
> In reality I doubt this case is ever seen in the wild, but it's good 
> to have the spec right anyway.
> 
> Regards,
> 
> --John
> 

From: Jeffrey Haas <[email-masked]>
To: "John G. Scudder" <[email-masked]>
Cc: [email-masked]
Subject: Re: [Idr] Proposed change to 9.1.2.2
Sender: [email-masked]
Date: Tue, 30 Sep 2003 11:32:47 -0400

On Tue, Sep 30, 2003 at 11:19:23AM -0400, John G. Scudder wrote:
> I suppose it might also be worth saying (somewhere else, e.g. under 
> the discussion of aggregation) that if you create an aggregated route 
> which has an AS_SET as the first element in its AS_PATH, then you 
> SHOULD strip the MED out.

Well, this is only important if you're allowing routes to be aggregated
regardless of MED value. :-)

Good catch though.

This makes me wonder if our elders had already though of this particular
case and that was what the odd restriction of not aggregating things with
different MEDs was really for.  If you don't aggregate things with
different MEDs, you can simply check the leading set for the
presence of the AS.

-- 
Jeff Haas 
NextHop Technologies

To: [email-masked]
From: "John G. Scudder" <[email-masked]>
Subject: [Idr] Proposed change to 9.1.2.2
Sender: [email-masked]
Date: Tue, 30 Sep 2003 11:19:23 -0400

Folks,

There is a minor bug in the MED-handling procedures (9.1.2.2) of the BGP spec:

       c) Remove from consideration routes with less-preferred
       MULTI_EXIT_DISC attributes. MULTI_EXIT_DISC is only comparable
       between routes learned from the same neighboring AS (the neighbor-
       ing AS is determined from the AS_PATH attribute). Routes which do
       not have the MULTI_EXIT_DISC attribute are considered to have the
       lowest possible MULTI_EXIT_DISC value.

       This is also described in the following procedure:

             for m = all routes still under consideration
                 for n = all routes still under consideration
                     if (neighborAS(m) == neighborAS(n)) and (MED(n) < MED(m))
                         remove route m from consideration

       In the pseudo-code above, MED(n) is a function which returns the
       value of route n's MULTI_EXIT_DISC attribute. If route n has no
       MULTI_EXIT_DISC attribute, the function returns the lowest possi-
       ble MULTI_EXIT_DISC value, i.e. 0.

       Similarly, neighborAS(n) is a function which returns the neighbor
       AS from which the route was received.  If the route is learned via
       IBGP, and the other IBGP speaker didn't originate the route, it is
       the neighbor AS from which the other IBGP speaker learned the
       route. If the route is learned via IBGP, and the other IBGP
       speaker originated the route, it is the local AS.

This text assumes that it is always possible to unambiguously 
determine a unique neighbor AS for any route.  However, in principle 
this is not the case, as when a border router performs aggregation 
towards IBGP, leading to a route whose AS path begins with an AS_SET.

To correct this I propose that the following paragraph be added 
immediately following the text quoted above.

       In some cases it may not be possible to determine an unambiguous,
       unique neighbor AS, such as when the AS_PATH attribute begins with
       an AS_SET due to aggregation.  If the neighbor AS of a route cannot
       be determined, the MULTI_EXIT_DISC MUST NOT be compared with the
       MULTI_EXIT_DISC of any other route.  For the purposes of the pseudo-
       code above, this can be accomplished by considering neighborAS(n)
       to return a special distinguished "not found" value (which is not
       equal to any AS value) and MED(n) to return 0 for such routes.

I suppose it might also be worth saying (somewhere else, e.g. under 
the discussion of aggregation) that if you create an aggregated route 
which has an AS_SET as the first element in its AS_PATH, then you 
SHOULD strip the MED out.  This is just belt and suspenders though, 
and I don't much care if we do it or not.

In reality I doubt this case is ever seen in the wild, but it's good 
to have the spec right anyway.

Regards,

--John

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: [Idr] I-D ACTION:draft-ietf-idr-restart-08.txt
Sender: [email-masked]
Date: Tue, 30 Sep 2003 11:18:38 -0400

--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		: Graceful Restart Mechanism for BGP
	Author(s)	: S. Sangli, Y. Rekhter et al.
	Filename	: draft-ietf-idr-restart-08.txt
	Pages		: 10
	Date		: 2003-9-30
	
This document proposes a mechanism for BGP that would help minimize
the negative effects on routing caused by BGP restart. An End-of-RIB
marker is specified and can be used to convey routing convergence
information.  A new BGP capability, termed 'Graceful Restart
Capability', is defined which would allow a BGP speaker to express
its ability to preserve forwarding state during BGP restart. Finally,
procedures are outlined for temporarily retaining routing information
across a TCP transport reset.
The mechanisms described in this document are applicable to all
routers, both those with the ability to preserve forwarding state
during BGP restart and those without (although the latter need to
implement only a subset of the mechanisms described in this
document).

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-idr-restart-08.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-restart-08.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-restart-08.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-restart-08.txt

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

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

--OtherAccess--

--NextPart--

From: Pekka Savola <[email-masked]>
To: Yakov Rekhter <[email-masked]>
cc: [email-masked]
Subject: Re: [Idr] comments on idr-bgp4-20 
Sender: [email-masked]
Date: Tue, 30 Sep 2003 16:58:20 +0300 (EEST)

To: Pekka Savola <[email-masked]>
cc: Yakov Rekhter <[email-masked]>, [email-masked]
Subject: Re: [Idr] comments on idr-bgp4-20 
From: Yakov Rekhter <[email-masked]>
Sender: [email-masked]
Date: Tue, 30 Sep 2003 05:55:56 -0700

Pekka,

[clipped...]

Yakov.

From: Pekka Savola <[email-masked]>
To: Yakov Rekhter <[email-masked]>
cc: [email-masked]
Subject: Re: [Idr] comments on idr-bgp4-20 
Sender: [email-masked]
Date: Tue, 30 Sep 2003 10:10:49 +0300 (EEST)

The text:

From: Pekka Savola <[email-masked]>
To: Dennis Ferguson <[email-masked]>
cc: "John G. Scudder" <[email-masked]>, Jeffrey Haas <[email-masked]>, <[email-masked]>
Subject: Re: [Idr] comments on idr-bgp4-20 
Sender: [email-masked]
Date: Tue, 30 Sep 2003 09:52:00 +0300 (EEST)

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: [Idr] I-D ACTION:draft-ietf-idr-bgp4-21.txt
Sender: [email-masked]
Date: Mon, 29 Sep 2003 15:37:47 -0400

--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 et al.
	Filename	: draft-ietf-idr-bgp4-21.txt
	Pages		: 98
	Date		: 2003-9-29
	
The Border Gateway Protocol (BGP) is an inter-Autonomous System routing protocol.
The primary function of a BGP speaking system is to exchange network
reachability information with other BGP systems. This network
reachability information includes information on the list of
Autonomous Systems (ASs) that reachability information traverses.
This information is sufficient to construct a graph of AS
connectivity for this reachability from which routing loops may be
pruned and some policy decisions at the AS level may be enforced.
BGP-4 provides a set of mechanisms for supporting Classless Inter-
Domain Routing (CIDR) [RFC1518, RFC1519]. These mechanisms include
support for advertising a set of destinations as an IP prefix, and
eliminating the concept of network 'class' within BGP.  BGP-4 also
introduces mechanisms which allow aggregation of routes, including
aggregation of AS paths.
Routing information exchanged via BGP supports only the destination-
based forwarding paradigm, which assumes that a router forwards a
packet based solely on the destination address carried in the IP
header of the packet. This, in turn, reflects the set of policy
decisions that can (and can not) be enforced using BGP. BGP can
support only the policies conforming to the destination-based
forwarding paradigm.
This specification covers only the exchange of IP version 4 network
reachability information.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-idr-bgp4-21.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-21.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-21.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-21.txt

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

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

--OtherAccess--

--NextPart--

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: [Idr] I-D ACTION:draft-ietf-idr-bgp4-experience-protocol-03.txt
Sender: [email-masked]
Date: Mon, 29 Sep 2003 15:37:52 -0400

--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		: Experience with the BGP-4 Protocol
	Author(s)	: D. McPherson, K. Patel
	Filename	: draft-ietf-idr-bgp4-experience-protocol-03.txt
	Pages		: 22
	Date		: 2003-9-29
	
The purpose of this memo is to document how the requirements for
advancing a routing protocol from Draft Standard to full Standard
have been satisfied by Border Gateway Protocol version 4 (BGP-4).
This report satisfies the requirement for 'the second report', as
described in Section 6.0 of RFC 1264.  In order to fulfill the
requirement, this report augments RFC 1773 and describes additional
knowledge and understanding gained in the time between when the
protocol was made a Draft Standard and when it was submitted for
Standard.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-idr-bgp4-experience-protocol-03.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-experience-protocol-03.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-experience-protocol-03.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-experience-protocol-03.txt

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

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

--OtherAccess--

--NextPart--

To: [email-masked]
cc: [email-masked]
From: Yakov Rekhter <[email-masked]>
Subject: [Idr] WG Last Call on draft-ietf-idr-bgp4-analysis-04.txt
Sender: [email-masked]
Date: Mon, 29 Sep 2003 09:41:43 -0700

Folks,

This is to start WG Last Call on advancing 
draft-ietf-idr-bgp4-analysis-04.txt to an Informational RFC.
The Last Call ends Oct 13, 2003.

Sue & Yakov

To: Pekka Savola <[email-masked]>
cc: [email-masked]
Subject: Re: [Idr] comments on idr-bgp4-20 
From: Yakov Rekhter <[email-masked]>
Sender: [email-masked]
Date: Mon, 29 Sep 2003 07:04:03 -0700

Pekka,

[clipped..]

                        

[clipped...]

                   

Yakov.

From: [email-masked]
To: [email-masked]
Reply-To: [email-masked]
Subject: [Idr] AWARD NOTIFICATION
Sender: [email-masked]
Date: Sat, 27 Sep 2003 18:25:44 +0200

                              EL GORDO LAPRIMITIVA
                              C/GUZMAN EL BUENO,137
                                   MADRID - ESPAÑA 
                      TEL: +34-660 651 909 FAX:+34 645 440 201
                            E-mail: [email-masked]

FROM: OFFICE OF THE PROMOTIONS MANAGER, 
INTERNATIONAL PROMOTIONS/PRIZE AWARD DEPARTMENT, 
REF: LP/26510460037/03 
BATCH: 24/00319/IPD

RE: AWARD NOTIFICATION FINAL NOTICE 

We are pleased to inform you of the release of the ELGORDO LAPRIMITIVA LOTTERY/INTERNATIONAL PROGRAMS held on the 20th of September,2003.Your  email address attached to ticket number 025- 1146-4992-750 with serial number 2113-05 drew the lucky numbers 3-18-19-30-32-39, which consequently won the lottery in the 3rd category. 

You are therefore been approved for the lump sum pay out of €uros 847,828.87 (Eight hundred and fourty seven thousand eight hundred and eighty two .eighty seven cents.) in cash credited to file REF: LP/26510460037/03. This is from a total prize of €uros 10,500,000.00 shared among the seventeen (17) International winners in this category. 

CONGRATULATIONS!!!!!!!!!!!!!!!!!!!!!.

Your fund is now deposited with SANTA LUCIA SEGUROS but due to mix up of some numbers and addresses, we ask that you keep this award a top secret from the public notice until your claim has been processed and your prize money remitted to your account as this is part of our Security protocol to avoid double claiming by participants of this programme. 

All participants were selected through a computer ballot system drawn from 30,000 addresses from Australia, USA,  Europe, Asia ,New Zealand, Middle-East,South-North America and Africa as part of our international promotions program which is conducted annually. We hope with a part of your prize money, you will participate in our end of the year high stakes of €uros 300.000.000.00 Million International Lottery. 

To being your claim, please contact the claim agent Mr David Manuel, (Foreign Service Manager) for processing and remittance of your prize money to any designated account of your choice.Please call on this # Tel:+34686358621.Email:[email-masked]  Please note that all prize money must be claimed before the 20th of October, 2003. After this date, all funds will be returned as unclaimed. 

Note: In order to avoid unnecessary delays and complications, please remember to quote your reference and batch numbers in every of your correspondence with your agent. Furthermore, should there be any change of address,do inform your claims agent as soon as possible. 

Please remember to ask for your prize claim certificate. Congratulations again from all members of our staff.

Best regards, 

MARIA JOSE SANCHEZ.

To: Pekka Savola <[email-masked]>
cc: "John G. Scudder" <[email-masked]>, Jeffrey Haas <[email-masked]>, [email-masked]
Subject: Re: [Idr] comments on idr-bgp4-20 
From: Dennis Ferguson <[email-masked]>
Sender: [email-masked]
Date: Fri, 26 Sep 2003 15:40:11 -0700

Dennis Ferguson

From: Pekka Savola <[email-masked]>
To: "John G. Scudder" <[email-masked]>
cc: Jeffrey Haas <[email-masked]>, <[email-masked]>
Subject: Re: [Idr] comments on idr-bgp4-20
Sender: [email-masked]
Date: Fri, 26 Sep 2003 12:44:01 +0300 (EEST)

 

To: Pekka Savola <[email-masked]>
From: "John G. Scudder" <[email-masked]>
Subject: Re: [Idr] comments on idr-bgp4-20
Cc: Jeffrey Haas <[email-masked]>, [email-masked]
Sender: [email-masked]
Date: Thu, 25 Sep 2003 12:43:26 -0400

--John

From: Pekka Savola <[email-masked]>
To: Jeffrey Haas <[email-masked]>
cc: [email-masked]
Subject: Re: [Idr] comments on idr-bgp4-20
Sender: [email-masked]
Date: Thu, 25 Sep 2003 19:26:40 +0300 (EEST)

 

Right!

From: Jeffrey Haas <[email-masked]>
To: Pekka Savola <[email-masked]>
Cc: [email-masked]
Subject: Re: [Idr] comments on idr-bgp4-20
Sender: [email-masked]
Date: Thu, 25 Sep 2003 11:13:10 -0400

........   ........
:      :   :      :
: AS 1 :---: AS 1 :
:......:   :......:
     \       /
      \     /
   (           )
  (  Internet   )
   (           )

-- 
Jeff Haas 
NextHop Technologies

From: Pekka Savola <[email-masked]>
To: "John G. Scudder" <[email-masked]>
cc: [email-masked]
Subject: Re: [Idr] comments on idr-bgp4-20
Sender: [email-masked]
Date: Thu, 25 Sep 2003 10:31:20 +0300 (EEST)

Yes.  

 

 

[...]

From: Pekka Savola <[email-masked]>
To: Susan Hares <[email-masked]>
cc: [email-masked]
Subject: RE: [Idr] comments on idr-bgp4-20
Sender: [email-masked]
Date: Thu, 25 Sep 2003 08:08:42 +0300 (EEST)

On Wed, 24 Sep 2003, Susan Hares wrote:
> For context on the message, could you
> tell me are you:
> 
> 	2) Operator using BGP

Operator.

> -----Original Message-----
> From: Pekka Savola [mailto:[email-masked]]
> Sent: Wednesday, September 24, 2003 3:50 AM
> To: [email-masked]
> Subject: [Idr] comments on idr-bgp4-20
> 
> 
> Hi,
> 

To: Pekka Savola <[email-masked]>
From: "John G. Scudder" <[email-masked]>
Subject: Re: [Idr] comments on idr-bgp4-20
Cc: [email-masked]
Sender: [email-masked]
Date: Wed, 24 Sep 2003 12:34:30 -0400

Why?

--John

content-class: urn:content-classes:message
Subject: RE: [Idr] comments on idr-bgp4-20
From: "Susan Hares" <[email-masked]>
To: "Pekka Savola" <[email-masked]>, <[email-masked]>
Sender: [email-masked]
Date: Wed, 24 Sep 2003 11:39:00 -0400

Pekka:

For context on the message, could you
tell me are you:

	1) Implementor of BGP
	2) Operator using BGP
	3) Network researcher
	4) other 

Sue Hares

-----Original Message-----
From: Pekka Savola [mailto:[email-masked]]
Sent: Wednesday, September 24, 2003 3:50 AM
To: [email-masked]
Subject: [Idr] comments on idr-bgp4-20

Hi,

Overview:

substantial
-----------

                                                                                                     
       0                   1                   2                   3

5.1.3 NEXT_HOP

and:

                                                                                                  

                                                                                                
Normative References

Non-normative References

semi-substantial
----------------

   Adj-RIB-In
   Adj-RIBs-In
   Adj-RIB-Out
   Adj-RIBs-Out

   BGP speaker

   BGP speaker

....

      BGP Identifier:

...

      Path Attributes:

	

...

...

                                                                                                     

 

                                                                                                  

...

                                                                                                     

         a)   ORIGIN (Type Code 1):

 

 

==> s/cognizant/aware/

6. BGP Error Handling.

 

==> s/LocRib/Loc-RIB/

 

==> s/case/cases/

From: "Dr.Douglas Akpeki" <[email-masked]>
Reply-To: [email-masked]
To: [email-masked]
Subject: [Idr] INVITATION TO PARTNERSHIP
Sender: [email-masked]
Date: Wed, 24 Sep 2003 12:32:23 +0100

Dear Sir,
          REQUEST FOR YOUR UNRESERVED ASSISTANCE.
 This letter may come to you as a surprise but it was borne
out of my sincere desire to share a mutual business relationship 
with you. 
 
 First, your strictest confidence in this transaction is highly 
solicited. This is by virtue of its nature as being utterly
confidential and top secret. I am a top government official with 
a statutory corporation and member of an adhoc committee set up 
by the Federal Government of Nigeria to review contract awarded 
by past administration. In the course of identifying, 
srcutinising and recommending for the payment of all valid 
contract executed, we discovered a huge sum of money amounting to
USD41.5M (Forty One Million five Hundred Thousand US Dollars) on 
grossly over invoiced contract already awarded and exccuted for 
the Nigerian National Petroleum Corporation.
 
 Having cleaned the ‘AUGEAN STABLE‘ we intend to transfer the 
balance of USD41.5M presently floating in our apex bank of 
Nigeria to our own benefit and advantage. However, we request 
for your unwavering assistance in this regard because as civil 
servants we are prohibited under the civil service code of 
conduct bureau from operating a foreign account or running a 
foreign company unless after retirement in this vain we want you 
to front for us as partner to enable us lodge the funds speedily 
into your account. 
 
Bear in mind that no risk is attached to this project and all 
logistics are in place and modalities worked out for the smooth 
conclusion within a stipulated time. This is in accordance with 
the fact that you must never betray the trust already reposed on 
you. We have decided to compensate you with 30% of the total sum 
for your support, 60% for us while 10% for miscellaneous expenses
(local and international).
 
 Please, provide your confidential phone and fax number to enable 
me contact you for further discussion on this matter.  Please advise in your return mail if any time is confidential enough to call you.
   
Looking forward to hearing from you.
Best regards,
Dr.Douglas Akpeki

From: "Dr.Douglas Akpeki" <[email-masked]>
Reply-To: [email-masked]
To: [email-masked]
Subject: [Idr] INVITATION TO PARTNERSHIP
Sender: [email-masked]
Date: Wed, 24 Sep 2003 11:59:36 +0100

Dear Sir,
          REQUEST FOR YOUR UNRESERVED ASSISTANCE.
 This letter may come to you as a surprise but it was borne
out of my sincere desire to share a mutual business relationship 
with you. 
 
 First, your strictest confidence in this transaction is highly 
solicited. This is by virtue of its nature as being utterly
confidential and top secret. I am a top government official with 
a statutory corporation and member of an adhoc committee set up 
by the Federal Government of Nigeria to review contract awarded 
by past administration. In the course of identifying, 
srcutinising and recommending for the payment of all valid 
contract executed, we discovered a huge sum of money amounting to
USD41.5M (Forty One Million five Hundred Thousand US Dollars) on 
grossly over invoiced contract already awarded and exccuted for 
the Nigerian National Petroleum Corporation.
 
 Having cleaned the ‘AUGEAN STABLE‘ we intend to transfer the 
balance of USD41.5M presently floating in our apex bank of 
Nigeria to our own benefit and advantage. However, we request 
for your unwavering assistance in this regard because as civil 
servants we are prohibited under the civil service code of 
conduct bureau from operating a foreign account or running a 
foreign company unless after retirement in this vain we want you 
to front for us as partner to enable us lodge the funds speedily 
into your account. 
 
Bear in mind that no risk is attached to this project and all 
logistics are in place and modalities worked out for the smooth 
conclusion within a stipulated time. This is in accordance with 
the fact that you must never betray the trust already reposed on 
you. We have decided to compensate you with 30% of the total sum 
for your support, 60% for us while 10% for miscellaneous expenses
(local and international).
 
 Please, provide your confidential phone and fax number to enable 
me contact you for further discussion on this matter.  Please advise in your return mail if any time is confidential enough to call you.
   
Looking forward to hearing from you.
Best regards,
Dr.Douglas Akpeki

From: Pekka Savola <[email-masked]>
To: [email-masked]
Subject: [Idr] comments on idr-bgp4-20
Sender: [email-masked]
Date: Wed, 24 Sep 2003 10:50:26 +0300 (EEST)

Hi,

Overview:

substantial
-----------

                                                                                                     
       0                   1                   2                   3

5.1.3 NEXT_HOP

and:

                                                                                                  

                                                                                                
Normative References

Non-normative References

semi-substantial
----------------

   Adj-RIB-In
   Adj-RIBs-In
   Adj-RIB-Out
   Adj-RIBs-Out

   BGP speaker

   BGP speaker

....

      BGP Identifier:

...

      Path Attributes:

	

...

...

                                                                                                     

 

                                                                                                  

...

                                                                                                     

         a)   ORIGIN (Type Code 1):

 

 

==> s/cognizant/aware/

6. BGP Error Handling.

 

==> s/LocRib/Loc-RIB/

 

==> s/case/cases/

From: "Dr Mrs Mariam Abacha" <[email-masked]>
Reply-To: [email-masked]
To: [email-masked]
Subject: [Idr] Respond soonest
Sender: [email-masked]
Date: Tue, 23 Sep 2003 18:30:19 -0700

Attn:Sir/Ma,

 I salute you in the name of Allah,the most
high God.I am Mrs. Mariam Abacha, the widow of the
late General Sani Abacha, former Nigerian Military
head of state who died mysteriously as a result of
Cardiac arrest.Since my husband died, my family has
been under restriction of movement and that not
withstanding, we have been molested and constantly
under watch by the seemingly Agent, above all our bank
accounts here and abroad have been frozen by the
Nigerian civilian Government. Furthermore, my eldest
son is in detention by the Nigerian Government for
more interrogation about my husband assets and some
vital documents.

Following the recent discovery of my husband's bank
account by the Nigerian Government with my son's bank
in which a huge some of US$700 million and Dutch Mark
450 million was lodged and f1.6 billion belonging to
my late husband was seized by the Government of
Nigeria.I therefore wish to personally appeal to you
seriously and religious for your urgent assistance to
transfer the sum of US$25.5 million into your account
in your country where I believe it will be safe, since
we can not leave the country, due to the restriction
of the movement imposed on the members of my family by
the Nigerian Government.You can contact me through my
farmily lawyer's number 234 80333 13642(barister Buba Mohhamed) And he shall arrange with you for
a face-to face meeting outside Nigeria inorder to lease with him toward effective completion ofthis transaction.

However, arrangement have been put
in place to move this money out of the country, in the
secret vault through a security Company to any of West
African States, Europe,America as soon as you indicate
your interest, my Lawyer shall send to you the
Security Deposit Certificate and Airway Bill of the
luggage and other related documents so that you an
claim the luggage, which shall be tagged FAMILY
TREASUERS.

Conclusively, we have agreed to offer you 30% of the
total sum while 70% is to be held on trust by you
until we can decide on a suitable business investment
in your country subsequent to our free movement by the
Nigerian Government.Please, reply urgently and treat
with absolute confidentiality and sincerity.

Yours sincerely,

Mariam Abacha.

N.B.Your reponse will determine the transaction and
please all information guarantee safety.

From: "Kirk Smith" <[email-masked]>
To: [email-masked]
Subject: [Idr] Questions about operation of draft-ietf-idr-route-filter-09.txt
Sender: [email-masked]
Date: Tue, 23 Sep 2003 18:52:19 -0400

This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.

------_=_NextPart_001_01C38225.5819CCB4
Content-Type: text/plain

I have a question about the operation (Section 8) of receiving a route
refresh request containing ORFs.

In particular, the draft states:
"If the When-to-Refresh indicates IMMEDIATE, then after processing all the
ORF entries carried in the message the speaker re-advertises to the peer
routes from the Adj-RIB-Out associated with the peer that have the same
AFI/SAFI as what is carried in the message, and taking into account all the
ORF entries received from the peer. However, the routes that have not be
affected by the ORF entries carried in the message SHOULT NOT be
re-advertised to the peer."

  I take this to mean, that BGP will advertise those routes which match the
ORF entries contained in the UPDATE message being processed (and possibly
any previous marked as DEFER), but not those which were already processed
and advertised to this peer.
For example, say I have 2 BGP speakers, X and Y.
X sends a route refresh message to Y containing ORF value A with IMMEDIATE.
I assume any routes matching A (and the AFI/SAFI) will be sent to X from Y.
Now, say X sends a route refresh message to Y containing ORF value B with
IMMEDIATE.
I assume only those routes matching B will be sent to X from Y.  i.e. the
routes matching ORF A will not be readvertised.
Is my assumption correct?

Thanks,
  Kirk.

------_=_NextPart_001_01C38225.5819CCB4
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2656.31">
<TITLE>Questions about operation of draft-ietf-idr-route-filter-09.txt  =
      </TITLE>
</HEAD>
<BODY>

<P><FONT FACE=3D"Times New Roman">I have a question about the operation =
(Section 8) of receiving a route refresh request containing =
ORFs.</FONT>
</P>

<P><FONT FACE=3D"Times New Roman">In particular, the draft =
states:</FONT>
<BR><FONT FACE=3D"Times New Roman">&quot;If the When-to-Refresh =
indicates IMMEDIATE, then after processing all the ORF entries carried =
in the message the speaker re-advertises to the peer routes from the =
Adj-RIB-Out associated with the peer that have the same AFI/SAFI as =
what is carried in the message, and taking into account all the ORF =
entries received from the peer. However, the routes that have not be =
affected by the ORF entries carried in the message SHOULT NOT be =
re-advertised to the peer.&quot;</FONT></P>

<P><FONT FACE=3D"Times New Roman">&nbsp; I take this to mean, that BGP =
will advertise those routes which match the ORF entries contained in =
the UPDATE message being processed (and possibly any previous marked as =
DEFER), but not those which were already processed and advertised to =
this peer.</FONT></P>

<P><FONT FACE=3D"Times New Roman">For example, say I have 2 BGP =
speakers, X and Y.</FONT>
<BR><FONT FACE=3D"Times New Roman">X sends a route refresh message to Y =
containing ORF value A with IMMEDIATE.</FONT>
<BR><FONT FACE=3D"Times New Roman">I assume any routes matching A (and =
the AFI/SAFI) will be sent to X from Y.</FONT>
<BR><FONT FACE=3D"Times New Roman">Now, say X sends a route refresh =
message to Y containing ORF value B with IMMEDIATE.</FONT>
<BR><FONT FACE=3D"Times New Roman">I assume only those routes matching =
B will be sent to X from Y.&nbsp; i.e. the routes matching ORF A will =
not be readvertised.</FONT></P>

<P><FONT FACE=3D"Times New Roman">Is my assumption correct?</FONT>
</P>

<P><FONT FACE=3D"Times New Roman">Thanks,</FONT>
<BR><FONT FACE=3D"Times New Roman">&nbsp; Kirk.</FONT>
</P>

</BODY>
</HTML>
------_=_NextPart_001_01C38225.5819CCB4--

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: [Idr] I-D ACTION:draft-ietf-idr-bgp-analysis-04.txt
Sender: [email-masked]
Date: Mon, 22 Sep 2003 14:45:21 -0400

--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		: BGP-4 Protocol Analysis
	Author(s)	: D. Meyer, K. Patel
	Filename	: draft-ietf-idr-bgp-analysis-04.txt
	Pages		: 20
	Date		: 2003-9-22
	
The purpose of this report is to document how the requirements for
advancing a routing protocol from Draft Standard to full Standard
have been satisfied by Border Gateway Protocol version 4 (BGP-4).
This report satisfies the requirement for'the second report', as
described in Section 6.0 of RFC 1264 [RFC1264].  In order to fulfill
the requirement, this report augments RFC 1774 [RFC1774] and
summarizes the key features of BGP protocol, and analyzes the
protocol with respect to scaling and performance.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-idr-bgp-analysis-04.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-bgp-analysis-04.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-bgp-analysis-04.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-bgp-analysis-04.txt

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

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

--OtherAccess--

--NextPart--

Subject: Re: [idr] taxonomy of bogon filtering applied to route servers
From: Danny McPherson <[email-masked]>
To: <[email-masked]>
Sender: [email-masked]
Date: Sat, 20 Sep 2003 16:22:53 -0600

It would seem to me that this is more of an implementation/
"feature set" issue than protocol issue.

With that said, I suppose I see some utility, but as discussed
on other lists, it mostly just raises "the lazy bar", IMO.

This message is probably better suited for the GROW mailing list,
though I suspect the feeling there will be similar (then again,
....).

-danny

On Saturday, September 20, 2003, at 01:39 PM, Michel Py wrote:

> idr chairs and folks,
>
> [I apologize in advance is this off-topic for this list]
>
> I was recently looking at the issue of bogon route-servers, and it
> struck me that there would be little work to adapt BGP Prefix-Based
> Outbound Route Filtering (ORF) to change it into what is desperately
> needed for bogons.
>
> In a nutshell, the way I understand ORF is that the sending router  
> sends
> the receiving router a prefix-list (or distribute-list, or as-path
> list). When the receiving router receives the prefix-list, it applies  
> it
> outbound towards the peer it received it from.
>
> The enhancement that would be needed would be to make the receiving
> router capable of applying the received prefix-list to other peers,
> especially inbound. This would likely involve naming the received ORF
> and making it available to other peers.
>
> In other words, my idea is to use the ORF mechanism to propagate
> prefix-lists to other peers, not for the purpose of filtering the  
> routes
> sent to a peer and their associated handling but for the purpose of
> filtering inbound routes coming from other peers of the receiving ORF
> router. I was wondering what this WG thinks about it.
>
> I wrote a little taxonomy about IPv6 bogon filtering; this is very,  
> very
> crude and I welcome your comments.
>
> Best,
> Michel.
>
>
> Taxonomy of bogon filtering.
> ============================
>
> There are five basic ways to handle the bogon filtering issue:
>
> 1. Manually configured prefix-lists.
> 2. BGP feed of "bad" prefix aggregates.
> 3. BGP feed of anomalies.
> 4. BGP feed of "good" prefixes.
> 5. Derivative of BGP Prefix-Based Outbound Route Filtering (ORF).
>
>
> 1. Manually configured prefix-lists.
> ------------------------------------
>
> This involves one or more volunteers to maintain a prefix-list that is
> to be configured manually on routers. The issue with this is change
> management: as we have seen with the 69/8 fiasco not that long ago,  
> some
> people do _not_ update their filters regularly, and when the bogon
> prefix-list is modified it can take weeks to be upgraded, which is not
> good. However, in terms of granularity, this is what gives the finest
> control.
>
>
> 2. BGP feed of "bad" prefix aggregates.
> ---------------------------------------
>
> This is the mechanism currently used by team cymru's bogon route  
> servers
> (http://www.cymru.com/BGP/bogon-rs.html). The issue with this is that
> the domain of applicability is limited to networks that do not receive  
> a
> full feed. If one gets a full feed, this method does not prevent bad
> prefixes if they are smaller than the bogon feed, because of the  
> longest
> match rule. So, this is an option only for networks with private  
> peering
> only and a default route outside, because a blackhole route is  
> installed
> to dump all the bogon traffic instead of sending it to the default
> route.
>
>
> 3. BGP feed of anomalies.
> A finer version of the previous one. Real-time monitoring of the  
> routing
> table at different points allows to build a list of bad announcements.
> Contrary to the previous option, this allows to deal with specific
> announcements. The issue with this is that it does not prevent the bad
> announcement to be received, it actually adds another path that will be
> made preferred to the offending announcement and used to dump the
> traffic in a blackhole. Compared to the feeding of bad aggregates, this
> method extends the domain of applicability to defaultless networks, at
> the expense of aggravating the routing table size issue.
>
>
> 4. BGP feed of "good" prefixes.
> -------------------------------
>
> This is an IPv6-only topic that was discussed outside of idr. Please
> don't pay attention to it in this context.
>
>
> 5. Derivative of BGP Prefix-Based Outbound Route Filtering (ORF).
> -----------------------------------------------------------------
>
> http://www.ietf.org/internet-drafts/draft-chen-bgp-prefix-orf-06.txt
> http://www.ietf.org/internet-drafts/draft-ietf-idr-route-filter-09.txt
> http://www.cisco.com/en/US/products/sw/iosswrel/ps1838/ 
> products_feature_
> guide09186a0080134a57.html
>
> Unfortunately the actual capabilities of this are that the filter-list
> received from the peer is applied only outbound to the same peer. This
> is a very promising technique for bogon route servers, but we need to
> enhance it.
>
> Please send comments.
>
> Michel.
>
>

Subject: [idr] taxonomy of bogon filtering applied to route servers
Content-class: urn:content-classes:message
From: "Michel Py" <[email-masked]>
To: <[email-masked]>
Sender: [email-masked]
Date: Sat, 20 Sep 2003 12:39:09 -0700

idr chairs and folks,

[I apologize in advance is this off-topic for this list]

I was recently looking at the issue of bogon route-servers, and it
struck me that there would be little work to adapt BGP Prefix-Based
Outbound Route Filtering (ORF) to change it into what is desperately
needed for bogons.

In a nutshell, the way I understand ORF is that the sending router sends
the receiving router a prefix-list (or distribute-list, or as-path
list). When the receiving router receives the prefix-list, it applies it
outbound towards the peer it received it from.

The enhancement that would be needed would be to make the receiving
router capable of applying the received prefix-list to other peers,
especially inbound. This would likely involve naming the received ORF
and making it available to other peers.

In other words, my idea is to use the ORF mechanism to propagate
prefix-lists to other peers, not for the purpose of filtering the routes
sent to a peer and their associated handling but for the purpose of
filtering inbound routes coming from other peers of the receiving ORF
router. I was wondering what this WG thinks about it.

I wrote a little taxonomy about IPv6 bogon filtering; this is very, very
crude and I welcome your comments.

Best,
Michel.

Taxonomy of bogon filtering.
============================

There are five basic ways to handle the bogon filtering issue:

1. Manually configured prefix-lists.
2. BGP feed of "bad" prefix aggregates.
3. BGP feed of anomalies.
4. BGP feed of "good" prefixes.
5. Derivative of BGP Prefix-Based Outbound Route Filtering (ORF).

1. Manually configured prefix-lists.
------------------------------------

This involves one or more volunteers to maintain a prefix-list that is
to be configured manually on routers. The issue with this is change
management: as we have seen with the 69/8 fiasco not that long ago, some
people do _not_ update their filters regularly, and when the bogon
prefix-list is modified it can take weeks to be upgraded, which is not
good. However, in terms of granularity, this is what gives the finest
control.

2. BGP feed of "bad" prefix aggregates.
---------------------------------------

This is the mechanism currently used by team cymru's bogon route servers
(http://www.cymru.com/BGP/bogon-rs.html). The issue with this is that
the domain of applicability is limited to networks that do not receive a
full feed. If one gets a full feed, this method does not prevent bad
prefixes if they are smaller than the bogon feed, because of the longest
match rule. So, this is an option only for networks with private peering
only and a default route outside, because a blackhole route is installed
to dump all the bogon traffic instead of sending it to the default
route.

3. BGP feed of anomalies.
-------------------------

A finer version of the previous one. Real-time monitoring of the routing
table at different points allows to build a list of bad announcements.
Contrary to the previous option, this allows to deal with specific
announcements. The issue with this is that it does not prevent the bad
announcement to be received, it actually adds another path that will be
made preferred to the offending announcement and used to dump the
traffic in a blackhole. Compared to the feeding of bad aggregates, this
method extends the domain of applicability to defaultless networks, at
the expense of aggravating the routing table size issue.

4. BGP feed of "good" prefixes.
-------------------------------

This is an IPv6-only topic that was discussed outside of idr. Please
don't pay attention to it in this context.

5. Derivative of BGP Prefix-Based Outbound Route Filtering (ORF).
-----------------------------------------------------------------

http://www.ietf.org/internet-drafts/draft-chen-bgp-prefix-orf-06.txt
http://www.ietf.org/internet-drafts/draft-ietf-idr-route-filter-09.txt
http://www.cisco.com/en/US/products/sw/iosswrel/ps1838/products_feature_
guide09186a0080134a57.html

Unfortunately the actual capabilities of this are that the filter-list
received from the peer is applied only outbound to the same peer. This
is a very promising technique for bogon route servers, but we need to
enhance it.

Please send comments.

Michel.

From: "DR.FRANK EFE" <[email-masked]>
Reply-To: [email-masked]
To: [email-masked]
Subject: [Idr] PARTNER  NEEDED
Sender: [email-masked]
Date: Fri, 19 Sep 2003 11:25:23 -0700

                             CONFIDENTIAL

25 Adewabe Street,
Ikoyi Island,
Lagos.

                                                IFax:1775-522-8610

                                                   18/9/2003

ATTN:THE PRESIDENT/CEO

FROM:DR.FRANK EFE.

Dear Sir,

I would like to firstly send to you the best wishes of good health and success in your pursuits particularly through my proposal as contained in this letter.

Before going into details of my proposal to you, I must first implore you to treat with the utmost confidentiality as this is required for its success and to have faith in this transaction,for opportunities like this only comes to one once in a life time.

My colleagues and I are senior officials of the Federal Government of my country's Contracts Review Panel (CRP) who are interested in diverting some funds that are presently loating in the accounts of the Apex Bank of my country.In order to commence this transaction, we solicit for your assistance to enable us transfer into your nominated account the said floating funds. We are determined to conclude the transfer before the end of this quarter of 2003. The source of the funds are as follows: During the last military regime in my country,government officials set up companies and awarded themselves contracts that were grossly over-invoiced in various ministries and parastatals.The present civilian government set up the Contract Review Panel, which has the mandate to use the instruments of payments made available to it by the decree setting up the panel, to review these contracts and if necessary pay those who are being owed outstanding amounts.

My colleagues and I have identified quite a huge sum of
these funds which are presently floating in our (Apex)Central Bank ready for disbursement and would like to divert some of it for our own purposes. However, by virtue of our positions as civil servants and members of this panel, we cannot acquire these funds in our names or in the names of companies that are based in my country. I have therefore been mandated,as a matter of trust by my colleagues in the panel, to look for a reliable overseas partner into whose account we can transfer the sum of U.S.$20,500,000.00 (Twenty million, five hundred thousand U.S. dollars).That is why I am seeking your assistance. We have agreed to share the money to be transferred into your account, if you agree with our proposition as follows;
(i)25% to the account owner(you).
(ii)65% for us (the panel officials).
(iii)10% to be used in settling all expenses (by both you and us) incidental to the actualization of this project.

We wish to invest our share of the proceeds of this project in foreign stock markets and other viable business till we are ready and able to have access to them without raising any eyebrows here at home. Please note that this
transaction is 100% safe and risk-free.
We intend to effect the transfer within fourteen (14)banking days from the date of receipt of the following information through the ifax number stated above:Your company's
name,address,telephone and fax numbers we will use your company's name to apply for the payment and backdate the award of the contract in favour of your company. We are looking forward to doing this transaction with you and we solicit for your utmost confidentiality in this transaction.

I will bring you into a more detailed picture of this transaction when I hear from you.Please get in touch through my IFAX # 177-552-286-10.

Best regards,

DR.FRANK EFE.

To: [email-masked]
Cc: [email-masked]
Reply-To: [email-masked]
Subject: some comments on draft-ietf-idr-bgp4-experience-protocol-02.txt
Date: Wed, 17 Sep 2003 10:38:08 -0400
From: Curtis Villamizar <[email-masked]>
Sender: [email-masked]

ref:
	Title		: Experience with the BGP-4 Protocol
	Author(s)	: D. McPherson, K. Patel
	Filename	: draft-ietf-idr-bgp4-experience-protocol-02.txt

Danny,

This looks to be in good shape.  If you do another version of the
draft here are some suggestions.

None of this is essential to the draft but it might be helpful.

Curtis

In the MED section you might want to describe the common "hot potatoe
/ cold potatoe" usage.  Here is some suggested text.

   In a situation where traffic flows between a pair of destinations,
   each connected to two transit networks, each of the transit
   networks has the choice of either sending the traffic to the
   closest peering to other transit provider or passing traffic to the
   peering which advertises the least cost through the other provider.
   The former method is called "hot potatoe routing" because like a
   hot potatoe held in bare hands, whoever has it tries to get rid of
   it quickly.  Hot potatoe routing is accomplished by not passing the
   EGBP learned MED into IBGP.  This minimizes transit traffic for the
   provider routing the traffic.  Far less common is "cold potatoe
   routing" where the transit provider uses their own transit capacity
   to get the traffic to the point in the adjacent transit provider
   advertised as being closest to the destination.  Cold potatoe
   routing is accomplished by passing the EBGP learned MED into IBGP.

   If one transit provider uses hot potatoe routing and another uses
   cold potatoe, traffic between the two tends to be symetric.
   Depending on the business relationships, if one provider has more
   capacity or a significantly less congested transit network, then
   that provider may use cold potatoe routing.  An example of
   widespread use of cold potatoe routing was the NSF funded NSFNET
   backbone and NSF funded regional networks in the mid 1990s.

   In some cases a provider may use hot potatoe routing for some
   destinations for a given peer AS and cold potatoe routing for
   others.  An example of this is the different treatment of
   commercial and research traffic in the NSFNET in the mid 1990s.

Optionally add to the last paragraph "This might best be described as
'mashed potatoe routing' a term which reflects the complexity of
router configurations in use at the time".  :-)

Under "Internet Dynamics" I would prefer if you would add:

   None of the current implementations of BGP Route Flap Damping store
   route history by unique NRLI and AS Path although it is listed as
   manditory in RFC 2439.  A potential result of failure to consider
   each AS Path separately is an overly aggressive suppression of
   destinations in a densely meshed network, with the most severe
   consequence being suppression of a destination after a single
   failure.  Because the top tier AS in the Internet are densely
   meshed, these adverse consequences are observed.

After "Limit Rate Updates" you might add a section:

   13 1/2.  Consideration of TCP Characteristics

   If a TCP receiver is processing input more slowly than the sender
   or if the TCP connection rate is the limiting factor, a form of
   backpressure is observed by the TCP sending application.  When the
   TCP buffer fills, the sending application will either block on the
   write or receive an error on the write.  Common errors in either
   early implementations or an occasional naive new implementation
   are to either set options to block on the write or set options for
   non-blocking writes and then treat the errors due to a full buffer
   as fatal.

   Having recognized that full write buffers are to be expected
   additional implementation pitfalls exist.  The application should
   not attempt to store the TCP stream within the application itself.
   If the receiver or the TCP connection is persistently slow, then
   the buffer can grow until memory is exhausted.  A BGP
   implementation must send changes to all peers for which the TCP
   connection is not blocked and must remember to send those changes
   to the remaining peers when the connection becomes unblocked.

   If the preferred route for a given NLRI changes multiple times
   while writes to one or more peer is blocked, only the most recent
   best route needs to be sent.  In this way BGP is work conserving.
   In times of extremely high route change, a higher volume of route
   change is sent to those peers which are able to process it more
   quickly and a lower volume of route change is sent to those peers
   not able to process the changes as quickly.

   For implentations which handle differing peer capacity to absorb
   route change well, if the majority of route change is contributed
   by a subset of unstable NRLI, the only impact on relatively stable
   NRLI which make an isolated route change is a slower convergence
   for which convergence time remains bounded regardless of the amount
   of instability.

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-To: [email-masked]
Subject: I-D ACTION:draft-ietf-idr-bgp4-experience-protocol-02.txt
Date: Tue, 16 Sep 2003 14:53:22 -0400
Sender: [email-masked]

--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		: Experience with the BGP-4 Protocol
	Author(s)	: D. McPherson, K. Patel
	Filename	: draft-ietf-idr-bgp4-experience-protocol-02.txt
	Pages		: 20
	Date		: 2003-9-16
	
The purpose of this memo is to document how the requirements for
advancing a routing protocol from Draft Standard to full Standard
have been satisfied by Border Gateway Protocol version 4 (BGP-4).
This report satisfies the requirement for 'the second report', as
described in Section 6.0 of RFC 1264.  In order to fulfill the
requirement, this report augments RFC 1773 and describes additional
knowledge and understanding gained in the time between when the
protocol was made a Draft Standard and when it was submitted for
Standard.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-idr-bgp4-experience-protocol-02.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-experience-protocol-02.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-experience-protocol-02.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-experience-protocol-02.txt

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

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

--OtherAccess--

--NextPart--

From: Danny McPherson <[email-masked]>
To: [email-masked]
Subject: [Idr] Fwd: I-D ACTION:draft-ietf-idr-bgp4-experience-protocol-02.txt
Sender: [email-masked]
Date: Tue, 16 Sep 2003 13:05:03 -0600

Note that all comments received to date (within the WG LC window
that ends today) have been incorporated into this version of the
draft.

-danny

Begin forwarded message:

> From: [email-masked]
> Date: Tue Sep 16, 2003  12:53:22 PM America/Denver
> To: IETF-Announce: ;
> Cc: [email-masked]
> Subject: I-D ACTION:draft-ietf-idr-bgp4-experience-protocol-02.txt
> Reply-To: [email-masked]
>
> 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		: Experience with the BGP-4 Protocol
> 	Author(s)	: D. McPherson, K. Patel
> 	Filename	: draft-ietf-idr-bgp4-experience-protocol-02.txt
> 	Pages		: 20
> 	Date		: 2003-9-16
> 	
> The purpose of this memo is to document how the requirements for
> advancing a routing protocol from Draft Standard to full Standard
> have been satisfied by Border Gateway Protocol version 4 (BGP-4).
> This report satisfies the requirement for 'the second report', as
> described in Section 6.0 of RFC 1264.  In order to fulfill the
> requirement, this report augments RFC 1773 and describes additional
> knowledge and understanding gained in the time between when the
> protocol was made a Draft Standard and when it was submitted for
> Standard.
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-idr-bgp4-experience- 
> protocol-02.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-experience-protocol-02.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-experience-protocol-02.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.
> Content-Type: text/plain
> Content-ID:	<[email-masked]>

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-To: [email-masked]
Subject: I-D ACTION:draft-ietf-idr-bgp4-experience-protocol-02.txt
Date: Tue, 16 Sep 2003 14:53:22 -0400
Sender: [email-masked]

--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		: Experience with the BGP-4 Protocol
	Author(s)	: D. McPherson, K. Patel
	Filename	: draft-ietf-idr-bgp4-experience-protocol-02.txt
	Pages		: 20
	Date		: 2003-9-16
	
The purpose of this memo is to document how the requirements for
advancing a routing protocol from Draft Standard to full Standard
have been satisfied by Border Gateway Protocol version 4 (BGP-4).
This report satisfies the requirement for 'the second report', as
described in Section 6.0 of RFC 1264.  In order to fulfill the
requirement, this report augments RFC 1773 and describes additional
knowledge and understanding gained in the time between when the
protocol was made a Draft Standard and when it was submitted for
Standard.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-idr-bgp4-experience-protocol-02.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-experience-protocol-02.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-experience-protocol-02.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-experience-protocol-02.txt

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

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

--OtherAccess--

--NextPart--

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-To: [email-masked]
Subject: I-D ACTION:draft-ietf-idr-cease-subcode-04.txt
Date: Tue, 16 Sep 2003 10:20:08 -0400
Sender: [email-masked]

--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		: Subcodes for BGP Cease Notification Message
	Author(s)	: E. Chen, V. Gillet
	Filename	: draft-ietf-idr-cease-subcode-04.txt
	Pages		: 4
	Date		: 2003-9-16
	
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-ietf-idr-cease-subcode-04.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-cease-subcode-04.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-cease-subcode-04.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-cease-subcode-04.txt

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

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

--OtherAccess--

--NextPart--

To: Andrew Lange <[email-masked]>
Cc: [email-masked], [email-masked], "Don Goodspeed" <[email-masked]>, [email-masked]
Subject: Re: Cease Subcode Draft - Suggestion 
Date: Thu, 11 Sep 2003 18:02:57 -0700
From: Enke Chen <[email-masked]>
Sender: [email-masked]

Hi, Andrew and Don:

> Message-ID: <[email-masked]>
> Date: Thu, 11 Sep 2003 15:01:02 -0700
> From: Andrew Lange <[email-masked]>
> Organization: Alcatel USA
> To: [email-masked], [email-masked], [email-masked]
> Cc: "Don Goodspeed" <[email-masked]>
> Subject: Cease Subcode Draft - Suggestion
> 
> Hello,
> 
> Don Goodspeed pointed out a couple of error conditions that would be 
> useful to add to the cease subcodes draft.  We worked up some proposed 
> text to add to draft-ietf-idr-cease-subcode-03.txt:
> 
> 4. Subcode Definition
> 
>     Subcode	Symbolic Name
>        0		Other Condition

I do not think this is necessary as the BGP spec has already defined
Subcode 0 for "Unspecific". See the following text from the latest draft:

----------------------------------
4.5 NOTIFICATION Message Format

      Error subcode:

         This 1-octet unsigned integer provides more specific informa-
         tion about the nature of the reported error.  Each Error Code
         may have one or more Error Subcodes associated with it. If no
         appropriate Error Subcode is defined, then a zero (Unspecific)
         value is used for the Error Subcode field.
----------------------------------

>       ...        ...
>        8         Out of Resources

Assuming the message can still be sent :-)

I would like to hear some comments on this one.

-- Enke

> 
> 5. Subcode Usage
> 
>      If a BGP speaker decides to shutdown the session for a reason that
>      is not covered in the other subcodes defined in this document, then
>      the speaker should send a NOTIFICATION message with the Error Code
>      Cease, and the Error Subcode "Other Condition".
> 
>      If a BGP speaker decides to shut down a session because it is out of
>      resources, such as memory, then the speaker should send a
>      NOTIFICATION message with the Error Code Cease, and the Error
>      Subcode "Out of Resources".
> 
>      ...
> 
>      It is recommended that a BGP speaker implement a backoff mechanism
>      in re-trying a BGP connection after the speaker receives a Cease
>      NOPTIFICATION message with the subcode of ... "Out of Resources".
> 
> 
> Andrew
> 

Date: Thu, 11 Sep 2003 15:01:02 -0700
From: Andrew Lange <[email-masked]>
Organization: Alcatel USA
To: [email-masked], [email-masked], [email-masked]
Cc: "Don Goodspeed" <[email-masked]>
Subject: Cease Subcode Draft - Suggestion
Sender: [email-masked]

Hello,

Don Goodspeed pointed out a couple of error conditions that would be 
useful to add to the cease subcodes draft.  We worked up some proposed 
text to add to draft-ietf-idr-cease-subcode-03.txt:

4. Subcode Definition

    Subcode	Symbolic Name
       0		Other Condition
      ...        ...
       8         Out of Resources

5. Subcode Usage

     If a BGP speaker decides to shutdown the session for a reason that
     is not covered in the other subcodes defined in this document, then
     the speaker should send a NOTIFICATION message with the Error Code
     Cease, and the Error Subcode "Other Condition".

     If a BGP speaker decides to shut down a session because it is out of
     resources, such as memory, then the speaker should send a
     NOTIFICATION message with the Error Code Cease, and the Error
     Subcode "Out of Resources".

     ...

     It is recommended that a BGP speaker implement a backoff mechanism
     in re-trying a BGP connection after the speaker receives a Cease
     NOPTIFICATION message with the subcode of ... "Out of Resources".

Andrew

From: "C. M. Heard" <[email-masked]>
To: Jeffrey Haas <[email-masked]>
cc: "Wijnen, Bert (Bert)" <[email-masked]>, IDR WG <[email-masked]>
Subject: [Idr] Re: I-D ACTION:draft-ietf-idr-bgp4-mib-12.txt
Sender: [email-masked]
Date: Wed, 10 Sep 2003 08:32:24 -0700 (PDT)

[ list address changed to <[email-masked]>. plz update charter page. ]

On Wed, 10 Sep 2003, Jeffrey Haas wrote:
> On Wed, Sep 10, 2003 at 09:14:46AM +0200, Wijnen, Bert (Bert) wrote:
> > Thanks for the (partial) review Mike.
> > I am sure it will be helpfull... I have not read it in detail
> > yet... hope to do so later this week.
> > 
> > I assume author and WG will respond with fixes and or 
> > answers.
> 
> I accept all of the suggested changes unless there is further feedback
> from the WG.  Meanwhile, I'll hold off issuing another version of
> the draft pending your review.

Allow me to add some clarifications regarding this:

> (b) The smidiff report indicates that several objects that RFC 1657
> declared as 'obsolete' have been promoted to a status of
> 'deprecated', in violation of SMIv2 revision rules:
> 
> BGP4-MIB.my:480 [2] {status-change} status change from `obsolete' to
> `deprecated' for `bgpRcvdPathAttrTable'
> BGP4-MIB.my:491 [2] {status-change} status change from `obsolete' to
> `deprecated' for `bgpPathAttrEntry'
> BGP4-MIB.my:516 [2] {status-change} status change from `obsolete' to
> `deprecated' for `bgpPathAttrPeer'
> BGP4-MIB.my:525 [2] {status-change} status change from `obsolete' to
> `deprecated' for `bgpPathAttrDestNetwork'
> BGP4-MIB.my:532 [2] {status-change} status change from `obsolete' to
> `deprecated' for `bgpPathAttrOrigin'
> BGP4-MIB.my:547 [2] {status-change} status change from `obsolete' to
> `deprecated' for `bgpPathAttrASPath'
> BGP4-MIB.my:563 [2] {status-change} status change from `obsolete' to
> `deprecated' for `bgpPathAttrNextHop'
> BGP4-MIB.my:572 [2] {status-change} status change from `obsolete' to
> `deprecated' for `bgpPathAttrInterASMetric'
> BGP4-MIB.my:803 [2] {status-change} status change from `deprecated'
> to `current' for `bgpEstablished'
> BGP4-MIB.my:812 [2] {status-change} status change from `deprecated'
> to `current' for `bgpBackwardTransition'
> 
> Unless the WG had a specific reason for making this change, I would
> be inclined to recommend that the status of these definitions be
> changed back to 'obsolete'.

- First, the status-change messages for bgpEstablished and
bgpBackwardTransition are wrong (the change was from current
to deprecated) and should be ignored.  I will file a bug report
with the smidiff maintainers.

- Second, the group bgp4MIBRcvdPathAttrGroup, which contains all of
the accessible columns in the bgpRcvdPathAttrTable, has a status of
'deprecated'.  That is legal, even though the contained objects
themselves have a status of 'obsolete', but the WG may prefer for
bgp4MIBRcvdPathAttrGroup have a status of 'obsolete'.  If its status
is changed be sure to update the DESCRIPTION clause to match.

Thanks,

Mike Heard

Date: Wed, 10 Sep 2003 09:04:13 -0400
From: Jeffrey Haas <[email-masked]>
To: "Wijnen, Bert (Bert)" <[email-masked]>
Cc: "C. M. Heard" <[email-masked]>, IDR WG <[email-masked]>
Subject: Re: I-D ACTION:draft-ietf-idr-bgp4-mib-12.txt
Sender: [email-masked]

On Wed, Sep 10, 2003 at 09:14:46AM +0200, Wijnen, Bert (Bert) wrote:
> Thanks for the (partial) review Mike.
> I am sure it will be helpfull... I have not read it in detail
> yet... hope to do so later this week.
> 
> I assume author and WG will respond with fixes and or 
> answers.

I accept all of the suggested changes unless there is further feedback
from the WG.  Meanwhile, I'll hold off issuing another version of
the draft pending your review.

-- 
Jeff Haas 
NextHop Technologies

From: =?iso-8859-1?q?John=20Smith?= <[email-masked]>
To: [email-masked]
Subject: [Idr] Slides
Sender: [email-masked]
Date: Wed, 10 Sep 2003 13:00:26 +0100 (BST)

Hi,
Can we concerned authorities please upload the slides and the meeting minutes on the ietf
web page for the 57th meeting.

John

________________________________________________________________________
Want to chat instantly with your online friends?  Get the FREE Yahoo!
Messenger http://mail.messenger.yahoo.co.uk

From: "C. M. Heard" <[email-masked]>
To: Jeffrey Haas <[email-masked]>
cc: IDR WG <[email-masked]>, "Wijnen, Bert (Bert)" <[email-masked]>
ReSent-Date: Tue, 9 Sep 2003 07:58:01 -0700 (PDT)
ReSent-From: "C. M. Heard" <[email-masked]>
ReSent-To: [email-masked]
ReSent-Subject: Re: I-D ACTION:draft-ietf-idr-bgp4-mib-12.txt
ReSent-Message-ID: <[email-masked]>
Subject: [Idr] Re: I-D ACTION:draft-ietf-idr-bgp4-mib-12.txt
Sender: [email-masked]
Date: Mon, 8 Sep 2003 12:11:57 -0700 (PDT)
Resent-Date: Tue, 09 Sep 2003 10:59:01 -0400

Greetings,

I noticed the I-D announcement and would like to make a few MIB
doctor comments on this draft (but please note that this is the
result of a spot check ... I have NOT done a full MIB doctor review
of this document).

1.) My understanding from reading the draft and from previous e-mail
messages is that this document is supposed to obsolete RFCs 1657 and
1269.  If that understanding is correct, an explicit statement to
that effect, such as

   This memo obsoletes RFC 1657 and RFC 1269.

must be added both to the Abstract and to the Introduction.

2.) I also understand from reading the draft and from previous
e-mail messages that the main purpose of this document is to provide
a clean MIB module that documents the behaviour of deployed
implementations, and that a new MIB module to overcome numerous
shortcomings is under development and will in due course be
submitted for standards-track consideration.  Under the
circumstances it may be appropriate to submit this document as an
Informational RFC rather than for the standards track, as indicated
in the WG last call:  if a replacement is under development, there
is no reason to progress this document along the standards track,
and submitting it for Proposed Standard implies such an intent.

3.) In reviewing the smidiff report between the MIB module in this
draft and the one in RFC 1657 I noticed a couple of questionable
things:

(a) There are no REVISION/DESCRIPTION pairs for the previous
incarnations of the MIB module.  This gives rise to the following
error message:

RFC1657-MIB.my:25 [3] {revision-removed} revision `1994-05-05 00:00'
removed

This can be easily fixed by the following change to the MIB module
at the end of the REVISION/DESCRIPTION pair now present:

OLD:
                          bgpPeerInTotalMessages, bgpPeerOutTotalMessages"

NEW:
                          bgpPeerInTotalMessages, bgpPeerOutTotalMessages.

                      Published as RFC yyyy."
-- RFC Ed.: replace yyyy with actual RFC number & remove this note

            REVISION "199405050000Z"
            DESCRIPTION
                    "Translated to SMIv2 and published as RFC 1657."

            REVISION "199110261839Z"
            DESCRIPTION
                    "Initial version, published as RFC 1269."

Note that "199405050000Z is copied from the LAST-UPDATED clause in
the MIB module in RFC 1657, which is standard practice.  Since that
MIB module did not contain a REVISION/DESCRIPTION pair for the RFC
1269 version, and since RFC 1269 was an SMIv1 module and so has no
LAST-UPDATED or REVISION clause, the date "199110261839Z" is
synthesized from the UTC time stamp Oct 26 18:39:09 1991 on
http://www.rfc-editor.org/rfc/rfc1269.txt

In my opinion, this is a "must-do" change.

(b) The smidiff report indicates that several objects that RFC 1657
declared as 'obsolete' have been promoted to a status of
'deprecated', in violation of SMIv2 revision rules:

BGP4-MIB.my:480 [2] {status-change} status change from `obsolete' to
`deprecated' for `bgpRcvdPathAttrTable'
BGP4-MIB.my:491 [2] {status-change} status change from `obsolete' to
`deprecated' for `bgpPathAttrEntry'
BGP4-MIB.my:516 [2] {status-change} status change from `obsolete' to
`deprecated' for `bgpPathAttrPeer'
BGP4-MIB.my:525 [2] {status-change} status change from `obsolete' to
`deprecated' for `bgpPathAttrDestNetwork'
BGP4-MIB.my:532 [2] {status-change} status change from `obsolete' to
`deprecated' for `bgpPathAttrOrigin'
BGP4-MIB.my:547 [2] {status-change} status change from `obsolete' to
`deprecated' for `bgpPathAttrASPath'
BGP4-MIB.my:563 [2] {status-change} status change from `obsolete' to
`deprecated' for `bgpPathAttrNextHop'
BGP4-MIB.my:572 [2] {status-change} status change from `obsolete' to
`deprecated' for `bgpPathAttrInterASMetric'
BGP4-MIB.my:803 [2] {status-change} status change from `deprecated'
to `current' for `bgpEstablished'
BGP4-MIB.my:812 [2] {status-change} status change from `deprecated'
to `current' for `bgpBackwardTransition'

Unless the WG had a specific reason for making this change, I would
be inclined to recommend that the status of these definitions be
changed back to 'obsolete'.

4.) In the DESCRIPTION clause of bgp4MIBNotificationGroup there is
a typo.  Here is the fix:

OLD:
                 Obsoletes bgp4MIBNotificationGroup."
NEW:
                 Obsoletes bgp4MIBTrapGroup."

In my opinion, this is also another "must-do" change.

Regards,

Mike Heard

Subject: Re: [Idr] graceful restart vs flap dampening
From: Danny McPherson <[email-masked]>
To: IDR mailing list <[email-masked]>
Sender: [email-masked]
Date: Mon, 8 Sep 2003 22:36:52 -0600

On Monday, September 8, 2003, at 04:00 PM, Kaarthik Sivakumar wrote:

> I am interested in how route flap dampening would interact with
> graceful restart. Should stale routes be considered flapping and the
> figure of merit appropriately increased? Should this be done when the
> peer goes down or when the peer comes back up and doesnt readvertise
> one of the stale routes,

Only the latter (as usual), IMO.  Else you scope the usefulness
of graceful restart.

> thus forcing the route to be withdrawn from
> the listening speaker's forwarding? The graceful restart draft doesnt
> refer to this interaction.

I don't believe it should, as the functionality is clearly
orthogonal.

> In my view, the figure of merit for the route should only be affected
> when the restarting speaker comes up and doesnt readvertise the stale
> route. Maybe this is clear from the draft and the route flap dampening
> rfc and I just missed it. If so, let me know what I am missing.
> Otherwise I would suggest some text in the graceful restart draft
> about this interaction.

I don't believe you're missing anything, this is implied
behavior.

-danny

To: IDR mailing list <[email-masked]>
From: Kaarthik Sivakumar <[email-masked]>
Subject: [Idr] graceful restart vs flap dampening
Sender: [email-masked]
Date: Mon, 08 Sep 2003 18:00:43 -0400

I am interested in how route flap dampening would interact with
graceful restart. Should stale routes be considered flapping and the
figure of merit appropriately increased? Should this be done when the
peer goes down or when the peer comes back up and doesnt readvertise
one of the stale routes, thus forcing the route to be withdrawn from
the listening speaker's forwarding? The graceful restart draft doesnt
refer to this interaction.

In my view, the figure of merit for the route should only be affected
when the restarting speaker comes up and doesnt readvertise the stale
route. Maybe this is clear from the draft and the route flap dampening
rfc and I just missed it. If so, let me know what I am missing.
Otherwise I would suggest some text in the graceful restart draft
about this interaction.

Thanks..

kaarthik

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-To: [email-masked]
Subject: I-D ACTION:draft-ietf-idr-bgp4-mib-12.txt
Date: Mon, 08 Sep 2003 06:52:48 -0400
Sender: [email-masked]

--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		: Definitions of Managed Objects for the Fourth Version 
                          of Border Gateway Protocol (BGP-4)
	Author(s)	: J. Haas, S. Hares
	Filename	: draft-ietf-idr-bgp4-mib-12.txt
	Pages		: 35
	Date		: 2003-9-5
	
This memo is an extension to the SNMP MIB.  The origin of this memo
is from RFC 1269 'Definitions of Managed Objects for the Border
Gateway Protocol (Version 3)', which was updated to support BGP-4 in
RFC 1657.  This memo fixes errors introduced when the MIB was
converted to use the SNMPv2 SMI, as well as updates references to the
current SNMP framework documents.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-idr-bgp4-mib-12.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-mib-12.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-mib-12.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-mib-12.txt

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

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

--OtherAccess--

--NextPart--

Date: Thu, 4 Sep 2003 09:58:48 -0600
Subject: Re: Last Call on draft-ietf-idr-bgp4-experience-protocol-01.txt 
From: Danny McPherson <[email-masked]>
To: [email-masked]
Sender: [email-masked]

>
> The value of X varies with implementation but there is always some
> practical limit.  You could put a sentence in stating that.

OK, I'll add something to that effect..

-danny

To: Danny McPherson <[email-masked]>
Cc: Erblichs <[email-masked]>, [email-masked]
Reply-To: [email-masked]
Subject: Re: Last Call on draft-ietf-idr-bgp4-experience-protocol-01.txt 
Date: Thu, 04 Sep 2003 11:48:39 -0400
From: Curtis Villamizar <[email-masked]>
Sender: [email-masked]

In message <[email-masked]>, Danny McPherson writ
es:
> 
> > 	  6) 8. Internal BGP in Large ...
> >
> > 		"with a large number of peers"
> >
> > 		Should this be specified? with the number of peers
> > 		  			  greater than "X"
> 
> I'm not sure X can be defined, as it's relative.  I think it's
> probably OK as is.

The value of X varies with implementation but there is always some
practical limit.  You could put a sentence in stating that.

Curtis

Date: Thu, 4 Sep 2003 09:31:13 -0600
Subject: Re: Last Call on draft-ietf-idr-bgp4-experience-protocol-01.txt
Cc: [email-masked]
To: Erblichs <[email-masked]>
From: Danny McPherson <[email-masked]>
Sender: [email-masked]

On Wednesday, September 3, 2003, at 03:57 PM, Erblichs wrote:

1-5: fixed!

> 	  6) 8. Internal BGP in Large ...
>
> 		"with a large number of peers"
>
> 		Should this be specified? with the number of peers
> 		  			  greater than "X"

I'm not sure X can be defined, as it's relative.  I think it's
probably OK as is.

>
> 		RFC 2065 not in References

Should have been 3065.

7-12: fixed!

> 	------------------
> 	B) Non-nits

1-4:  Added some text to address each of these, it should be
sufficient.

Great feedback, thanks!

-danny

To: [email-masked]
Subject: Last Call on draft-ietf-idr-bgp4-experience-protocol-01.txt 
Date: Tue, 02 Sep 2003 08:26:29 -0700
From: Yakov Rekhter <[email-masked]>
Sender: [email-masked]

Folks,

This is to start the WG Last Call on advacing 
draft-ietf-idr-bgp4-experience-protocol-01.txt to an Informational RFC.
The Last Call ends Sep 16, 2003.

Yakov.
------- Forwarded Message

Date:    Wed, 27 Aug 2003 10:27:11 -0400
From:    [email-masked]
To:      IETF-Announce: ;
cc:      [email-masked]
Subject: I-D ACTION:draft-ietf-idr-bgp4-experience-protocol-01.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		: Experience with the BGP-4 Protocol
	Author(s)	: D. McPherson, K. Patel
	Filename	: draft-ietf-idr-bgp4-experience-protocol-01.txt
	Pages		: 18
	Date		: 2003-8-27
	
The purpose of this memo is to document how the requirements for
advancing a routing protocol from Draft Standard to full Standard
have been satisfied by Border Gateway Protocol version 4 (BGP-4).
This report satisfies the requirement for 'the second report', as
described in Section 6.0 of RFC 1264.  In order to fulfill the
requirement, this report augments RFC 1773 and describes additional
knowledge and understanding gained in the time between when the
protocol was made a Draft Standard and when it was submitted for
Standard.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-idr-bgp4-experience-protocol-01.
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-experience-protocol-01.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-experience-protocol-01.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-experience-protocol-01.txt

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