Subject: [Idr] WG Last Call on draft-ietf-idr-rfc2796bis-00.txt

From: Yakov Rekhter <[email-masked]>
Date: Wed, 14 Apr 2004 13:36:09 -0700

Folks,

This is to start the IDR WG Last Call on advancing 
draft-ietf-idr-rfc2796bis-00.txt to Draft Standard. 

The Last Call ends April 28.

Yakov.
------- Forwarded Message

Date:    Wed, 14 Apr 2004 15:33:52 -0400
From:    [email-masked]
To:      [email-masked]
cc:      [email-masked]
Subject: I-D ACTION:draft-ietf-idr-rfc2796bis-00.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		: BGP Route Reflection - An Alternative to Full Mesh IB
GP
	Author(s)	: T. Bates, et al.
	Filename	: draft-ietf-idr-rfc2796bis-00.txt
	Pages		: 11
	Date		: 2004-4-14
	
The Border Gateway Protocol [1] is an inter-autonomous system routing
   protocol designed for TCP/IP internets. Currently in the Internet BGP
   deployments are configured such that that all BGP speakers within a
   single AS must be fully meshed so that any external routing
   information must be re-distributed to all other routers within that
   AS. This represents a serious scaling problem that has been  well
   documented with several alternatives proposed [2,3].

   This document describes the use and design of a method known as
   'Route Reflection' to alleviate the the need for 'full mesh' IBGP.

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

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of the mess
age.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

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-rfc2796bis-00.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-rfc2796bis-00.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-rfc2796bis-00.txt

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

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

- --OtherAccess--

- --NextPart--

_______________________________________________
I-D-Announce mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/i-d-announce

------- End of Forwarded Message

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

---

From: Yakov Rekhter <[email-masked]>
Date: Fri, 30 Apr 2004 10:56:17 -0700

Folks

> The Last Call ends April 28.

The WG Last Call is over. 

Many thanks to the folks who read and commented on the document !!!

The authors of the document are going to incorporate the comments 
received during the WG Last Call and re-issue a revised draft.

Yakov.

---

From: Yakov Rekhter <[email-masked]>
Date: Fri, 30 Apr 2004 10:56:17 -0700

Folks

Yakov.

---

From: "john smith" <[email-masked]>
Date: Fri, 30 Apr 2004 23:48:23 +0000

unsubscribe

>From: Yakov Rekhter <[email-masked]>
>To: Subject: Re: [Idr] WG Last Call on draft-ietf-idr-rfc2796bis-00.txt 
>Date: Fri, 30 Apr 2004 10:56:17 -0700
>
>Folks
>
> > Folks,
> >

_________________________________________________________________
Protect your PC - get McAfee.com VirusScan Online 
http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963

---

From: "john smith" <[email-masked]>
Date: Fri, 30 Apr 2004 23:48:23 +0000

unsubscribe

From: "john smith" <[email-masked]>
To: [email-masked]
Subject: Re: [Idr] WG Last Call on draft-ietf-idr-rfc2796bis-00.txt
Sender: [email-masked]
Date: Fri, 30 Apr 2004 23:48:23 +0000

unsubscribe

Cc: [email-masked]
From: Thomas Barron <[email-masked]>
Subject: Re: [Idr] draft-chen-bgp-avoid-transition-01.txt 
To: Enke Chen <[email-masked]>
Sender: [email-masked]
Date: Fri, 30 Apr 2004 17:41:07 -0500

Hi Enke,

   Thanks for clarifying.  I'm cool with this :-)

- Tom

On Apr 30, 2004, at 5:17 PM, Enke Chen wrote:

> Hi, Tom:
>
> Please see inline.
>
>> Message-Id: <[email-masked]>
>> Content-Transfer-Encoding: 7bit
>> Cc: [email-masked]
>> From: Thomas Barron <[email-masked]>
>> Subject: Re: [Idr] draft-chen-bgp-avoid-transition-01.txt
>> Date: Fri, 30 Apr 2004 14:46:43 -0500
>> To: Enke Chen <[email-masked]>
>>
>
> [snip]
>
>> Well, if I'm right, it isn't always effective for this subset either.
>>
>>     Consider the example in Fig. 3 where
>>
>>        o R1, R2, R3 and R4 belong to one AS
>>        o R1 is a route reflector with R3 as its client.
>>        o R2 is a route reflector with R4 as its client.
>>        o External paths (a), (b) and (c) are as described in Fig. 4.
>>
>>
>>                    +----+      10      +----+
>>                    | R1 |--------------| R2 |
>>                    +----+              +----+
>>                       |                   |
>>                       |                   |
>>                       | 5                 | 20
>>                       |                   |
>>                       |                   |
>>                    +----+              +----+
>>                    | R3 |              | R4 |
>>                    +----+              +----+
>>                   /      \                |
>>                  /        \               |
>>                (a)        (b)            (c)
>>
>>                            Figure 3
>>
>>
>>                  Path    AS     MED   TimeofArrival
>>                   a        1        0         2
>>                   b        2       20        1
>>                   c        2       10        5
>>
>>                            Figure 4
>>
>> Here is the oscillation:
>>
>> 1. R3 likes (b) over (a) (ToA)
>> 2. R3 advertises (b) to R1
>> 3. R1 hears (b, c) and prefers (c) (MED)
>> 4. R1 advertises (c) to R3
>> 5. R3 prefers (a) among (a, b, c) (MED + ToA)
>>      *NOTE* the arrival time of (c) is no longer 5, but it is some
>> quantity >5.
>>       ToA(c) > 5 > ToA(a), so  (a) wins after MED eliminates (b) in
>> favor of (c).
>> 6. R3 advertises (a) to R1
>> 7. R1 hears (a, c) and prefers (a) (IGP)
>> 8. R1 advertises (a) to R2
>> 9. R2 prefers (a) over (c) (lower IGP cost)
>> 10. R2 withdraws (c) from R1 and the withdrawal propagates through R1
>> to R3
>> 11.  R3 prefers (b) over (a) since (c) is no longer available to
>> disqualify (b) and
>>        ToA(b) < ToA(a)
>
>
> I see where your confusion was. The proposed algorithm in Sect. 4 of 
> the
> draft does not really care about ToA ("Time of Arrival"). It just says
> that "Do not switch the best path from one EBGP path to another EBGP
> path when the comparison comes down to the route-id.
>
> So, in Step 11, if you follow the proposed algorithm, (a) will remain
> as the best path on R3, and the churn will stop.
>
> I will need to think about other comments of yours, and try to clarify
> the text in the next version.
>
> Thanks. -- Enke
>

From: [email-masked]
Subject: Re: Yakov Rekhter: [Idr] draft-chen-bgp-avoid-transition-01.txt as an IDR WG document
To: [email-masked]
Cc: [email-masked], [email-masked]
Sender: [email-masked]
Date: Fri, 30 Apr 2004 15:37:33 -0700 (PDT)

I vote yes to have it be accepted as an IDR WG document.

thanks,
jenny

> Message-Id: <[email-masked]>
> To: [email-masked]
> Subject: [Idr] draft-chen-bgp-avoid-transition-01.txt as an IDR WG document
> Date: Fri, 30 Apr 2004 10:21:45 -0700
> 
> Folks
> 
> We receive a request to accept draft-chen-bgp-avoid-transition-01.txt
> as an IDR WG document. Please comment to the list. The deadline
> for comments is May 14, 2004. 
> 
> Yakov.
> - ------- Forwarded Message
> 
> Date:    Wed, 28 Apr 2004 10:13:29 -0700
> From:    Enke Chen <[email-masked]>
> To:      [email-masked], [email-masked]
> cc:      [email-masked]
> Subject: draft-chen-bgp-avoid-transition-01.txt
> 
> Hi, Yakov and Sue:
> 
> I would like to request that the draft <draft-chen-bgp-avoid-transition-01.txt>
> be accepted as an IDR WG document. The draft was presented previosuly at an
> IDR meeting. The algorithm described in the draft has been deployed for several
> years.
> 
> Thanks. -- Enke
> 
> - - ------- Forwarded Message
> 
> Message-Id: <[email-masked]>
> To: IETF-Announce: ;
> Reply-To: [email-masked]
> Subject: I-D ACTION:draft-chen-bgp-avoid-transition-01.txt
> Date: Tue, 20 Jan 2004 10:04:35 -0500
> 
> - - - --NextPart
> 
> 	Title		: Avoid BGP Best Path Transition from One External to A
> nother
> 	Author(s)	: E. Chen, S. Sangli
> 	Filename	: draft-chen-bgp-avoid-transition-01.txt
> 	Pages		: 5
> 	Date		: 2004-1-19
> 	
> In this document we propose an algorithm that would help improve the
> overall network stability by avoiding BGP best path transition from
> one external to another (under certain conditions)
> 
> http://www.ietf.org/internet-drafts/draft-chen-bgp-avoid-transition-01.txt
> 
> 
> - - ------- End of Forwarded Message
> 
> 
> - ------- End of Forwarded Message
> 
> 

From: Jeffrey Haas <[email-masked]>
To: Thomas Barron <[email-masked]>
Cc: Enke Chen <[email-masked]>, [email-masked]
Subject: Re: [Idr] draft-chen-bgp-avoid-transition-01.txt
Sender: [email-masked]
Date: Fri, 30 Apr 2004 18:25:46 -0400

On Fri, Apr 30, 2004 at 02:46:43PM -0500, Thomas Barron wrote:
> I am not myself aware of any other circumstances where the 
> indeterminism that this knob introduces has any bad effects.

Or existing implementations of this knob that already do this. :-)

Speaking as a former network operator of a tier-3 ISP, it took us a
while to understand why otherwise very stable paths would all of
a sudden take a sharp turn.  This was typically noticed when the
new stable path was poor for some reason.  

-- 
Jeff Haas 
NextHop Technologies

To: Thomas Barron <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: [Idr] draft-chen-bgp-avoid-transition-01.txt 
From: Enke Chen <[email-masked]>
Sender: [email-masked]
Date: Fri, 30 Apr 2004 15:17:21 -0700

Hi, Tom:

Please see inline.

> Message-Id: <[email-masked]>
> Content-Transfer-Encoding: 7bit
> Cc: [email-masked]
> From: Thomas Barron <[email-masked]>
> Subject: Re: [Idr] draft-chen-bgp-avoid-transition-01.txt 
> Date: Fri, 30 Apr 2004 14:46:43 -0500
> To: Enke Chen <[email-masked]>
> 

[snip]

> Well, if I'm right, it isn't always effective for this subset either.
> 
>     Consider the example in Fig. 3 where
> 
>        o R1, R2, R3 and R4 belong to one AS
>        o R1 is a route reflector with R3 as its client.
>        o R2 is a route reflector with R4 as its client.
>        o External paths (a), (b) and (c) are as described in Fig. 4.
> 
> 
>                    +----+      10      +----+
>                    | R1 |--------------| R2 |
>                    +----+              +----+
>                       |                   |
>                       |                   |
>                       | 5                 | 20
>                       |                   |
>                       |                   |
>                    +----+              +----+
>                    | R3 |              | R4 |
>                    +----+              +----+
>                   /      \                |
>                  /        \               |
>                (a)        (b)            (c)
> 
>                            Figure 3
> 
> 
>                  Path    AS     MED   TimeofArrival
>                   a        1        0         2
>                   b        2       20        1
>                   c        2       10        5
> 
>                            Figure 4
> 
> Here is the oscillation:
> 
> 1. R3 likes (b) over (a) (ToA)
> 2. R3 advertises (b) to R1
> 3. R1 hears (b, c) and prefers (c) (MED)
> 4. R1 advertises (c) to R3
> 5. R3 prefers (a) among (a, b, c) (MED + ToA)
>      *NOTE* the arrival time of (c) is no longer 5, but it is some 
> quantity >5.
>       ToA(c) > 5 > ToA(a), so  (a) wins after MED eliminates (b) in 
> favor of (c).
> 6. R3 advertises (a) to R1
> 7. R1 hears (a, c) and prefers (a) (IGP)
> 8. R1 advertises (a) to R2
> 9. R2 prefers (a) over (c) (lower IGP cost)
> 10. R2 withdraws (c) from R1 and the withdrawal propagates through R1 
> to R3
> 11.  R3 prefers (b) over (a) since (c) is no longer available to 
> disqualify (b) and
>        ToA(b) < ToA(a)

I see where your confusion was. The proposed algorithm in Sect. 4 of the
draft does not really care about ToA ("Time of Arrival"). It just says
that "Do not switch the best path from one EBGP path to another EBGP
path when the comparison comes down to the route-id.

So, in Step 11, if you follow the proposed algorithm, (a) will remain
as the best path on R3, and the churn will stop.

I will need to think about other comments of yours, and try to clarify
the text in the next version.

Thanks. -- Enke

From: Jeffrey Haas <[email-masked]>
To: [email-masked]
Subject: Re: [Idr] Soft-Notify as an IDR WG document
Sender: [email-masked]
Date: Fri, 30 Apr 2004 17:04:44 -0400

On Mon, Apr 26, 2004 at 08:01:36AM -0700, Yakov Rekhter wrote:
> Please comment on the attached. The deadline for comments is
> May 10.

I would urge that this document not be accepted.  I think that
a multi-session BGP is a better solution, perhaps with a graceful
failover mechanism.  I would offer many of the same reasons that Pedro
did, specifically the inability to deal with a corrupt TCP stream.

I believe that most of the shutdown reasons that we cared about have
been addressed in the current cease subcode document undergoing last call.

The prefix-limit issue is working itself out in other documents.

One note on BGP multi-session with regards to operational issues:
The BGP v2MIB includes the ability to montior multiple peering
sessions to a single peer across the same src/dst addresses.

-- 
Jeff Haas 
NextHop Technologies

To: Pekka Savola <[email-masked]>, Yakov Rekhter <[email-masked]>
From: Dinara Suleymanova <[email-masked]>
Subject: Re: [Idr] FYI: Last Call: 'A Border Gateway Protocol 4 (BGP-4)' to Draft Standard 
Cc: Alex Zinin <[email-masked]>, <[email-masked]>, <[email-masked]>
Sender: [email-masked]
Date: Thu, 29 Apr 2004 14:00:46 -0400

Hello,

Could it be possible to UN-subscribe us/me (not sure what address was added 
on your subscription list)
from your discussion list.

Thanks a lot.

Dinara Suleymanova

At 12:35 PM 4/29/2004, Pekka Savola wrote:
>On Tue, 20 Apr 2004, Yakov Rekhter wrote:
> > > >  2) The definition of active route is bad.  This fails in the
> > > >     situation where you need to export loopbacks/point-to-points to
> > > >     eBGP, but you have them in youro IGP.  The specification does not
> > > >     consider them active (not used for forwarding), and they aren't
> > > >     exported.
> > > >
> > > >     When the next-hop of the IGP route is the same as BGP next-hop,
> > > >     obviously this is no problem.  Gargi Nalawade promised to submit
> > > >     text, but hasn't, and I think Yakov said something about being
> > > >     willing to incorporate that, but obviously hasn't.
> > > >
> > > >     This was discussed at idr thread:
> > >
> > > >       issue 11.2: active route, again
> > >
> > > > Otherwise, I think this was operationally good.
> > >
> > > Sue, Yakov, please check if the ball was dropped re this one.
> >
> > First of all, the consensus of the WG (as documented in
> > draft-ietf-idr-bgp-issues) is to have the following 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.
> >
> > While this text does not cover the case described by Pekka, it does
> > not preclude it either - handling the case described by Pekka
> > is just outside the scope of the spec.
> >
> > With this in mind I suggest that the case described by Pekka
> > should be covered in a separate Internet Draft.
>
>I think this is operationally a rather common (or even very common)
>scenario, and it would seem very disadvantageous not to tackle it in
>this specification.  Further, there's major deployment of it (maybe
>even multi-vendor -- probably) so there is considerable proof that it
>works.
>
>It should be the default behaviour of BGP as that's which makes the
>most sense, operationally.  "BGP route is ... used by forwarding" does
>not sufficiently cover the fact that people do use IGPs and there's
>often overlap with IGP and BGP :).
>
>--
>Pekka Savola                 "You each name yourselves king, yet the
>Netcore Oy                    kingdom bleeds."
>Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
>
>

Cc: [email-masked]
From: Thomas Barron <[email-masked]>
Subject: Re: [Idr] draft-chen-bgp-avoid-transition-01.txt 
To: Enke Chen <[email-masked]>
Sender: [email-masked]
Date: Fri, 30 Apr 2004 14:46:43 -0500

Hi Enke,

    Please see inline.

On Apr 29, 2004, at 11:49 PM, Enke Chen wrote:

> Hi, Tom:
>
> Thanks for your comments, and sorry that I forgot to reply to your 
> original
> message earlier. Please see my comments inline.
>
>> Message-Id: <[email-masked]>
>> Cc: [email-masked], [email-masked]
>> From: Thomas Barron <[email-masked]>
>> Subject: Re: [Idr] draft-chen-bgp-avoid-transition-01.txt
>> To: Enke Chen <[email-masked]>, [email-masked]
>>
>> Hi Enke,
>>
>>     Attached is an email I sent to IDR that discusses some issues 
>> around
>> your draft.  I don't think I have seen a reply.
>>
>>    I will add now that since that note I've discussed and thought a 
>> bit
>> more about your argument in 5.2, and I think it is quite clear (and is
>> indeed the received opinion nowadays) that the essential ingredient in
>> these route-oscillation problems is the interaction of Route 
>> Reflectors
>> and IGP costs.
>
> MED plays a major role as well.
>

Sure.

>> Using sufficiently high IGP costs between clusters will suffice to 
>> stop
>> the churn both in your scenario and in other scenarios that don't 
>> involve
>> router-id.
>
> Very true, and that is also discussed in Sect. 9 of RFC 2796 (RR).
>

I rather like the way the point is put there.

> Re-configuring the IGP metric is certainly an option. However, 
> changing the
> IGP metric typically has much larger impact on the network traffic 
> matrix,
> and may not be desirable or feasible.
>

Hmmm.  Maybe my thinking is just too pedestrian, but I don't myself see 
the design drivers for setting up RRs and RCs such that clusters don't 
"cluster" in terms of IGP metrics as well.

>> Indeed, in your scenario if by chance
>> the times of arrival correspond in the same order to that determined 
>> by
>> the router-ids the churn is not avoided by your algorithm either (the
>> proof is tedious, but intuitively: start the scenario with the same
>> ranking of tie-breakers, just use time-of-arrival instead of 
>> router-id;
>> then realize that this order gets preserved as the oscillation 
>> proceeds
>> because the repeatedly advertised-and-withdrawn route will always be
>> "newest" and correspond to the largest router id in the original
>> scenario.)
>
> Do you have a specific example?  I would like to understand better 
> whether
> the algorithm is applicable to the example.
>
> Unlike the ADD-PATH approach (which is a complete solution), the 
> proposed
> algorithm is effective only for a subset of route oscillations.
>

Well, if I'm right, it isn't always effective for this subset either.

    Consider the example in Fig. 3 where

       o R1, R2, R3 and R4 belong to one AS
       o R1 is a route reflector with R3 as its client.
       o R2 is a route reflector with R4 as its client.
       o External paths (a), (b) and (c) are as described in Fig. 4.

                   +----+      10      +----+
                   | R1 |--------------| R2 |
                   +----+              +----+
                      |                   |
                      |                   |
                      | 5                 | 20
                      |                   |
                      |                   |
                   +----+              +----+
                   | R3 |              | R4 |
                   +----+              +----+
                  /      \                |
                 /        \               |
               (a)        (b)            (c)

                           Figure 3

                 Path    AS     MED   TimeofArrival
                  a        1        0         2
                  b        2       20        1
                  c        2       10        5

                           Figure 4

Here is the oscillation:

1. R3 likes (b) over (a) (ToA)
2. R3 advertises (b) to R1
3. R1 hears (b, c) and prefers (c) (MED)
4. R1 advertises (c) to R3
5. R3 prefers (a) among (a, b, c) (MED + ToA)
     *NOTE* the arrival time of (c) is no longer 5, but it is some 
quantity >5.
      ToA(c) > 5 > ToA(a), so  (a) wins after MED eliminates (b) in 
favor of (c).
6. R3 advertises (a) to R1
7. R1 hears (a, c) and prefers (a) (IGP)
8. R1 advertises (a) to R2
9. R2 prefers (a) over (c) (lower IGP cost)
10. R2 withdraws (c) from R1 and the withdrawal propagates through R1 
to R3
11.  R3 prefers (b) over (a) since (c) is no longer available to 
disqualify (b) and
       ToA(b) < ToA(a)

(Thanks to Nick Feamster, some time ago, for documenting these steps in 
a private email.)

So, what we've done is keep everything the same in your example except 
that we've put ToA where you have Router ID.  You make the point that 
"the BGP identifier of a route received from an external peer is just a 
random number" and that led me to think of the fact that the same can 
be said of the Time of Arrival.  The interesting thing about your 
scenario is that the Time of Arrival of route (c) will change because 
it is withdrawn and readvertised, but since it is the highest that 
doesn't affect the order of the Times of Arrival so the formal 
parallelism with your case using BGP identifiers is preserved.

>>
>>    But as I say in the attached, my argument is really with section 
>> 5.2,
>> not with your overall proposal.  There are implementations that 
>> provide
>> a knob to do just what you are documenting and I agree that the BGP
>> spec should provide for this option.
>>
>>     Best regards,
>>
>>    Tom Barron
>>
>>
>>> From [email-masked] Mon Nov 10 11:51:50 2003
>> From: Tom Barron <[email-masked]>
>> To: [email-masked]
>> Cc: Thomas P Barron <[email-masked]>
>> Message-ID: <[email-masked]>
>>
>> Enke, Srihari, et. al:
>>
>> I have some questions about draft-chen-bgp-avoid-transition-00.txt.
>> I'm glad to see this draft since there are implementations out there
>> using the route-selection algorithm this draft proposes, and since the
>> proposed algorith is not what is documented in RFC1771 or in
>> draft-ietf-idr-bgr4-22.txt section 9.1.2.2.
>>
>> First, is it the intent of this draft that the proposed algorithm
>> should *replace* the algorithm currently documented, or just that
>> it be added as an option?
>
> It is a backward-compatible extension to the base BGP spec.. Whether
> it is ON or OFF, that is an implementation decision. (If that is the
> intent of your question.)
>

Good.   Yes, that is the intention of my question, and I suggest that 
you make this point explicitly in your draft.

>>
>> Second, while I think the claim in 5.1 that the proposed algorithm
>> avoids an unnecessary best path transition is quite straightforward,
>> there ought to be some discussion of concerns that have been expressed
>> about the consequent lack of determinism in route selection.  See
>> for example section 7.1.4 of 
>> draft-ietf-idr-bgp4-experience-protocol-03.txt
>> and appendix A of "Guidelines for Interdomain Traffic Engineering" by
>> Feamster, Borkenhagen, and Rexford.  I'm not personally convinced
>> that this local indeterminism is a real big deal, but I do think it
>> needs some discussion in your draft.
>
> As I recall, the only practical concern raised so far is the impact on
> BGP testing script by the proposed algorithm, and the subject (impact
> on the testing script) seems to be outside the scope of the document.
> Please let me know if I have missed any other practical concerns.
>

Well, without getting into issues about whether Traffic Engineering is 
"practical" :-), I suggest that you might want to explicitly state that 
there may be circumstances in which an ISP is doing TE where this knob 
would be best left off.

I am not myself aware of any other circumstances where the 
indeterminism that this knob introduces has any bad effects.

>>
>> Third, I found the argument at 5.2 to the effect that the proposed
>> algorithm reduces route oscillation a bit unclear.  Maybe just a bit
>> more text is needed, but it seems to me that the really essential
>> ingredient in your setup in figure 1 and figure 2 is not the router
>> ID, but the high intracluster IGP metric.  Indeed, though you cite
>> RFC3345, that work focuses on IGP metrics, not router ID, as a
>> critical factor for "type 1" oscillation scenarios (yours appears to
>> be a type 1 variant.)  If adjusting IGP metrics is sufficient to fix
>> both your oscillation scenario and other type 1 scenarios, but
>> shifting from Router ID selection to the proposed time-of-arrival
>> algorithm is not sufficient for type 1 scenarios in general, then the
>> contribution of the proposed algorithm to the route oscillation
>> problem does not seem very decisive.  On the other hand, if using the
>> proposed time-of-arrival algorithm yields a general solution to
>> oscillation problems, then this reader at least did not get that from
>> the draft as currently written.
>>
>
> We will work on adding more text to clarify.
>
>> I'm glad you folks wrote this draft.  I hope it's clear that I'm
>> not against your proposal, but rather want to address some gaps
>> in my own understanding of the issues that surround it.
>>
>
> Some of the gaps are with the text in the document :-)
> We will work on improving it in the next version.
>
> Regards,
>
> -- Enke
>

Thanks,

- Tom

From: Pedro Roque Marques <[email-masked]>
To: Pekka Savola <[email-masked]>
Cc: Yakov Rekhter <[email-masked]>, Alex Zinin <[email-masked]>, <[email-masked]>, <[email-masked]>
Subject: Re: [Idr] FYI: Last Call: 'A Border Gateway Protocol 4 (BGP-4)' to Draft Standard 
Sender: [email-masked]
Date: Fri, 30 Apr 2004 11:14:38 -0700 (PDT)

Pekka Savola writes:

> On Fri, 30 Apr 2004, Yakov Rekhter wrote:
>> > I think this is operationally a rather common (or even very
>> common) > scenario, and it would seem very disadvantageous not to
>> tackle it in > this specification.  Further, there's major
>> deployment of it (maybe > even multi-vendor -- probably) so there
>> is considerable proof that it > works.  > > It should be the
>> default behaviour of BGP as that's which makes the > most sense,
>> operationally.  "BGP route is ... used by forwarding" does > not
>> sufficiently cover the fact that people do use IGPs and there's >
>> often overlap with IGP and BGP :).
>> 
>> People do use IGPs, and there is interaction between IGPs and BGP.
>> 
>> It is just that the based BGP protocol spec is *not* the place to
>> document the interaction between BGP and IGPs.

> I have to disagree here.  BGP is useless without IGP.  Failing to
> consider that would mean a specifition disconnected from the
> reality.

Pekka,
BGP is only one of the miriad of components necessary in a
router. There are advantages in documenting interactions between such
components but these are typically not done in the base
specification.

One simply cannot put all the bits of information required to make bgp
"useful" in the base specification and still have a readable document.

moreever the iteraction procedures that you seem to want to document
are not something the wg has achieved consensus on. there are still
different opinions on this topic and different deployed
behaviours. Thus including this topic in the base protocol spec seems
to me to be contrary to the original goals of revising the
specification.

I would also like to point out that several outher people have
expressed the opinion that this topic should be left out of the base
spec. In fact i would claim that there is consensus on that ammong the
wg.

  Pedro.

To: [email-masked]
Subject: Re: [Idr] WG Last Call on draft-ietf-idr-rfc2796bis-00.txt 
From: Yakov Rekhter <[email-masked]>
Sender: [email-masked]
Date: Fri, 30 Apr 2004 10:56:17 -0700

Folks

Yakov.

To: Jeffrey Haas <[email-masked]>
Cc: Yakov Rekhter <[email-masked]>, [email-masked], [email-masked]
Subject: Re: [Idr] Last Call on draft-ietf-idr-rfc2796bis-00.txt 
From: Enke Chen <[email-masked]>
Sender: [email-masked]
Date: Fri, 30 Apr 2004 10:43:36 -0700

Hi, Jeff:

> From: Jeffrey Haas <[email-masked]>
> To: Yakov Rekhter <[email-masked]>
> Cc: [email-masked]
> Subject: Re: [Idr] Last Call on draft-ietf-idr-rfc2796bis-00.txt
> Message-ID: <[email-masked]>
> References: <[email-masked]>
> 
> Additional nits:
> >    Their modification could potential result in routing loops.
> 
> s/potential/potentially/
> 
> In the changes, also note that you corrected transitive to
> non-transitive in the introduction.
> 
> I think ROUTER_ID should be consistently substituted with "BGP Identifier"
> per the current use in draft-ietf-idr-bgp4-23

Ok.

> 
>    one. Using this attribute an RR can identify if the routing
>    information is looped back to the same cluster due to mis-
>    configuration. If the local CLUSTER_ID is found in the CLUSTER_LIST,
> 
> 
> s/is looped/has looped/

Ok.

> 
> Original text:
>    If the BGP Identifiers of two paths are equal when compared in the
>    route selection, then the path with the shorter CLUSTER_LIST length
> 
> Suggested change:
>    The BGP Decision Process Tie Breaking rules (Section 9.1.2.2 of the
>    BGP specification) is modified by inserting the following rule 
>    between f and g:
> 
>    The BGP Speaker SHOULD prefer all routes with the shorter
>    CLUSTER_LIST length.  If no CLUSTER_LIST path attribute is present,
>    the CLUSTER_LIST length is zero.

will revise the text along these lines.

Thanks.  -- Enke

> 
> On Fri, Apr 16, 2004 at 02:21:13PM -0700, Yakov Rekhter wrote:
> > Folks,
> > 
> > During the Last Call it would be greatly appreciated if folks would
> > read the document and comment on it to the IDR mailing list. In
> > other words, we need "yes, looks good" or "should fix this and
> > that", not just silence.
> > 
> > Thanks in advance.
> > 
> > Yakov.
> 
> -- 
> Jeff Haas 
> NextHop Technologies
> 

To: [email-masked]
cc: [email-masked]
Subject: Re: [Idr] draft-lange-flexible-bgp-communities-02.txt as an IDR WG document 
From: Yakov Rekhter <[email-masked]>
Sender: [email-masked]
Date: Fri, 30 Apr 2004 10:26:49 -0700

Folks

> We receive a request to accept draft-lange-flexible-bgp-communities-02.txt
> as an IDR WG document. Please send comments to the list. The deadline
> for comments is April 28, 2004. 

The draft didn't generate enough support to justify its acceptance
as an IDR WG document.

Sue & Yakov.

To: [email-masked]
From: Yakov Rekhter <[email-masked]>
Subject: [Idr] draft-chen-bgp-avoid-transition-01.txt as an IDR WG document
Sender: [email-masked]
Date: Fri, 30 Apr 2004 10:21:45 -0700

Folks

We receive a request to accept draft-chen-bgp-avoid-transition-01.txt
as an IDR WG document. Please comment to the list. The deadline
for comments is May 14, 2004. 

Yakov.

Date:    Wed, 28 Apr 2004 10:13:29 -0700
From:    Enke Chen <[email-masked]>
To:      [email-masked], [email-masked]
cc:      [email-masked]
Subject: draft-chen-bgp-avoid-transition-01.txt

Hi, Yakov and Sue:

I would like to request that the draft <draft-chen-bgp-avoid-transition-01.txt>
be accepted as an IDR WG document. The draft was presented previosuly at an
IDR meeting. The algorithm described in the draft has been deployed for several
years.

Thanks. -- Enke

- ------- Forwarded Message

Message-Id: <[email-masked]>
To: IETF-Announce: ;
From: [email-masked]
Reply-To: [email-masked]
Subject: I-D ACTION:draft-chen-bgp-avoid-transition-01.txt
Date: Tue, 20 Jan 2004 10:04:35 -0500

- - --NextPart

	Title		: Avoid BGP Best Path Transition from One External to A
nother
	Author(s)	: E. Chen, S. Sangli
	Filename	: draft-chen-bgp-avoid-transition-01.txt
	Pages		: 5
	Date		: 2004-1-19
	
In this document we propose an algorithm that would help improve the
overall network stability by avoiding BGP best path transition from
one external to another (under certain conditions)

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-chen-bgp-avoid-transition-01.txt

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

From: Pekka Savola <[email-masked]>
To: Yakov Rekhter <[email-masked]>
cc: Alex Zinin <[email-masked]>, <[email-masked]>, <[email-masked]>
Subject: Re: [Idr] FYI: Last Call: 'A Border Gateway Protocol 4 (BGP-4)' to Draft Standard 
Sender: [email-masked]
Date: Fri, 30 Apr 2004 20:18:44 +0300 (EEST)

On Fri, 30 Apr 2004, Yakov Rekhter wrote:
> > I think this is operationally a rather common (or even very common)  
> > scenario, and it would seem very disadvantageous not to tackle it in
> > this specification.  Further, there's major deployment of it (maybe
> > even multi-vendor -- probably) so there is considerable proof that it
> > works.
> > 
> > It should be the default behaviour of BGP as that's which makes the
> > most sense, operationally.  "BGP route is ... used by forwarding" does
> > not sufficiently cover the fact that people do use IGPs and there's
> > often overlap with IGP and BGP :).
> 
> People do use IGPs, and there is interaction between IGPs and BGP.
> 
> It is just that the based BGP protocol spec is *not* the place to 
> document the interaction between BGP and IGPs.

I have to disagree here.  BGP is useless without IGP.  Failing to
consider that would mean a specifition disconnected from the reality.

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

To: Pekka Savola <[email-masked]>
cc: Alex Zinin <[email-masked]>, [email-masked], [email-masked]
Subject: Re: [Idr] FYI: Last Call: 'A Border Gateway Protocol 4 (BGP-4)' to Draft Standard 
From: Yakov Rekhter <[email-masked]>
Sender: [email-masked]
Date: Fri, 30 Apr 2004 10:15:26 -0700

Pekka,

> On Tue, 20 Apr 2004, Yakov Rekhter wrote:
> > > >  2) The definition of active route is bad.  This fails in the 
> > > >     situation where you need to export loopbacks/point-to-points to 
> > > >     eBGP, but you have them in youro IGP.  The specification does not
> > > >     consider them active (not used for forwarding), and they aren't 
> > > >     exported.
> > > > 
> > > >     When the next-hop of the IGP route is the same as BGP next-hop,
> > > >     obviously this is no problem.  Gargi Nalawade promised to submit 
> > > >     text, but hasn't, and I think Yakov said something about being 
> > > >     willing to incorporate that, but obviously hasn't.
> > > >
> > > >     This was discussed at idr thread:
> > > 
> > > >       issue 11.2: active route, again
> > > 
> > > > Otherwise, I think this was operationally good.
> > > 
> > > Sue, Yakov, please check if the ball was dropped re this one.
> > 
> > First of all, the consensus of the WG (as documented in 
> > draft-ietf-idr-bgp-issues) is to have the following 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.
> > 
> > While this text does not cover the case described by Pekka, it does
> > not preclude it either - handling the case described by Pekka
> > is just outside the scope of the spec.
> > 
> > With this in mind I suggest that the case described by Pekka
> > should be covered in a separate Internet Draft.
> 
> I think this is operationally a rather common (or even very common)  
> scenario, and it would seem very disadvantageous not to tackle it in
> this specification.  Further, there's major deployment of it (maybe
> even multi-vendor -- probably) so there is considerable proof that it
> works.
> 
> It should be the default behaviour of BGP as that's which makes the
> most sense, operationally.  "BGP route is ... used by forwarding" does
> not sufficiently cover the fact that people do use IGPs and there's
> often overlap with IGP and BGP :).

People do use IGPs, and there is interaction between IGPs and BGP.

It is just that the based BGP protocol spec is *not* the place to 
document the interaction between BGP and IGPs.

Yakov.

To: Thomas Barron <[email-masked]>
Cc: [email-masked], [email-masked]
Subject: Re: [Idr] draft-chen-bgp-avoid-transition-01.txt 
From: Enke Chen <[email-masked]>
Sender: [email-masked]
Date: Thu, 29 Apr 2004 21:49:24 -0700

Hi, Tom:

Thanks for your comments, and sorry that I forgot to reply to your original
message earlier. Please see my comments inline.

> Message-Id: <[email-masked]>
> Cc: [email-masked], [email-masked]
> From: Thomas Barron <[email-masked]>
> Subject: Re: [Idr] draft-chen-bgp-avoid-transition-01.txt
> To: Enke Chen <[email-masked]>, [email-masked]
> 
> Hi Enke,
> 
>     Attached is an email I sent to IDR that discusses some issues around  
> your draft.  I don't think I have seen a reply.
> 
>    I will add now that since that note I've discussed and thought a bit  
> more about your argument in 5.2, and I think it is quite clear (and is  
> indeed the received opinion nowadays) that the essential ingredient in  
> these route-oscillation problems is the interaction of Route Reflectors  
> and IGP costs.

MED plays a major role as well.

> Using sufficiently high IGP costs between clusters will suffice to stop
> the churn both in your scenario and in other scenarios that don't involve
> router-id.

Very true, and that is also discussed in Sect. 9 of RFC 2796 (RR).

Re-configuring the IGP metric is certainly an option. However, changing the
IGP metric typically has much larger impact on the network traffic matrix,
and may not be desirable or feasible.

> Indeed, in your scenario if by chance  
> the times of arrival correspond in the same order to that determined by  
> the router-ids the churn is not avoided by your algorithm either (the  
> proof is tedious, but intuitively: start the scenario with the same  
> ranking of tie-breakers, just use time-of-arrival instead of router-id;  
> then realize that this order gets preserved as the oscillation proceeds  
> because the repeatedly advertised-and-withdrawn route will always be  
> "newest" and correspond to the largest router id in the original  
> scenario.)

Do you have a specific example?  I would like to understand better whether
the algorithm is applicable to the example.

Unlike the ADD-PATH approach (which is a complete solution), the proposed
algorithm is effective only for a subset of route oscillations.

> 
>    But as I say in the attached, my argument is really with section 5.2,  
> not with your overall proposal.  There are implementations that provide  
> a knob to do just what you are documenting and I agree that the BGP  
> spec should provide for this option.
> 
>     Best regards,
> 
>    Tom Barron
> 
> 
> >From [email-masked] Mon Nov 10 11:51:50 2003
> From: Tom Barron <[email-masked]>
> To: [email-masked]
> Cc: Thomas P Barron <[email-masked]>
> Message-ID: <[email-masked]>
> 
> Enke, Srihari, et. al:
> 
> I have some questions about draft-chen-bgp-avoid-transition-00.txt.
> I'm glad to see this draft since there are implementations out there
> using the route-selection algorithm this draft proposes, and since the
> proposed algorith is not what is documented in RFC1771 or in
> draft-ietf-idr-bgr4-22.txt section 9.1.2.2.
> 
> First, is it the intent of this draft that the proposed algorithm 
> should *replace* the algorithm currently documented, or just that
> it be added as an option?

It is a backward-compatible extension to the base BGP spec.. Whether
it is ON or OFF, that is an implementation decision. (If that is the
intent of your question.)

> 
> Second, while I think the claim in 5.1 that the proposed algorithm
> avoids an unnecessary best path transition is quite straightforward,
> there ought to be some discussion of concerns that have been expressed
> about the consequent lack of determinism in route selection.  See
> for example section 7.1.4 of draft-ietf-idr-bgp4-experience-protocol-03.txt
> and appendix A of "Guidelines for Interdomain Traffic Engineering" by
> Feamster, Borkenhagen, and Rexford.  I'm not personally convinced
> that this local indeterminism is a real big deal, but I do think it
> needs some discussion in your draft.

As I recall, the only practical concern raised so far is the impact on
BGP testing script by the proposed algorithm, and the subject (impact
on the testing script) seems to be outside the scope of the document.
Please let me know if I have missed any other practical concerns.

> 
> Third, I found the argument at 5.2 to the effect that the proposed
> algorithm reduces route oscillation a bit unclear.  Maybe just a bit
> more text is needed, but it seems to me that the really essential
> ingredient in your setup in figure 1 and figure 2 is not the router
> ID, but the high intracluster IGP metric.  Indeed, though you cite
> RFC3345, that work focuses on IGP metrics, not router ID, as a
> critical factor for "type 1" oscillation scenarios (yours appears to
> be a type 1 variant.)  If adjusting IGP metrics is sufficient to fix
> both your oscillation scenario and other type 1 scenarios, but
> shifting from Router ID selection to the proposed time-of-arrival
> algorithm is not sufficient for type 1 scenarios in general, then the
> contribution of the proposed algorithm to the route oscillation
> problem does not seem very decisive.  On the other hand, if using the
> proposed time-of-arrival algorithm yields a general solution to
> oscillation problems, then this reader at least did not get that from
> the draft as currently written.
> 

We will work on adding more text to clarify.

> I'm glad you folks wrote this draft.  I hope it's clear that I'm
> not against your proposal, but rather want to address some gaps
> in my own understanding of the issues that surround it.
> 

Some of the gaps are with the text in the document :-)
We will work on improving it in the next version.

Regards,

-- Enke

From: Jeffrey Haas <[email-masked]>
To: Pekka Savola <[email-masked]>
Cc: Pedro Roque Marques <[email-masked]>, Yakov Rekhter <[email-masked]>, [email-masked]
Subject: Re: [Idr] draft-lange-flexible-bgp-communities-02.txt as an IDR WG document
Sender: [email-masked]
Date: Fri, 30 Apr 2004 00:16:46 -0400

On Thu, Apr 22, 2004 at 12:17:53PM +0300, Pekka Savola wrote:
> For what it's worth, it seems to me that this memo is a solution
> looking for the problem.
> 
> Why do we need this in the first place?  To "standardize" commonly 
> used communities?  To give the users more tools to mess up their 
> routing, or to allow the users to make the ISP's policy more complex?
> 
> I'm skeptical about the usefulness of this approach.

FWIW, I think this was proposed for a couple of reasons:

Once upon a draft, draft-ietf-grow-bgp-redistribution-00.txt tried
to formalize some very common bgp policy that communities are
used for.  Specific examples are:

proxy as-path prepend
proxy append no-export
proxy append no-announce

filters included:
to an as
to two as's
to a cidr prefix (v4 only)
to a 4byte as

The operations are not novel as the survey that Olivier Bonaventure
and Bruno Quoitin did as part of the original GROW draft.  The 
draft was suggested as a way to take common operational procuedure
and simplify configuration.

The primary objection at the time were:
1. We can't represent ipv6 information due to the length of the 
   extended community.
2. Why don't we just make an uber community and be done with it?

Flexible communities adds this as well as adding the concept of
neighbor classes and being (well...) flexible enough to accomodate
future needs as well as deprecating existing mechanisms.

My personal suggestions:
o Is the underlying functionality useful regardless of the encoding?
o If so, is the encoding clean enough or potentially too cumbersome?
o Should we keep the encoding of things like route-target, etc. out
  of this?

>  - it might make sense to switch the order of Length and "ASN" fields 
> for better alignment.

I thought this had been mentioned at SF IETF. :-)

> Length could also include the ASN field. (Maybe 
> this would be a more typical TLV encoding?)

Perhaps it would be better to simply strip any 4byte ASes upon export
when 4byte ASes aren't supported.

-- 
Jeff Haas 
NextHop Technologies

From: Jeffrey Haas <[email-masked]>
To: [email-masked]
Subject: Re: [Idr] draft-chen-bgp-avoid-transition-01.txt
Sender: [email-masked]
Date: Thu, 29 Apr 2004 23:17:08 -0400

On Wed, Apr 28, 2004 at 10:13:29AM -0700, Enke Chen wrote:
> I would like to request that the draft <draft-chen-bgp-avoid-transition-01.txt>
> be accepted as an IDR WG document. The draft was presented previosuly at an
> IDR meeting. The algorithm described in the draft has been deployed for several

I would echo many of Tom's comments.  Specifically:

1. This doesn't solve med oscillation - or at least I don't think so.
2. Having this as a knob would be handy.  Whether this knob is turned
   on by default is an interesting question and the matter of some
   debate.
3. By having such a knob, those who prefer deterministic path selection
   in their network can have it while those who prefer path stability
   with the caveat that it is temporally deterministic could have their
   way too - perhaps on a border router basis.

Suggested changes:
Remove 5.2
Add something along the lines of item 3 above?
Be a bit more specific about where in the tie breaking algorithm this goes.

-- 
Jeff Haas 
NextHop Technologies

From: Jeffrey Haas <[email-masked]>
To: Yakov Rekhter <[email-masked]>
Cc: [email-masked]
Subject: Re: [Idr] Last Call on draft-ietf-idr-rfc2796bis-00.txt
Sender: [email-masked]
Date: Thu, 29 Apr 2004 22:40:18 -0400

Additional nits:
>    Their modification could potential result in routing loops.

s/potential/potentially/

In the changes, also note that you corrected transitive to
non-transitive in the introduction.

I think ROUTER_ID should be consistently substituted with "BGP Identifier"
per the current use in draft-ietf-idr-bgp4-23

   one. Using this attribute an RR can identify if the routing
   information is looped back to the same cluster due to mis-
   configuration. If the local CLUSTER_ID is found in the CLUSTER_LIST,

s/is looped/has looped/

Original text:
   If the BGP Identifiers of two paths are equal when compared in the
   route selection, then the path with the shorter CLUSTER_LIST length

Suggested change:
   The BGP Decision Process Tie Breaking rules (Section 9.1.2.2 of the
   BGP specification) is modified by inserting the following rule 
   between f and g:

   The BGP Speaker SHOULD prefer all routes with the shorter
   CLUSTER_LIST length.  If no CLUSTER_LIST path attribute is present,
   the CLUSTER_LIST length is zero.

On Fri, Apr 16, 2004 at 02:21:13PM -0700, Yakov Rekhter wrote:
> Folks,
> 
> During the Last Call it would be greatly appreciated if folks would
> read the document and comment on it to the IDR mailing list. In
> other words, we need "yes, looks good" or "should fix this and
> that", not just silence.
> 
> Thanks in advance.
> 
> Yakov.

-- 
Jeff Haas 
NextHop Technologies

From: Cheng-Yin Lee <[email-masked]>
Reply-To: [email-masked]
To: [email-masked], [email-masked]
Subject: Re: [Idr] AD-review comments on draft-ietf-idr-bgp-analysis-04.txt
Sender: [email-masked]
Date: Thu, 29 Apr 2004 15:15:03 -0400

Hello,

Alex Zinin wrote:

>>2.2.  BGP Algorithms
>>
>>
>>   BGP uses an algorithm that is neither a pure distance vector
>>   algorithm or a pure link state algorithm.  It is instead a modified
>>   distance vector algorithm referred to as a "Path Vector" algorithm
>>   that uses path information to avoid traditional distance vector
>>   problems.  Each route within BGP pairs destination with path
>>   information to that destination.  Path information (also known as
>>   AS_PATH information) is stored within the AS_PATH attribute in BGP.
>>   This allows BGP to reconstruct large portions of overall topology
>>   whenever required.
>>    
>>
>
>I've always been uncomfortable with documents saying that BGP reconstructs the
>overall topology. It doesn't really do this like the link-state protocols do,
>for example.
>  
>
Is this sentence "This allows BGP to reconstruct  large portions of
overall
topology ...." talking about using AS_PATH  as topology information or
reconstructing routes/paths?

>>6.1.1.  CPU utilization
>>
>>
>>   An important and fundamental feature of BGP is that BGP's CPU
>>   utilization depends only on the stability of the Internet.  If the
>>   Internet is stable, then the only link bandwidth and router CPU
>>   cycles consumed by BGP are due to the exchange of the BGP KEEPALIVE
>>   messages.  The KEEPALIVE messages are exchanged only between peers.
>>   The suggested frequency of the exchange is 30 seconds.  The KEEPALIVE
>>   messages are quite short (19 octets), and require virtually no
>>   processing.  As a result, the bandwidth consumed by the KEEPALIVE
>>   messages is about 5 bits/sec.  Operational experience confirms that
>>   the overhead (in terms of bandwidth and CPU) associated with the
>>   KEEPALIVE messages should be viewed as negligible.
>>
>>   During periods of Internet instability, changes to the reachability
>>   information are passed between routers in UPDATE messages.  The
>>    
>>
>
>While theoretically the text is correct and we could talk about periods of
>stability and instability of the Internet, I wonder if this text is still
>applicable from the practical perspective. I.e., the continuous churn that the
>Internet BGP speakers experience ensures that they practically always have
>something to process.
>
>Probably instead of talking about periods of "Internet stability" and "Internet
>instability" we could talk about something like "periods of stable state among
>BGP speakers when they do no have new updates to communicate to each other".
>
>  
>
>>Meyer and Patel                                Section 6.1.1.  [Page 10]
>>
>>INTERNET-DRAFT             Expires: March 2004            September 2003
>>
>>
>>   greatest overhead per UPDATE message occurs when each UPDATE message
>>   contains only a single network.  It should be pointed out that in
>>   practice routing changes exhibit strong locality with respect to the
>>   AS path.  That is, routes that change are likely to have common AS
>>   path.  In this case, multiple networks can be grouped into a single
>>   UPDATE message, thus significantly reducing the amount of bandwidth
>>   required (see also Appendix F.1 of [BGP4]).
>>
>>   Since in the steady state the link bandwidth and router CPU cycles
>>   consumed by the BGP protocol are dependent only on the stability of
>>   the Internet, it follows that BGP should have no scaling problems in
>>   the areas of link bandwidth and router CPU utilization.
>>    
>>
>
>Not sure I follow here. What is meant by the "steady state" here? If it means
>convergence on a stable topology after the initial exchange of updates, then why
>talk about "stability of the Internet"? 
>
>        I took this to mean that whenever a BGP session starts, there's a
>     potentially long initial exchange of routes, and we mean to exclude
>     that startup transient.
>
>        But, of course, we're back to the "stable Internet" paradigm. :^(

>In other words, if the Internet is
>unstable then can we say that the BGP speakers are in steady state? In the lack
>of topology changes, it seems that the consumption should instead depend on the
>number of peers (affects KEEPALIVE processing) and the number of persistently
>oscillating routes potentially present in the network...
>
I agree the term Internet instability may not be clear enough in this
draft.

It seems that the draft is saying :
BGP CPU's utilization depends mostly on number of route exchanges and
KEEPALIVE message processing is not significant [The route exchanges can
be due to a topology change, router startup, configuration changes,
oscillating routes, ..... And oscillating routes
may be triggered by topology change, router startup, configuration
changes .....] ?

If that's the case, instead of saying Internet stability or instability
as follows :
"If the Internet is stable, then the only link bandwidth and router CPU
cycles consumed by BGP are  due to the exchange of the BGP KEEPALIVE
messages. "

perhaps the draft could say something along this line :
"If there are no route exchanges, then the only link bandwidth and
router CPU cycles consumed by BGP are due to the exchange of the BGP
KEEPALIVE messages".

>   that as the Internet grows,  the overall stability of the inter-AS 
> connectivity of the Internet can be controlled. 

>     Please specify how it is assumed to be "controlled", e.g. through
>     operational practices.

>          I believe historically this meant route-flap damping

I thought route-flap damping may also slow down route convergence
(i.e. may cause instability in turn...)

Regards
Cheng-Yin

From: Pekka Savola <[email-masked]>
To: Yakov Rekhter <[email-masked]>
cc: Alex Zinin <[email-masked]>, <[email-masked]>, <[email-masked]>
Subject: Re: [Idr] FYI: Last Call: 'A Border Gateway Protocol 4 (BGP-4)' to Draft Standard 
Sender: [email-masked]
Date: Thu, 29 Apr 2004 19:35:00 +0300 (EEST)

On Tue, 20 Apr 2004, Yakov Rekhter wrote:
> > >  2) The definition of active route is bad.  This fails in the 
> > >     situation where you need to export loopbacks/point-to-points to 
> > >     eBGP, but you have them in youro IGP.  The specification does not
> > >     consider them active (not used for forwarding), and they aren't 
> > >     exported.
> > > 
> > >     When the next-hop of the IGP route is the same as BGP next-hop,
> > >     obviously this is no problem.  Gargi Nalawade promised to submit 
> > >     text, but hasn't, and I think Yakov said something about being 
> > >     willing to incorporate that, but obviously hasn't.
> > >
> > >     This was discussed at idr thread:
> > 
> > >       issue 11.2: active route, again
> > 
> > > Otherwise, I think this was operationally good.
> > 
> > Sue, Yakov, please check if the ball was dropped re this one.
> 
> First of all, the consensus of the WG (as documented in 
> draft-ietf-idr-bgp-issues) is to have the following 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.
> 
> While this text does not cover the case described by Pekka, it does
> not preclude it either - handling the case described by Pekka
> is just outside the scope of the spec.
> 
> With this in mind I suggest that the case described by Pekka
> should be covered in a separate Internet Draft.

I think this is operationally a rather common (or even very common)  
scenario, and it would seem very disadvantageous not to tackle it in
this specification.  Further, there's major deployment of it (maybe
even multi-vendor -- probably) so there is considerable proof that it
works.

It should be the default behaviour of BGP as that's which makes the
most sense, operationally.  "BGP route is ... used by forwarding" does
not sufficiently cover the fact that people do use IGPs and there's
often overlap with IGP and BGP :).

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

From: Pekka Savola <[email-masked]>
To: Andrew Lange <[email-masked]>
cc: Pedro Roque Marques <[email-masked]>, Yakov Rekhter <[email-masked]>, <[email-masked]>
Subject: Re: [Idr] draft-lange-flexible-bgp-communities-02.txt as an IDR WG document
Sender: [email-masked]
Date: Thu, 29 Apr 2004 18:52:14 +0300 (EEST)

On Mon, 26 Apr 2004, Andrew Lange wrote:
> > Why do we need this in the first place?  To "standardize" commonly
> > used communities?  To give the users more tools to mess up their
> > routing, or to allow the users to make the ISP's policy more complex?
> 
> Here is some additional text for the introduction which, I hope, will 
> answer your questions.
> 
> There is a clear demand by BGP-savvy customers to have enhanced control 
> over their route announcements.  Today this demand is addressed by custom, 
> complex and difficult to manage community policies.  There is no 
> consistency across providers, except for the NO_EXPORT well known community 
> specified in RFC1997.  There are more well-known communities for common 
> policies specified in this document to help provide commonality and ease of 
> maintenance.  The current route policies required to provide enhanced BGP 
> services are very cumbersome.  The larger space provided in flexible 
> communities, and the introduction of neighbor classes significantly ease 
> the implementation and maintenance burdens for service providers.
> 
> Service providers also often tag their data based on where and from whom 
> they learned it (peer, customer, geographic origin).  The flexible 
> community, and the neighbor class application especially, make both 
> assigning inbound communities and matching on outbound peers significantly 
> easier and less error prone.
> 
> In addition, community values today are simply too small and too rigidly 
> defined to allow for the growth of the Internet.  For example, encoding 
> IPv6 address and an action to take on them is simply impossible.

This is clearer.

However, there are still many things I find disturbing, based on the 
quick glance:

 - operator losing the control of the network.  For us, the #1 thing
in the network is being able to control the traffic flows etc. as we
see fit except with the tools we give to the customers.  So, this
would seem to call for a statement that acting upon these communities
should be disabled unless explicitly enabled.

 - IPv4/IPv6 addresses: these are very poor keys for communities and 
probably should not be included -- or is there a specific usage case 
for them?  If there are needed, could these be implemented as a form 
of extended communities then?

 - usability for the customer: these are only applicable to the
customer if the customer has already negotiated with the ISP that the
ISP supports these communities, and has marked each and all the BGP
sessions it has accordingly ("peer", "upstream", "transit", etc.);  
they aren't useful otherwise.  This seems like a rather big leap to
me.

So what these are is a replacement for those ISPs who already 
community-based schemes to something "standardized".  It doesn't help 
much (except a little with set-up complexity) with other ISPs, so it 
isn't a silver bullet.

 - similar to IPv4/IPv6 address applicability, the applicability of 
VPN communities seems a bit fuzzy.  In addition to those the bandwidth 
community seems particularly unnecessary.

 - this appears to be confusing:

   The Flexible Community attribute MUST NOT be used to modify the BGP
   best path selection algorithm in a way that leads to forwarding
   loops.

   ==> does this allow that to happen?  Do we want to specify anything 
that would lead to that?  On the other hand, if we allow flexibility, 
the customer always has a possibility to shoot himself in the foot, 
and the protocol should not prevent that?

(btw, the refs need to be split to normative/informative, and an IPR 
statement needs to be added.)

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

From: Pekka Savola <[email-masked]>
To: Parantap Lahiri <[email-masked]>
cc: "'Gargi Nalawade'" <[email-masked]>, "'Pedro Roque Marques'" <[email-masked]>, <[email-masked]>, "'Yakov Rekhter'" <[email-masked]>
Subject: RE: [Idr] Soft-Notify as an IDR WG document
Sender: [email-masked]
Date: Thu, 29 Apr 2004 18:22:43 +0300 (EEST)

On Wed, 28 Apr 2004, Parantap Lahiri wrote:
> If the community has already made its mind that BGP is going to carry most
> of the services, the vendor community has accepted to undertake that
> incremental complexity and the operators have accepted to live with the
> risk, then resisting this draft from going to WG, is a mixed signal. If
> everyone HAS to live with multiple AFI/SAFI in the same session, they might
> as well get their control and not think about how many sets of sessions they
> should run in their infrastructure.

Why would anyone want have to live with multiple AFI/SAFI in the same
session if (s)he could set them up as separate sessions?

It seems that soft-notify accomplishes a subset of goals which 
multisession (and the like accomplish), but with a lot of additional 
issues.  The implementation or deployment complexity is probably 
roughly equal.  

So, this makes me wonder why soft-notify should go forward here at
all?

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

From: Srikanth Chavali <[email-masked]>
To: Yakov Rekhter <[email-masked]>
CC: [email-masked]
Subject: Re: [Idr] draft-chavali-bgp-prefixlimit-01.txt as an IDR WG document
Sender: [email-masked]
Date: Thu, 29 Apr 2004 10:44:16 -0400

In response to some of the comments made on this draft in the WG, we 
have made some changes  to the
01 version of the draft. The following is the link to the new draft 
which is based of 00 version as suggested by some.

http://ndzh.com/idr/Drafts/draft-chavali-bgp-prefixlimit-02.txt

This is has been submitted as an internet draft today. Please forward 
your your comments to the
list.

Thanks

srikanth chavali

Cc: [email-masked], [email-masked]
From: Thomas Barron <[email-masked]>
Subject: Re: [Idr] draft-chen-bgp-avoid-transition-01.txt
To: Enke Chen <[email-masked]>, [email-masked]
Sender: [email-masked]
Date: Wed, 28 Apr 2004 14:38:30 -0500

--Apple-Mail-4--352788604
Content-Type: text/plain;
	charset=US-ASCII;
	delsp=yes;
	format=flowed
Content-Transfer-Encoding: 7bit

On Apr 28, 2004, at 12:13 PM, Enke Chen wrote:

> Hi, Yakov and Sue:
>
> I would like to request that the draft  
> <draft-chen-bgp-avoid-transition-01.txt>
> be accepted as an IDR WG document. The draft was presented previosuly  
> at an
> IDR meeting. The algorithm described in the draft has been deployed  
> for several
> years.
>
> Thanks. -- Enke
>
> Message-Id: <[email-masked]>
> To: IETF-Announce: ;
> Reply-To: [email-masked]
> Subject: I-D ACTION:draft-chen-bgp-avoid-transition-01.txt
> Date: Tue, 20 Jan 2004 10:04:35 -0500
>
> - --NextPart
>
> 	Title		: Avoid BGP Best Path Transition from One External to Another
> 	Author(s)	: E. Chen, S. Sangli
> 	Filename	: draft-chen-bgp-avoid-transition-01.txt
> 	Pages		: 5
> 	Date		: 2004-1-19
> 	
> In this document we propose an algorithm that would help improve the
> overall network stability by avoiding BGP best path transition from
> one external to another (under certain conditions)
>
> http://www.ietf.org/internet-drafts/draft-chen-bgp-avoid-transition 
> -01.txt
>
>

Hi Enke,

    Attached is an email I sent to IDR that discusses some issues around  
your draft.  I don't think I have seen a reply.

   I will add now that since that note I've discussed and thought a bit  
more about your argument in 5.2, and I think it is quite clear (and is  
indeed the received opinion nowadays) that the essential ingredient in  
these route-oscillation problems is the interaction of Route Reflectors  
and IGP costs.  Using sufficiently high IGP costs between clusters will  
suffice to stop the churn both in your scenario and in other scenarios  
that don't involve router-id.  Indeed, in your scenario if by chance  
the times of arrival correspond in the same order to that determined by  
the router-ids the churn is not avoided by your algorithm either (the  
proof is tedious, but intuitively: start the scenario with the same  
ranking of tie-breakers, just use time-of-arrival instead of router-id;  
then realize that this order gets preserved as the oscillation proceeds  
because the repeatedly advertised-and-withdrawn route will always be  
"newest" and correspond to the largest router id in the original  
scenario.)

   But as I say in the attached, my argument is really with section 5.2,  
not with your overall proposal.  There are implementations that provide  
a knob to do just what you are documenting and I agree that the BGP  
spec should provide for this option.

    Best regards,

   Tom Barron

--Apple-Mail-4--352788604
Content-Type: text/plain;
	x-unix-mode=0600;
	name="reduce-route-oscillation-discussion.txt"
Content-Disposition: attachment;
	filename=reduce-route-oscillation-discussion.txt
Content-Transfer-Encoding: 7bit

>From [email-masked] Mon Nov 10 11:51:50 2003
From: Tom Barron <[email-masked]>
To: [email-masked]
Cc: Thomas P Barron <[email-masked]>
Message-ID: <[email-masked]>

Enke, Srihari, et. al:

I have some questions about draft-chen-bgp-avoid-transition-00.txt.
I'm glad to see this draft since there are implementations out there
using the route-selection algorithm this draft proposes, and since the
proposed algorith is not what is documented in RFC1771 or in
draft-ietf-idr-bgr4-22.txt section 9.1.2.2.

First, is it the intent of this draft that the proposed algorithm 
should *replace* the algorithm currently documented, or just that
it be added as an option?

Second, while I think the claim in 5.1 that the proposed algorithm
avoids an unnecessary best path transition is quite straightforward,
there ought to be some discussion of concerns that have been expressed
about the consequent lack of determinism in route selection.  See
for example section 7.1.4 of draft-ietf-idr-bgp4-experience-protocol-03.txt
and appendix A of "Guidelines for Interdomain Traffic Engineering" by
Feamster, Borkenhagen, and Rexford.  I'm not personally convinced
that this local indeterminism is a real big deal, but I do think it
needs some discussion in your draft.

Third, I found the argument at 5.2 to the effect that the proposed
algorithm reduces route oscillation a bit unclear.  Maybe just a bit
more text is needed, but it seems to me that the really essential
ingredient in your setup in figure 1 and figure 2 is not the router
ID, but the high intracluster IGP metric.  Indeed, though you cite
RFC3345, that work focuses on IGP metrics, not router ID, as a
critical factor for "type 1" oscillation scenarios (yours appears to
be a type 1 variant.)  If adjusting IGP metrics is sufficient to fix
both your oscillation scenario and other type 1 scenarios, but
shifting from Router ID selection to the proposed time-of-arrival
algorithm is not sufficient for type 1 scenarios in general, then the
contribution of the proposed algorithm to the route oscillation
problem does not seem very decisive.  On the other hand, if using the
proposed time-of-arrival algorithm yields a general solution to
oscillation problems, then this reader at least did not get that from
the draft as currently written.

I'm glad you folks wrote this draft.  I hope it's clear that I'm
not against your proposal, but rather want to address some gaps
in my own understanding of the issues that surround it.

- Tom Barron

--Apple-Mail-4--352788604
Content-Type: text/plain;
	charset=US-ASCII;
	format=flowed
Content-Transfer-Encoding: 7bit

--Apple-Mail-4--352788604--

From: Pedro Roque Marques <[email-masked]>
To: Enke Chen <[email-masked]>
Cc: [email-masked], [email-masked], [email-masked]
Subject: [Idr] draft-chen-bgp-avoid-transition-01.txt
Sender: [email-masked]
Date: Wed, 28 Apr 2004 15:41:17 -0700 (PDT)

Enke Chen writes:

> Hi, Yakov and Sue: I would like to request that the draft
> <draft-chen-bgp-avoid-transition-01.txt> be accepted as an IDR WG
> document. The draft was presented previosuly at an IDR meeting. The
> algorithm described in the draft has been deployed for several
> years.

my turn to cheer: i believe this should be a wg document.

  Pedro.

From: Parantap Lahiri <[email-masked]>
Subject: RE: [Idr] Soft-Notify as an IDR WG document
To: "'Pedro Roque Marques'" <[email-masked]>
Cc: [email-masked], "'Yakov Rekhter'" <[email-masked]>
Importance: Normal
Sender: [email-masked]
Date: Wed, 28 Apr 2004 17:29:01 -0400

I am not sure if it was a complete misrepresentation of your argument. You
do mention in your mail that 

>> Besides multisession is 10x easier to implement and deploy since it can
use existing state machines.

As an operator we definitely do keep network management implications in our
mind while choosing any mechanism and I appreciate your concern there. And
the fact that adding BGP complexity is worrying some is a good sign. 

Though whatever choice you make has tactical as well as strategic
implications. BGP is becoming a generic protocol to transport not only
routing but also service information. Now the question is whether to control
these information flows at a higher AFI/SAFI level or to split them apart
and tie them down to lower tcp session level? Definitely the operators are
familiar with managing BGP TCP sessions, but if you are too quick to arrive
at the latter alternative and discard the former one for lack of NMS
functions you may run the risk of not assigning the right function to the
right component. I have no idea how the number of AFI/SAFI and their
functions there-of are going to evolve in future, but if we start bundling
them together in subsets and tie the control mechanisms of each subset to a
tcp session, it has to be more conscious and well thought decision than a
quick tactical one depending on short-term merit.

I will be interested in understanding how multisession BGP stacks up with
running completely separate BGP between the same end points. [I understand
that its not doable now, but just trying to gauge the merit]

-----Original Message-----
From: Pedro Roque Marques [mailto:[email-masked]] 
Sent: Wednesday, April 28, 2004 12:46 PM
To: Parantap Lahiri
Cc: [email-masked]; 'Yakov Rekhter'
Subject: RE: [Idr] Soft-Notify as an IDR WG document

Parantap Lahiri writes:

> Now, here is this thread, where a part of the same community is
> suggesting that giving individual soft control to each AFI/SAFI pair
> would make BGP protocol implementation more complicated than
> necessary and we should push the complexity to the operator
> world. That is fine and in some ways sane, but in most ways
> confusing.

This is a misrepresentation of the argument.

The point is that you cannot achieve individual control for afi/safi
without adding the necessary diagnostics and support for tools and
management on the operator side. Not to mention understanding of how
mecanisms work.

The multisession draft is nicer alternative for several reasons
including the fact that it fits into the current management framework
and follows a model understood by all.

The point is not wether to achieve a given end goal but to find the
approach that gets us there with less pain. and which can be built
incrementally. 

As an operator i would expect you to be supportive of the need to
consider the network management implications before picking a
solution.

  Pedro. 

Content-class: urn:content-classes:message
From: "Susan Hares" <[email-masked]>
To: "Enke Chen" <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>
Subject: [Idr] RE: draft-chen-bgp-avoid-transition-01.txt
Sender: [email-masked]
Date: Wed, 28 Apr 2004 13:19:08 -0400

Enke:

Please drop me a note to indicate where the
draft has been deployed and in what routers.

Are there inter-operable implementations?

Sue

-----Original Message-----
From: Enke Chen [mailto:[email-masked]]
Sent: Wednesday, April 28, 2004 1:13 PM
To: [email-masked]; Susan Hares
Cc: [email-masked]
Subject: draft-chen-bgp-avoid-transition-01.txt

Hi, Yakov and Sue:

I would like to request that the draft <draft-chen-bgp-avoid-transition-01.txt>
be accepted as an IDR WG document. The draft was presented previosuly at an
IDR meeting. The algorithm described in the draft has been deployed for several
years.

Thanks. -- Enke

Message-Id: <[email-masked]>
To: IETF-Announce: ;
From: [email-masked]
Reply-To: [email-masked]
Subject: I-D ACTION:draft-chen-bgp-avoid-transition-01.txt
Date: Tue, 20 Jan 2004 10:04:35 -0500

- --NextPart

	Title		: Avoid BGP Best Path Transition from One External to Another
	Author(s)	: E. Chen, S. Sangli
	Filename	: draft-chen-bgp-avoid-transition-01.txt
	Pages		: 5
	Date		: 2004-1-19
	
In this document we propose an algorithm that would help improve the
overall network stability by avoiding BGP best path transition from
one external to another (under certain conditions)

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-chen-bgp-avoid-transition-01.txt

To: [email-masked], [email-masked]
Cc: [email-masked]
From: Enke Chen <[email-masked]>
Subject: [Idr] draft-chen-bgp-avoid-transition-01.txt
Sender: [email-masked]
Date: Wed, 28 Apr 2004 10:13:29 -0700

Hi, Yakov and Sue:

I would like to request that the draft <draft-chen-bgp-avoid-transition-01.txt>
be accepted as an IDR WG document. The draft was presented previosuly at an
IDR meeting. The algorithm described in the draft has been deployed for several
years.

Thanks. -- Enke

Message-Id: <[email-masked]>
To: IETF-Announce: ;
From: [email-masked]
Reply-To: [email-masked]
Subject: I-D ACTION:draft-chen-bgp-avoid-transition-01.txt
Date: Tue, 20 Jan 2004 10:04:35 -0500

- --NextPart

	Title		: Avoid BGP Best Path Transition from One External to Another
	Author(s)	: E. Chen, S. Sangli
	Filename	: draft-chen-bgp-avoid-transition-01.txt
	Pages		: 5
	Date		: 2004-1-19
	
In this document we propose an algorithm that would help improve the
overall network stability by avoiding BGP best path transition from
one external to another (under certain conditions)

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-chen-bgp-avoid-transition-01.txt

Content-class: urn:content-classes:message
Subject: RE: [Idr] draft-keyur-prefixlimit-orf-00
From: "Susan Hares" <[email-masked]>
To: "John G. Scudder" <[email-masked]>
Cc: <[email-masked]>
Sender: [email-masked]
Date: Wed, 28 Apr 2004 12:58:17 -0400

John:

Read document before I sent the message. 

Complexity came in -01 came in allowing ORFs
as well as the global limits.  We set it 
up as an option and worked out the coordination deals

So, we'll just trying to allow both methods.

Capabilities and Dynamic capabilities provide
a simple way to determine the 3 prefix limits:
warning, stop receiving and disconnect per peer.
The support of dynamic allows re-negotiation easily on
a connection basis. 

ORFs is too heavy weighted for that simple focus. 
If we are trying to travel light, ORFs are like
adding a 2 ton weight to your baggage. 

Sue

-----Original Message-----
From: John G. Scudder [mailto:[email-masked]]
Sent: Wednesday, April 28, 2004 12:50 PM
To: Susan Hares
Cc: [email-masked]
Subject: RE: [Idr] draft-keyur-prefixlimit-orf-00

Sue,

Sorry you feel that way.  As you might imagine, I 
have a different perspective, which is that I 
tried to suggest a way to simplify the 
specification, but instead found the -01 version 
to be more complex.  Since I clearly didn't 
communicate the idea effectively enough at the 
Minneapolis meeting it seemed like it would be 
more productive to express it in the form of a 
fully written specification instead of a list of 
comments.

If you haven't read 
draft-keyur-prefixlimit-orf-00 then please do 
(it's short).  If having read it you do think 
that it's more complex, I'd love to discuss the 
reasons.  Of course, I would also like to hear 
what other members of the WG think.

We'd be happy to make reasonable changes to the 
acknowledgement section if you'd like to 
communicate what the problem is, either on or off 
list.

Respectfully,

--John

At 12:36 PM -0400 4/28/04, Susan Hares wrote:
>John:
>
>Well this is amazing.  Since you suggested the complexity...
>Perhaps you changed your mind.
>
>We put the complex ORF policy in because you state
>Cisco did not support dynamic configuration.
>In simplifying this, I do not find people wanting to
>go to an ORF policy. 
>
>Sue
>
>PS - your acknowledgement section is problematic.
>
>-----Original Message-----
>From: John G. Scudder [mailto:[email-masked]]
>Sent: Wednesday, April 28, 2004 11:19 AM
>To: [email-masked]
>Subject: [Idr] draft-keyur-prefixlimit-orf-00
>
>
>Folks,
>
>As others have noted, while the underlying goal of
>draft-chavali-bgp-prefixlimit-01 seems worthwhile, we think the
>actual mechanisms proposed are more complex than is necessary.
>
>We've written another draft which we think provides the needed
>functionality with less complexity, along the lines of what I
>suggested at the meeting in Minneapolis.  In summary we introduce a
>new ORF-type which carries a 32 bit prefix limit, and also use the
>PERMIT/DENY flag to signal whether enforcement of the limit will be
>done by dropping the session or not.  The draft is a tad over four
>pages plus six pages of IETF boilerplate.
>
>The draft has been submitted as an I-D.  Until it's available in the
>usual places, you can find it at
>ftp://ftpeng.cisco.com/jgs/draft-keyur-prefixlimit-orf-00.txt
>
>Discussion of the draft would be welcome.
>
>Thanks,
>
>--John
>

To: "Susan Hares" <[email-masked]>
From: "John G. Scudder" <[email-masked]>
Subject: RE: [Idr] draft-keyur-prefixlimit-orf-00
Cc: <[email-masked]>
Sender: [email-masked]
Date: Wed, 28 Apr 2004 12:50:28 -0400

Sue,

Sorry you feel that way.  As you might imagine, I 
have a different perspective, which is that I 
tried to suggest a way to simplify the 
specification, but instead found the -01 version 
to be more complex.  Since I clearly didn't 
communicate the idea effectively enough at the 
Minneapolis meeting it seemed like it would be 
more productive to express it in the form of a 
fully written specification instead of a list of 
comments.

If you haven't read 
draft-keyur-prefixlimit-orf-00 then please do 
(it's short).  If having read it you do think 
that it's more complex, I'd love to discuss the 
reasons.  Of course, I would also like to hear 
what other members of the WG think.

We'd be happy to make reasonable changes to the 
acknowledgement section if you'd like to 
communicate what the problem is, either on or off 
list.

Respectfully,

--John

At 12:36 PM -0400 4/28/04, Susan Hares wrote:
>John:
>
>Well this is amazing.  Since you suggested the complexity...
>Perhaps you changed your mind.
>
>We put the complex ORF policy in because you state
>Cisco did not support dynamic configuration.
>In simplifying this, I do not find people wanting to
>go to an ORF policy. 
>
>Sue
>
>PS - your acknowledgement section is problematic.
>
>-----Original Message-----
>From: John G. Scudder [mailto:[email-masked]]
>Sent: Wednesday, April 28, 2004 11:19 AM
>To: [email-masked]
>Subject: [Idr] draft-keyur-prefixlimit-orf-00
>
>
>Folks,
>
>As others have noted, while the underlying goal of
>draft-chavali-bgp-prefixlimit-01 seems worthwhile, we think the
>actual mechanisms proposed are more complex than is necessary.
>
>We've written another draft which we think provides the needed
>functionality with less complexity, along the lines of what I
>suggested at the meeting in Minneapolis.  In summary we introduce a
>new ORF-type which carries a 32 bit prefix limit, and also use the
>PERMIT/DENY flag to signal whether enforcement of the limit will be
>done by dropping the session or not.  The draft is a tad over four
>pages plus six pages of IETF boilerplate.
>
>The draft has been submitted as an I-D.  Until it's available in the
>usual places, you can find it at
>ftp://ftpeng.cisco.com/jgs/draft-keyur-prefixlimit-orf-00.txt
>
>Discussion of the draft would be welcome.
>
>Thanks,
>
>--John
>

From: Pedro Roque Marques <[email-masked]>
To: Parantap Lahiri <[email-masked]>
Cc: [email-masked], "'Yakov Rekhter'" <[email-masked]>
Subject: RE: [Idr] Soft-Notify as an IDR WG document
Sender: [email-masked]
Date: Wed, 28 Apr 2004 09:46:14 -0700 (PDT)

Parantap Lahiri writes:

> Now, here is this thread, where a part of the same community is
> suggesting that giving individual soft control to each AFI/SAFI pair
> would make BGP protocol implementation more complicated than
> necessary and we should push the complexity to the operator
> world. That is fine and in some ways sane, but in most ways
> confusing.

This is a misrepresentation of the argument.

The point is that you cannot achieve individual control for afi/safi
without adding the necessary diagnostics and support for tools and
management on the operator side. Not to mention understanding of how
mecanisms work.

The multisession draft is nicer alternative for several reasons
including the fact that it fits into the current management framework
and follows a model understood by all.

The point is not wether to achieve a given end goal but to find the
approach that gets us there with less pain. and which can be built
incrementally. 

As an operator i would expect you to be supportive of the need to
consider the network management implications before picking a
solution.

  Pedro. 

From: Michael Dell <[email-masked]>
To: "'Yakov Rekhter'" <[email-masked]>, [email-masked]
Subject: RE: [Idr] Last Call on draft-ietf-idr-rfc2796bis-00.txt
Sender: [email-masked]
Date: Tue, 27 Apr 2004 14:20:55 +0100

Yakov

I have no particular comments on or issues with the draft.  However, we were
slightly surprised by the time difference between this draft being published
and then moving to last call - about 2 minutes by my count.  I can't see any
details on what is motivating this draft in the proceedings of the last
couple of IETF meetings.  

Apologies if I'm the only reader of this list that doesn't know the history
behind this modification, but perhaps you could summarise for me, either on
or off list?

Regards

Mike Dell
Networking Protocols Group
Data Connection Ltd
Tel: +44 20 8366 1177
Fax: +44 20 8367 8501
E-mail: [email-masked]
Web: http://www.dataconnection.com

-----Original Message-----
From: Yakov Rekhter [mailto:[email-masked]]
Sent: 16 April 2004 22:21
To: [email-masked]
Subject: [Idr] Last Call on draft-ietf-idr-rfc2796bis-00.txt

Folks,

During the Last Call it would be greatly appreciated if folks would
read the document and comment on it to the IDR mailing list. In
other words, we need "yes, looks good" or "should fix this and
that", not just silence.

Thanks in advance.

Yakov.

Date:    Wed, 14 Apr 2004 13:36:09 -0700
From:    Yakov Rekhter <[email-masked]>
To:      [email-masked]
Subject: [Idr] WG Last Call on draft-ietf-idr-rfc2796bis-00.txt

Folks,

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

- - --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 Route Reflection - An Alternative to Full Mesh
IB
GP
	Author(s)	: T. Bates, et al.
	Filename	: draft-ietf-idr-rfc2796bis-00.txt
	Pages		: 11
	Date		: 2004-4-14

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of the
mess
age.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Send a message to:
	[email-masked].
In the body type:

- - --NextPart

- - --OtherAccess

Content-Type: text/plain

ENCODING mime

- - --OtherAccess

Content-Type: text/plain

- - --OtherAccess--

- - --NextPart--

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

Content-class: urn:content-classes:message
Subject: RE: [Idr] draft-keyur-prefixlimit-orf-00
From: "Susan Hares" <[email-masked]>
To: "John G. Scudder" <[email-masked]>, <[email-masked]>
Sender: [email-masked]
Date: Wed, 28 Apr 2004 12:36:14 -0400

John:

Well this is amazing.  Since you suggested the complexity...
Perhaps you changed your mind. 

We put the complex ORF policy in because you state
Cisco did not support dynamic configuration. 
In simplifying this, I do not find people wanting to
go to an ORF policy.  

Sue

PS - your acknowledgement section is problematic.

-----Original Message-----
From: John G. Scudder [mailto:[email-masked]]
Sent: Wednesday, April 28, 2004 11:19 AM
To: [email-masked]
Subject: [Idr] draft-keyur-prefixlimit-orf-00

Folks,

As others have noted, while the underlying goal of 
draft-chavali-bgp-prefixlimit-01 seems worthwhile, we think the 
actual mechanisms proposed are more complex than is necessary.

We've written another draft which we think provides the needed 
functionality with less complexity, along the lines of what I 
suggested at the meeting in Minneapolis.  In summary we introduce a 
new ORF-type which carries a 32 bit prefix limit, and also use the 
PERMIT/DENY flag to signal whether enforcement of the limit will be 
done by dropping the session or not.  The draft is a tad over four 
pages plus six pages of IETF boilerplate.

The draft has been submitted as an I-D.  Until it's available in the 
usual places, you can find it at 
ftp://ftpeng.cisco.com/jgs/draft-keyur-prefixlimit-orf-00.txt

Discussion of the draft would be welcome.

Thanks,

--John

From: Parantap Lahiri <[email-masked]>
Subject: RE: [Idr] Soft-Notify as an IDR WG document
To: "'Pekka Savola'" <[email-masked]>, "'Gargi Nalawade'" <[email-masked]>
Cc: "'Pedro Roque Marques'" <[email-masked]>, [email-masked], "'Yakov Rekhter'" <[email-masked]>
Importance: Normal
Sender: [email-masked]
Date: Wed, 28 Apr 2004 11:54:48 -0400

The response to this particular thread has been particularly interesting. 

So long the dominant story from this community has been to put all new
services and new features on the existing BGP protocol, which has an
established base, and keep the operator's world easy and simple. The
argument was that the vendors were good enough to handle all the
complexities in the protocol implementation and the operators need not worry
about code issues as much. So the (over)loading of BGP continues. Some
people, realizing that the BGP train was coming too fast and too strong,
stopped arguing.

Now, here is this thread, where a part of the same community is suggesting
that giving individual soft control to each AFI/SAFI pair would make BGP
protocol implementation more complicated than necessary and we should push
the complexity to the operator world. That is fine and in some ways sane,
but in most ways confusing. 

If the community has already made its mind that BGP is going to carry most
of the services, the vendor community has accepted to undertake that
incremental complexity and the operators have accepted to live with the
risk, then resisting this draft from going to WG, is a mixed signal. If
everyone HAS to live with multiple AFI/SAFI in the same session, they might
as well get their control and not think about how many sets of sessions they
should run in their infrastructure.

If the BGP session has to be split it should be split across the
infrastructure and service boundary. The infrastructure layer should run
hardened well tested BGP code and the service layer could run new loaded BGP
(or ??) code which will have individual control of individual services
built-in.

-Parantap

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Pekka
Savola
Sent: Tuesday, April 27, 2004 6:17 AM
To: Gargi Nalawade
Cc: Pedro Roque Marques; [email-masked]; Yakov Rekhter
Subject: Re: [Idr] Soft-Notify as an IDR WG document

On Mon, 26 Apr 2004, Gargi Nalawade wrote:
> > I can come up w/ 2 simple scenarios:
> > a) you want fate sharing... i.e. intentionally tie afis so that when
> > one fails the other does fail also. (both are required to provide a
> > service for instance).
> > b) you don't want to deal w/ the extra complexity of monitoring
> > multiple substates and prefer to deal w/ a binary "works" / "broken".
> > 
> > In both these examples which i consider rather realistic adding
> > notifications/negotiation does not provide value.
> 
> Give me one Provider who says that because IPv4 Unicast in their network
> is needed for providing some IPv4 Multicast service, IPv4 unicast should
> fail whenever IPv4 Multicast has an error or a CEASE notification.

And when would such an error occur?  If you have shared 
unicast/multicast infrastructure, pretty much never, unless both would 
be equally impacted.   And when the topologies aren't congruent, then 
you will notice it in any case.

I share Pedro's concerns about the applicability.  If operators see it
important to protect AFI/SAFIs from each other, something like
"multisession" seems like an obvious choice.  If there is an obvious
choice, it will be deployed as well.

It seems like we're talking about a solution which would become 
interesting either in the scenario where 1) operator is not 
(sufficiently interested) for doing something like multi-session BGP 
(but could be interested in something like this), or 2) operator 
doesn't want to wait for multi-session, and wants something sooner.

Both of these scenarios seem very questionable to me.

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

To: Yakov Rekhter <[email-masked]>
From: "John G. Scudder" <[email-masked]>
Subject: Re: [Idr] draft-chavali-bgp-prefixlimit-01.txt as an IDR WG document
Cc: [email-masked]
Sender: [email-masked]
Date: Wed, 28 Apr 2004 11:19:59 -0400

(Following up to original thread for completeness.)

I don't think that the draft as it stands is appropriate as a WG doc 
because it's rather too complex.  As noted in my other message, we've 
submitted another draft, draft-keyur-prefixlimit-orf-00, which 
represents an alternative approach to achieving the same goals.

Regards,

--John

At 6:59 AM -0700 4/15/04, Yakov Rekhter wrote:
>Folks,
>
>We receive a request to accept draft-chavali-bgp-prefixlimit-01.txt
>as an IDR WG document. Please send comments to the list. The deadline
>for comments is April 29, 2004.
>
>Yakov.

To: [email-masked]
From: "John G. Scudder" <[email-masked]>
Subject: [Idr] draft-keyur-prefixlimit-orf-00
Sender: [email-masked]
Date: Wed, 28 Apr 2004 11:19:27 -0400

Folks,

As others have noted, while the underlying goal of 
draft-chavali-bgp-prefixlimit-01 seems worthwhile, we think the 
actual mechanisms proposed are more complex than is necessary.

We've written another draft which we think provides the needed 
functionality with less complexity, along the lines of what I 
suggested at the meeting in Minneapolis.  In summary we introduce a 
new ORF-type which carries a 32 bit prefix limit, and also use the 
PERMIT/DENY flag to signal whether enforcement of the limit will be 
done by dropping the session or not.  The draft is a tad over four 
pages plus six pages of IETF boilerplate.

The draft has been submitted as an I-D.  Until it's available in the 
usual places, you can find it at 
ftp://ftpeng.cisco.com/jgs/draft-keyur-prefixlimit-orf-00.txt

Discussion of the draft would be welcome.

Thanks,

--John

To: Pekka Savola <[email-masked]>
cc: [email-masked]
Subject: Re: [Idr] Last Call on draft-ietf-idr-rfc2796bis-00.txt 
From: Yakov Rekhter <[email-masked]>
Sender: [email-masked]
Date: Tue, 27 Apr 2004 08:10:41 -0700

Pekka,

> On Fri, 16 Apr 2004, Yakov Rekhter wrote:
> > During the Last Call it would be greatly appreciated if folks would
> > read the document and comment on it to the IDR mailing list. In
> > other words, we need "yes, looks good" or "should fix this and
> > that", not just silence.
> 
> In general, I think this should be rather close to being ready for 
> going forward.
> 
> A few quick comments:
> 
>  - the text could use a lot more updates, but is readable as it is.
>  
>  - where are the implementation & interop reports?

Enke is working on it (see his e-mail to the IDR mailing list on 4/14/2004).

>  - several ID-nits or other process issues must be fixed, at least:
>   o Status of this memo, Abstract, etc. must be unnumbered sections 
>     (typically Introduction is section number 1)

ok.

>   o No references in the abstract.

ok.

>   o One cannot have normative references to documents of lower 
>     maturity level.  I suggest moving everything except [1] (or 
>     maybe also [7]) to a new Informational References section.

Correct - [1] should go into the Normative Reference section, the
rest should go into the Non-normative Reference section.

>   o The document should probably say (in Abstract and Introduction) 
>     that this document Obsoletes both 2796 and 1966 (note 2796 only 
>     Updates 1966, which was probably a bug.)?

Ok.

>   o Standard IPR statement is needed at the end even if there is is no 
>     IPR.  The date in the copyright statement is 4 years old as well..

ok.

>   o every empty line in this memo is duplicated (due to flawed 
>     DOS/WINDOWS -> Unix conversion?)

ok.

>  - food for thought: should we kill two birds in one stone, and also 
>    declare RFC1863 ("A BGP/IDRP Route Server alternative to a full 
>    mesh routing") historic?  Is that useful anymore?

This is a good question. May I suggest you'll bring it up to the
IDR mailing list after we'll finish the WG Last Call on this document
(as it deserves discussion on its own).

>  - A few rewordings I spotted (I grew bored with the text soon after 
>    the abstract, as there would have been a lot of changes):
> 
>                                          Currently in the Internet BGP
>    AS.
   
> ==> s/Currently in the Internet BGP deployments are configured such 
> that that/Typically/ (the same in the Introduction)
>                                                                              
   
>    information, as is common in many of todays internet networks.
>                                                                              
   
> ==> s/todays internet/today's Internet/

Sure.

Yakov.

Content-class: urn:content-classes:message
Subject: RE: [Idr] draft-chavali-bgp-prefixlimit-01.txt as an IDR WG document 
From: "Susan Hares" <[email-masked]>
To: "Yakov Rekhter" <[email-masked]>
Cc: <[email-masked]>
Sender: [email-masked]
Date: Tue, 27 Apr 2004 10:17:15 -0400

Narrowing down to one would be fine.

Sue

-----Original Message-----
From: Yakov Rekhter [mailto:[email-masked]]
Sent: Tuesday, April 27, 2004 9:18 AM
To: Susan Hares
Cc: [email-masked]
Subject: Re: [Idr] draft-chavali-bgp-prefixlimit-01.txt as an IDR WG
document 

Sue,

<with the WG co-chair hat off>

If one uses ORF to pass prefix limit, then I think there is no need
to also exchange this limit in the BGP Open message - all you
need to carry in the Open message is the Capability that indicates support
for the prefix limit ORF type (and the appropriate AFI/SAFI). This
is because of the way how ORF operates (quoting from the ORF spec):

   Consider a BGP speaker that advertises the Cooperative Route Filtering
   Capability indicating its willingness to receive a particular set of
   <AFI, SAFI, ORF-Type> from its peer, and that receives the Cooperative
   Route Filtering Capability indicating the desire of the peer to send a
   particular set <AFI, SAFI, ORF-Type> to the speaker. If for a given
   <AFI, SAFI> the intersection between these two sets are not-empty, the
   speaker SHOULD NOT advertise to the peer any routes with that <AFI,
   SAFI> prior to receiving from the peer any ROUTE-REFRESH message
   carrying that <AFI, SAFI>, where the message could be either without
   any ORF entries, or with one or more ORF entry and When-to-refresh
   field set to IMMEDIATE. If, on the other hand, for a given <AFI, SAFI>
   the intersection between these two sets is empty, the speaker SHOULD
   follow normal BGP procedures.

In the above pay especial attention to the "speaker SHOULD NOT advertise" 
part.

I am also a bit concerned with support for two ways of advertising
the prefix limit: one via OFR and another via Dynamic Capabilities.
Why narrowing this down to one is not enough ?

Yakov.

To: Michael Dell <[email-masked]>
cc: [email-masked]
Subject: Re: [Idr] Last Call on draft-ietf-idr-rfc2796bis-00.txt 
From: Yakov Rekhter <[email-masked]>
Sender: [email-masked]
Date: Tue, 27 Apr 2004 06:33:07 -0700

Mike,

> Yakov
> 
> I have no particular comments on or issues with the draft.  However, we were
> slightly surprised by the time difference between this draft being published
> and then moving to last call - about 2 minutes by my count.  I can't see any
> details on what is motivating this draft in the proceedings of the last
> couple of IETF meetings.  
> 
> Apologies if I'm the only reader of this list that doesn't know the history
> behind this modification, but perhaps you could summarise for me, either on
> or off list?

The main purpose of this draft is to update the current BGP Route
Reflector spec to document how BGP route selection is done
in the presence of BGP Route Reflectors.

Yakov.

To: "Susan Hares" <[email-masked]>
cc: [email-masked]
Subject: Re: [Idr] draft-chavali-bgp-prefixlimit-01.txt as an IDR WG document 
From: Yakov Rekhter <[email-masked]>
Sender: [email-masked]
Date: Tue, 27 Apr 2004 06:17:41 -0700

Sue,

<with the WG co-chair hat off>

If one uses ORF to pass prefix limit, then I think there is no need
to also exchange this limit in the BGP Open message - all you
need to carry in the Open message is the Capability that indicates support
for the prefix limit ORF type (and the appropriate AFI/SAFI). This
is because of the way how ORF operates (quoting from the ORF spec):

   Consider a BGP speaker that advertises the Cooperative Route Filtering
   Capability indicating its willingness to receive a particular set of
   <AFI, SAFI, ORF-Type> from its peer, and that receives the Cooperative
   Route Filtering Capability indicating the desire of the peer to send a
   particular set <AFI, SAFI, ORF-Type> to the speaker. If for a given
   <AFI, SAFI> the intersection between these two sets are not-empty, the
   speaker SHOULD NOT advertise to the peer any routes with that <AFI,
   SAFI> prior to receiving from the peer any ROUTE-REFRESH message
   carrying that <AFI, SAFI>, where the message could be either without
   any ORF entries, or with one or more ORF entry and When-to-refresh
   field set to IMMEDIATE. If, on the other hand, for a given <AFI, SAFI>
   the intersection between these two sets is empty, the speaker SHOULD
   follow normal BGP procedures.

In the above pay especial attention to the "speaker SHOULD NOT advertise" 
part.

I am also a bit concerned with support for two ways of advertising
the prefix limit: one via OFR and another via Dynamic Capabilities.
Why narrowing this down to one is not enough ?

Yakov.

From: Pekka Savola <[email-masked]>
To: Gargi Nalawade <[email-masked]>
cc: Pedro Roque Marques <[email-masked]>, <[email-masked]>, Yakov Rekhter <[email-masked]>
Subject: Re: [Idr] Soft-Notify as an IDR WG document
Sender: [email-masked]
Date: Tue, 27 Apr 2004 13:16:34 +0300 (EEST)

On Mon, 26 Apr 2004, Gargi Nalawade wrote:
> > I can come up w/ 2 simple scenarios:
> > a) you want fate sharing... i.e. intentionally tie afis so that when
> > one fails the other does fail also. (both are required to provide a
> > service for instance).
> > b) you don't want to deal w/ the extra complexity of monitoring
> > multiple substates and prefer to deal w/ a binary "works" / "broken".
> > 
> > In both these examples which i consider rather realistic adding
> > notifications/negotiation does not provide value.
> 
> Give me one Provider who says that because IPv4 Unicast in their network
> is needed for providing some IPv4 Multicast service, IPv4 unicast should
> fail whenever IPv4 Multicast has an error or a CEASE notification.

And when would such an error occur?  If you have shared 
unicast/multicast infrastructure, pretty much never, unless both would 
be equally impacted.   And when the topologies aren't congruent, then 
you will notice it in any case.

I share Pedro's concerns about the applicability.  If operators see it
important to protect AFI/SAFIs from each other, something like
"multisession" seems like an obvious choice.  If there is an obvious
choice, it will be deployed as well.

It seems like we're talking about a solution which would become 
interesting either in the scenario where 1) operator is not 
(sufficiently interested) for doing something like multi-session BGP 
(but could be interested in something like this), or 2) operator 
doesn't want to wait for multi-session, and wants something sooner.

Both of these scenarios seem very questionable to me.

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

From: Robert Raszuk <[email-masked]>
Reply-To: [email-masked]
Organization: Signature: http://www.employees.org/~raszuk/sig/
To: [email-masked]
CC: Pedro Roque Marques <[email-masked]>, [email-masked], Yakov Rekhter <[email-masked]>
Subject: Re: [Idr] Soft-Notify as an IDR WG document
Sender: [email-masked]
Date: Tue, 27 Apr 2004 00:25:20 -0700

All,

> The deployment part of the equation doesn't...
> Ops people understand the bgp state machine... its easy to add the
> concept of multisession on top. Its is a much more significant
> chalenge to add this per nlri up/down negotiation.

Yes I agree that soft notify adds a new layer of troubleshooting & 
deployment complexity. While today most of the monitoring tools or SNMP 
work on a per session granularity it would require to be immediately 
updated to go deeper to the AFI/SAFI per session levels. Otherwise 
operators may have a really hard time to monitor what is going on. And 
unless they know that one AFI/SAFI is down under a working BGP session 
their NOC can't log in and fix the problem hence end customers may be 
impacted. Maybe it goes without saying that modifications to a number of 
show commands would be also required.

On the other hand what is not clear to me is why do we equate 
Soft-Notify to address just the session reset piece. For whatever it is 
worth my observations of various BGP deployments today lead me to 
believe that BGP code in most implementations does not trigger session 
Notifications in the first place that often ;). So I am not sure if we 
are solving a real problem here. And the problem at hand should be 
solved with the simplest solution so multisession seems to fit the bill. 
Moreover multisession seems to be an automation to today's manual 
session separation which some operators are already using.

That said I think one could observe that Soft-Notify does not just 
address the reset problem. Well maybe the name of the draft is wrong :) 
The functionality I support in it is to inform the peer about some BGP 
actions or events without resetting the session. As original INFORM 
draft was proposing and very similar to what Enke's cease msg defines 
for the Notification itself.

Just an real live example ...

BGP draft says:

    A BGP speaker MAY support the ability to impose an (locally config-
    ured) upper bound on the number of address prefixes the speaker is
    willing to accept from a neighbor. When the upper bound is reached,
    the speaker (under control of local configuration) either (a) dis-
    cards new address prefixes from the neighbor (while maintaining BGP
    connection with the neighbor), or (b) terminates the BGP connection
    with the neighbor. If the BGP speaker decides to terminate its BGP
    connection with a neighbor because the number of address prefixes
    received from the neighbor exceeds the locally configured upper
    bound, then the speaker MUST send to the neighbor a NOTIFICATION mes-
    sage with the Error Code Cease. The speaker MAY also log this
    locally.

So in the case operator choose to select option (a) above his EBGP peer 
has no way of knowing about action of his peer.

So maybe a good approach would be to reword the draft to primarily 
deliver the BGP event messaging between peers not causing the session 
resets while still allowing an optional vendor specific pool of msg types.

Therefor market and operators could decide which messages/actions are 
useful and which not ... In that light I would support to accept the 
reworded draft as an IDR WG doc.

R.

From: Robert Raszuk <[email-masked]>
Reply-To: [email-masked]
Organization: Signature: http://www.employees.org/~raszuk/sig/
To: "John G. Scudder" <[email-masked]>
CC: [email-masked]
Subject: Re: [Idr] Multisession as WG doc
Sender: [email-masked]
Date: Mon, 26 Apr 2004 23:37:13 -0700

I support multisession draft to become an IDR WG doc.

R.

 > John G. Scudder wrote:
 >
> Hi Folks,
> 
> I'd like to suggest that Multisession BGP 
> (draft-scudder-bgp-multisession-00.txt) be considered as an IDR working 
> group document.
> 
> Thanks,
> 
> --John
> 

From: Gargi Nalawade <[email-masked]>
To: Pedro Roque Marques <[email-masked]>
CC: [email-masked], Yakov Rekhter <[email-masked]>
Subject: Re: [Idr] Soft-Notify as an IDR WG document
Sender: [email-masked]
Date: Mon, 26 Apr 2004 18:16:32 -0700

> No, sub-states within a bgp session do not exist. A session is either
> working w/ all the functionality that has been configured on it, or
> its is not.

This is an implementation-specific design choice.

>>That too, not always. Note that even with
>>Multisession, multiple afi/safis can share the same session.
> 
> That doesnt mean that multisession can't be used w/ 1 session per
> nlri... in fact it allows you to control exactly what granularity is
> desired. 

Exactly. It also does not mean that it always mandates running one
afi/safi per session, which brings us back to today's BGP spec. So
lets just talk about that.

> 
> 
>>Soft-notify is aimed at addressing the case when multiple afi/safi's
>>share one session
> 
> and why would you do that *and* want per nlri mgmt of the session ???

Soft-notify does not need per-nlri "session"management. Whatever management
is needed - the state-machine and infra for that already exists post-
MP_REACH. Unless some implementation has limittaions, in which case it is
for that implementation to fix.

> The deployment part of the equation doesn't...
> Ops people understand the bgp state machine... its easy to add the
> concept of multisession on top. Its is a much more significant
> chalenge to add this per nlri up/down negotiation.

I dont see any per nlri negotiation challenges. The mechanism exists
today and it works.

>>For those cases, the draft proposes using Notifications instead of
>>Soft-Notifications.
> 
> 
> Which doesnt provide fault containment. I'd rather have a single way
> of fault containment that works across all reasons for session
> failure...

For session-failures yes. But theer are errors such as CEASE which
should not require a session-failure as they are independent of that.

> 
> Why don't we consider the reasons why one would like to have different
> afi/safi pairs in the same session and then ask ourselfs what having
> indepent notifications/up events will buy you.

Reduced #sessions, avoid session reestab latency (we are after all limited
by the speed of light :)), reduced overhead in terms of resources that
need to be allocated per-session and so on..

> 
> I can come up w/ 2 simple scenarios:
> a) you want fate sharing... i.e. intentionally tie afis so that when
> one fails the other does fail also. (both are required to provide a
> service for instance).
> b) you don't want to deal w/ the extra complexity of monitoring
> multiple substates and prefer to deal w/ a binary "works" / "broken".
> 
> In both these examples which i consider rather realistic adding
> notifications/negotiation does not provide value.

Give me one Provider who says that because IPv4 Unicast in their network
is needed for providing some IPv4 Multicast service, IPv4 unicast should
fail whenever IPv4 Multicast has an error or a CEASE notification.

I dont think these are realistic scenarios. However, thank you for your
opinion.

-Gargi

From: Pedro Roque Marques <[email-masked]>
To: [email-masked]
Cc: [email-masked], Yakov Rekhter <[email-masked]>
Subject: Re: [Idr] Soft-Notify as an IDR WG document
Sender: [email-masked]
Date: Mon, 26 Apr 2004 17:37:52 -0700 (PDT)

Gargi Nalawade writes:

> Pedro Roque Marques wrote:
>> Gargi Nalawade writes:
>> 
> >>Not really. The soft-notofication does not affcet the number of
> >>objects being tracked etc. Everything else stays exactly the
> >>same.
>> 
>> 
>> That is an unrealistic claim..  The network operator needs to know
>> that a given set of functionality is working. If you split a set
>> (session) such that parts can fail independently that needs to be
>> monitored.

> This already exists today. Look at how Route-refresh for a
> particular afi/safi works today. This is no different. Unless of
> course there are implementation-specific issues.

No, sub-states within a bgp session do not exist. A session is either
working w/ all the functionality that has been configured on it, or
its is not.

> Lets not mix this with multisession. That is a different solution
> with different tradeoffs. Let us talk about Soft-notify here, so we
> can focus the discussion on the pros & cons of this one.

Lets not. What is relavant is to address a particular problem and to
consider what option to chose we must contrast several approaches.

>> If you believe you want to manage things with per nlri-type
>> granularity you can do it w. multisession.

> Which is a different way of doing it by forcing each afi/safi on a
> separate session.

so you do agree that multisession is a different way to solve the
problem.

> That too, not always. Note that even with
> Multisession, multiple afi/safis can share the same session.
That doesnt mean that multisession can't be used w/ 1 session per
nlri... in fact it allows you to control exactly what granularity is
desired. 

> Soft-notify is aimed at addressing the case when multiple afi/safi's
> share one session
and why would you do that *and* want per nlri mgmt of the session ???

>> Besides multisession is 10x easier to implement and deploy since it
>> can use existing state machines.

> Depends on the implementation :)

The deployment part of the equation doesn't...
Ops people understand the bgp state machine... its easy to add the
concept of multisession on top. Its is a much more significant
chalenge to add this per nlri up/down negotiation.

>> Like update errors which more likely than not corrupt the tcp
>> stream.

> For those cases, the draft proposes using Notifications instead of
> Soft-Notifications.

Which doesnt provide fault containment. I'd rather have a single way
of fault containment that works across all reasons for session
failure...

>>  Please explain what can be done w. this approach that cannot be
>> done w/ one session per afi/safi or why, given that we are talking
>> about a significant development and deployment (given mgmt impact),
>> this approach is better than using 1 session per afi/safi.

> The point is not to force all afi/safi's on a single session.

But you haven't explained why that should be a goal... 

> The
> solution-space addressed by this document is the existing
> deployments and the existing BGP-Spec where operators either have or
> may choose to have multiple afi/safi's on a single session.

Why don't we consider the reasons why one would like to have different
afi/safi pairs in the same session and then ask ourselfs what having
indepent notifications/up events will buy you.

I can come up w/ 2 simple scenarios:
a) you want fate sharing... i.e. intentionally tie afis so that when
one fails the other does fail also. (both are required to provide a
service for instance).
b) you don't want to deal w/ the extra complexity of monitoring
multiple substates and prefer to deal w/ a binary "works" / "broken".

In both these examples which i consider rather realistic adding
notifications/negotiation does not provide value.

  Pedro.

From: Gargi Nalawade <[email-masked]>
Reply-To: [email-masked]
To: Pedro Roque Marques <[email-masked]>
CC: [email-masked], Yakov Rekhter <[email-masked]>
Subject: Re: [Idr] Soft-Notify as an IDR WG document
Sender: [email-masked]
Date: Mon, 26 Apr 2004 16:46:59 -0700

Pedro Roque Marques wrote:
> Gargi Nalawade writes:
> 
>>Not really. The soft-notofication does not affcet the number of
>>objects being tracked etc. Everything else stays exactly the
>>same.
> 
> 
> That is an unrealistic claim..
> The network operator needs to know that a given set of functionality
> is working. If you split a set (session) such that parts can fail
> independently that needs to be monitored.

This already exists today. Look at how Route-refresh for a particular
afi/safi works today. This is no different. Unless of course there are
implementation-specific issues.

> Again, you can achieve all this in a much simpler way by using
> multisession, with variable degrees of granularity.

Lets not mix this with multisession. That is a different solution
with different tradeoffs. Let us talk about Soft-notify here, so
we can focus the discussion on the pros & cons of this one.

> We are talking about fate-sharing of different afi/safi in a given
> session. Its is the exact same issue.

Which is as per the BGP-Spec as it exists today.

> If you believe you want to manage things with per nlri-type
> granularity you can do it w. multisession.

Which is a different way of doing it by forcing each afi/safi on a
separate session. That too, not always. Note that even with
Multisession, multiple afi/safis can share the same session.
Soft-notify is aimed at addressing the case when multiple afi/safi's
share one session and it is desirable that operations/events in one
afi/safi do not affect the operation of the others on the same session
as itself.

> Besides multisession is 10x easier to implement and deploy since it
> can use existing state machines.

Depends on the implementation :)

>>>you describe plus issues that you do not address.
>>
> 
>>Like which ones?
> 
> 
> Like update errors which more likely than not corrupt the tcp
> stream.

For those cases, the draft proposes using Notifications instead of
Soft-Notifications.

> 
> Please explain what can be done w. this approach that cannot be done
> w/ one session per afi/safi or why, given that we are talking about a
> significant development and deployment (given mgmt impact), this
> approach is better than using 1 session per afi/safi.

The point is not to force all afi/safi's on a single session. The
solution-space addressed by this document is the existing deployments
and the existing BGP-Spec where operators either have or may choose to
have multiple afi/safi's on a single session.

-Gargi

From: Pedro Roque Marques <[email-masked]>
To: Gargi Nalawade <[email-masked]>
Cc: [email-masked], Yakov Rekhter <[email-masked]>
Subject: Re: [Idr] Soft-Notify as an IDR WG document
Sender: [email-masked]
Date: Mon, 26 Apr 2004 15:28:59 -0700 (PDT)

Gargi Nalawade writes:

> Not really. The soft-notofication does not affcet the number of
> objects being tracked etc. Everything else stays exactly the
> same.

That is an unrealistic claim..
The network operator needs to know that a given set of functionality
is working. If you split a set (session) such that parts can fail
independently that needs to be monitored.

> The afi/safi demarcation is as specified by the BGP Spec
> today, Soft-Notify does not touch it. If you do, then that would be
> an implementation limitation or issue.

Changing the operational model for BGP sessions will add
complexity in terms of management. It must be a conscious tradeoff.

Again, you can achieve all this in a much simpler way by using
multisession, with variable degrees of granularity.

> >>If we are talking of >>changing BGP semantics as it exists today
> that is a separate issue >>and independant of this document. This
> document addresses the >>problem that exists with today's
> semantics. It is important that we >>address today's reality of
> today's BGP semantics and avoid >>penalizing the other afi/safis
> that share the same session in case >>of errors/actions on any one
> of them.

We are talking about fate-sharing of different afi/safi in a given
session. Its is the exact same issue.
If you believe you want to manage things with per nlri-type
granularity you can do it w. multisession.

Besides multisession is 10x easier to implement and deploy since it
can use existing state machines.

>> you describe plus issues that you do not address.

> Like which ones?

Like update errors which more likely than not corrupt the tcp
stream.

Please explain what can be done w. this approach that cannot be done
w/ one session per afi/safi or why, given that we are talking about a
significant development and deployment (given mgmt impact), this
approach is better than using 1 session per afi/safi.

From: Gargi Nalawade <[email-masked]>
To: Pedro Roque Marques <[email-masked]>
CC: [email-masked], Yakov Rekhter <[email-masked]>
Subject: Re: [Idr] Soft-Notify as an IDR WG document
Sender: [email-masked]
Date: Mon, 26 Apr 2004 15:05:31 -0700

Pedro Roque Marques wrote:
> Gargi Nalawade writes:
> 
> 
>>There are a large number of cases that are frequently hit
>>eg. reaching a Max-prefix limit, admin shutdown, user reset (clear)
>>of a safi, etc where it is unnecessary to penalize other afi/safis
>>that run on the same session.
> 
> 
> How do you recover from those conditions ? notification is just 1/2 of
> the problem... its isn't enought to address somethis partially.

Pls read the draft. It describes how.

>>Of course one could limit one afi/safi
>>per session, but unless we change the BGP Spec to force one session
>>per every afi/safi, the reality is going to be that multiple
>>afi/safis would share a single session.
> 
> 
> why is that ? with the multisession appoach you can give the operator
> a pratical way to select the unit of cotainment that it desires.

In which case you would still end up containing multiple afi/safis
over one session. So we are back to square one.

> 
> There of course trade-offs in such a choice, such as an increase in
> the number of objects that need to be monitored from an ops point of
> view, but the same issues do exist with what you a proposing.

Not really. The soft-notofication does not affcet the number of objects
being tracked etc. Everything else stays exactly the same. The afi/safi
demarcation is as specified by the BGP Spec today, Soft-Notify does not
touch it. If you do, then that would be an implementation limitation or
issue.

>>If we are talking of
>>changing BGP semantics as it exists today that is a separate issue
>>and independant of this document. This document addresses the
>>problem that exists with today's semantics. It is important that we
>>address today's reality of today's BGP semantics and avoid
>>penalizing the other afi/safis that share the same session in case
>>of errors/actions on any one of them.
> 
> 
> You seem to be considering just a subset of the shared fate implied in
> a bgp session, which btw isn't necessarly a bad thing.
> The multisession approach seems to me to cover all the scenarios that

Multisession and soft-notify are complementary solutions. The former
aims at separating out at the session level and gives a way to automate
establishing separate sessions per afi/safi. The latter addresses the
problem with today's spec which allows operators to have one session
carrying multiple afi/safi's, but penalizes the other safis in case of
operations that require reetting of only that afi/safi.

> you describe plus issues that you do not address.

Like which ones?

-Gargi

From: Pedro Roque Marques <[email-masked]>
To: Gargi Nalawade <[email-masked]>
Cc: [email-masked], Yakov Rekhter <[email-masked]>
Subject: Re: [Idr] Soft-Notify as an IDR WG document
Sender: [email-masked]
Date: Mon, 26 Apr 2004 14:55:25 -0700 (PDT)

Gargi Nalawade writes:

> There are a large number of cases that are frequently hit
> eg. reaching a Max-prefix limit, admin shutdown, user reset (clear)
> of a safi, etc where it is unnecessary to penalize other afi/safis
> that run on the same session.

How do you recover from those conditions ? notification is just 1/2 of
the problem... its isn't enought to address somethis partially.

> Of course one could limit one afi/safi
> per session, but unless we change the BGP Spec to force one session
> per every afi/safi, the reality is going to be that multiple
> afi/safis would share a single session.

why is that ? with the multisession appoach you can give the operator
a pratical way to select the unit of cotainment that it desires.

There of course trade-offs in such a choice, such as an increase in
the number of objects that need to be monitored from an ops point of
view, but the same issues do exist with what you a proposing.

> If we are talking of
> changing BGP semantics as it exists today that is a separate issue
> and independant of this document. This document addresses the
> problem that exists with today's semantics. It is important that we
> address today's reality of today's BGP semantics and avoid
> penalizing the other afi/safis that share the same session in case
> of errors/actions on any one of them.

You seem to be considering just a subset of the shared fate implied in
a bgp session, which btw isn't necessarly a bad thing.
The multisession approach seems to me to cover all the scenarios that
you describe plus issues that you do not address.

> Hence I propose that this be accepted as a WG document.

I maintain my opposition.

  Pedro.

From: Gargi Nalawade <[email-masked]>
To: Pedro Roque Marques <[email-masked]>, [email-masked]
CC: Yakov Rekhter <[email-masked]>
Subject: Re: [Idr] Soft-Notify as an IDR WG document
Sender: [email-masked]
Date: Mon, 26 Apr 2004 14:06:06 -0700

There are a large number of cases that are frequently hit eg. reaching
a Max-prefix limit, admin shutdown, user reset (clear) of a safi, etc
where it is unnecessary to penalize other afi/safis that run on the same
session. Of course one could limit one afi/safi per session, but unless
we change the BGP Spec to force one session per every afi/safi, the
reality is going to be that multiple afi/safis would share a single
session. If we are talking of changing BGP semantics as it exists
today that is a separate issue and independant of this document. This
document addresses the problem that exists with today's semantics. It
is important that we address today's reality of today's BGP semantics
and avoid penalizing the other afi/safis that share the same session
in case of errors/actions on any one of them.

Hence I propose that this be accepted as a WG document.

-Gargi

Pedro Roque Marques wrote:
> Yakov Rekhter writes:
> 
> 
>>Folks, Please comment on the attached. The deadline for comments is
>>May 10.
> 
> 
> I dont think this document should be accepted as a work-group
> document. The unit of containment in bgp should be the session. We can
> possibly have multiple sessions between a pair of systems either via
> manual config or with the mecanism that Scudder is proposing.
> 
> Attempting to reset a subset of the nlri is something that won't work
> in a considerable number of cases and that adds a very significant
> ammount of complexity to BGP.
> 
> I would like to propose that the WG rejects this approach.
> 
> 

From: Andrew Lange <[email-masked]>
To: Pekka Savola <[email-masked]>, Pedro Roque Marques <[email-masked]>
cc: Yakov Rekhter <[email-masked]>, [email-masked]
Subject: Re: [Idr] draft-lange-flexible-bgp-communities-02.txt as an IDR WG document
Sender: [email-masked]
Date: Mon, 26 Apr 2004 13:37:02 -0700

Hi Pekka,

> Why do we need this in the first place?  To "standardize" commonly
> used communities?  To give the users more tools to mess up their
> routing, or to allow the users to make the ISP's policy more complex?

Here is some additional text for the introduction which, I hope, will 
answer your questions.

There is a clear demand by BGP-savvy customers to have enhanced control 
over their route announcements.  Today this demand is addressed by custom, 
complex and difficult to manage community policies.  There is no 
consistency across providers, except for the NO_EXPORT well known community 
specified in RFC1997.  There are more well-known communities for common 
policies specified in this document to help provide commonality and ease of 
maintenance.  The current route policies required to provide enhanced BGP 
services are very cumbersome.  The larger space provided in flexible 
communities, and the introduction of neighbor classes significantly ease 
the implementation and maintenance burdens for service providers.

Service providers also often tag their data based on where and from whom 
they learned it (peer, customer, geographic origin).  The flexible 
community, and the neighbor class application especially, make both 
assigning inbound communities and matching on outbound peers significantly 
easier and less error prone.

In addition, community values today are simply too small and too rigidly 
defined to allow for the growth of the Internet.  For example, encoding 
IPv6 address and an action to take on them is simply impossible.

> A few nits:
>  - if EX-COMM doesn't support IPv6 addresses, and that is important
> enough, the support MUST be added.

EX-COMM is 8 octets.  An IPv6 address is 16.  As IPv6 deployments progress 
there will be a demand for encoding IPv6 addresses.

>  - it might make sense to switch the order of Length and "ASN" fields
> for better alignment.  Length could also include the ASN field. (Maybe
> this would be a more typical TLV encoding?)

This would be pretty simple to do.  I had structured things the way they 
are to allow for a larger DATA Field to encode values.  We would max out at 
251 octets of data with the ASN field second.  251 is probably enough, and 
we would gain a slightly simpler header and more alignment with existing 
communities.  Okay, I'll reorder those two fields.

Andrew

> On Wed, 21 Apr 2004, Pedro Roque Marques wrote:
>> Yakov Rekhter writes:
>> > Folks, It would be greatly appreciated if folks would read the
>> > document and comment on it to the IDR mailing list. In other words,
>> > we need "yes, looks good" or "should fix this and that", not just
>> > silence.
>>
>> my recollection is that this draft has been discussed before and that
>> the majority of the WG requested that encoding and applications of
>> communities be kept separate.
>>
>> reclying the comments: it does appear that the propossed applications
>> are possible w/ existing protocol support. The author recognises that
>> some of those applications may or may not be a good idea given that
>> they seem to impose on an ISP a set of policies which the ISP may or
>> may not wish to provide...
>>
>> reading the document, it seems that the original comments are still
>> relevant.
>>
>> i also believe that embeding ipv4 and ipv6 addresses into communities is
>> not a feature... addresses don't make for very good identifiers given
>> that they may change.
>>
>>   Pedro.
>>
> --
> Pekka Savola                 "You each name yourselves king, yet the
> Netcore Oy                    kingdom bleeds."
> Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
>
>

From: Andrew Lange <[email-masked]>
To: Yakov Rekhter <[email-masked]>, [email-masked]
Subject: Re: [Idr] Soft-Notify as an IDR WG document
Sender: [email-masked]
Date: Mon, 26 Apr 2004 13:33:30 -0700

This draft should be accepted by the WG.  It provides a valuable mechanism 
for today's deployments where we have multiple NLRI in a single session.

Andrew

--On Monday, April 26, 2004 8:01 AM -0700 Yakov Rekhter <[email-masked]> 
wrote:

> Folks,
>
> Please comment on the attached. The deadline for comments is
> May 10.
>
> Yakov.
>
> Date:    Tue, 20 Apr 2004 12:47:27 -0700
> From:    Gargi Nalawade <[email-masked]>
> To:      [email-masked]
> Subject: [Idr] Soft-Notify as IDR WG document
>
> Hi All,
>
> I would like to request that BGP Soft-Notify draft,
> draft-nalawade-bgp-soft-notify-00.txt be accepted as
> an IDR WG document.
>
> - -Gargi
>
>

From: "zafar ali" <[email-masked]>
To: "'Yakov Rekhter'" <[email-masked]>, <[email-masked]>
Subject: RE: [Idr] Soft-Notify as an IDR WG document
Organization: Cisco Systems
Importance: Normal
Sender: [email-masked]
Date: Mon, 26 Apr 2004 15:22:57 -0400

Hi, 

Yes, this document should be accepted as a WG ID. 

Thanks

Regards... Zafar

>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]] On Behalf 
>Of Yakov Rekhter
>Sent: Monday, April 26, 2004 11:02 AM
>To: [email-masked]
>Subject: [Idr] Soft-Notify as an IDR WG document
>
>
>Folks,
>
>Please comment on the attached. The deadline for comments is May 10.
>
>Yakov.
>
>Date:    Tue, 20 Apr 2004 12:47:27 -0700
>From:    Gargi Nalawade <[email-masked]>
>To:      [email-masked]
>Subject: [Idr] Soft-Notify as IDR WG document
>
>Hi All,
>
>I would like to request that BGP Soft-Notify draft, 
>draft-nalawade-bgp-soft-notify-00.txt be accepted as an IDR WG 
>document.
>
>- -Gargi
>
>

From: Andrew Lange <[email-masked]>
To: Pedro Roque Marques <[email-masked]>, Yakov Rekhter <[email-masked]>
cc: [email-masked]
Subject: Re: [Idr] draft-lange-flexible-bgp-communities-02.txt as an IDR WG document
Sender: [email-masked]
Date: Mon, 26 Apr 2004 12:13:50 -0700

Hi Pedro,

Replies are inline.

> my recollection is that this draft has been discussed before and that
> the majority of the WG requested that encoding and applications of
> communities be kept separate.

This suggestion was brought up at the SF IETF meeting.  There was no action
taken to access if this was a majority opinion or not.  If we look at the
former communities documents (1997 or the ext-comms draft) an initial set
of applications is also specified in those documents.  The applications
specified in this draft parallel the ones specified in 1997 and ext-comms,
with a couple of additions (neighbor classes, prepend, announce_with).

> reclying the comments: it does appear that the propossed applications
> are possible w/ existing protocol support. The author recognises that
> some of those applications may or may not be a good idea given that
> they seem to impose on an ISP a set of policies which the ISP may or
> may not wish to provide...
>
> reading the document, it seems that the original comments are still
> relevant.

Could you expand on this a little?  As an operator at the time I wrote
this, I included a proviso that says that operators MUST be able to turn
things off that they do not wish to honor.

The application that I think SPs will be cautious with is the ANNOUNCE_WITH
option.  Some providers will want to allow their customers to do this, but
some may not.

The basis for this proposal was community policies that providers were
already painstakingly using in their networks.  The policy actions in the
flex comms draft makes those policies easier to express, implement and
maintain in SP's networks.  Examples would include easy sending of lists of
ASNs for NO_EXPORT, neighbor-class functionality, etc.

> i also believe that embeding ipv4 and ipv6 addresses into communities is
> not a feature... addresses don't make for very good identifiers given
> that they may change.

Changing addresses can be an operational concern.  However, this extends
the options that exist for extended communities. You cannot send a IPv6
route-target without the ability to encode an IP address.  There are also
some tactical situations where a BGP-savvy customer would want to encode an
IP address.  For example one could wish to prepend to an east-coast peer
for its routes to avoid a perceived problem on that peering link.  So

                AS 100 ----   AS 200    ---- AS 100
                                |
                              AS 5000

AS 5000 would announce to 200 a community where it would ask that a
specific prefix or set of prefixes be prepended to AS 100's east-coast peer
IP (or neighbor class, if those are configured).  AS 200 would prepend, and
some of the traffic would move over to the AS100-AS200 west coast link.

Andrew

To: "Susan Hares" <[email-masked]>
Cc: "Pekka Savola" <[email-masked]>, [email-masked], "Yakov Rekhter" <[email-masked]>, [email-masked]
Subject: Re: [Idr] draft-chavali-bgp-prefixlimit-01.txt as an IDR WG document 
From: Enke Chen <[email-masked]>
Sender: [email-masked]
Date: Mon, 26 Apr 2004 12:10:51 -0700

Hi, Sue:

At the last IDR meeting, there were several suggestions about simplifying
the spec..  One particular one (by jgs?) is to just advertise the prefix
limit, something like <afi, safi, max-limit>.  As a BGP speaker knows how
many prefixes it has advertised to a particular peer, the <afi, safi, max>
received from a peer should be sufficient for a local BGP to take action
(such as generate warning, stop advertisement, ...)

*If* the prefix-limit advertisement is needed, I suggest that we take the
approach of just advertising <afi, safi, max-limit>. The current draft
is just too complicated for the feature.

-- Enke

> From: "Susan Hares" <[email-masked]>
> To: "Pekka Savola" <[email-masked]>
> Cc: "Yakov Rekhter" <[email-masked]>, <[email-masked]>
> 
> 
> Pekka:
> 
> Thanks for the input.  Your vote is for=20
> the simple version.=20
> 
> Sue
> 
> 
> -----Original Message-----
> From: Pekka Savola [mailto:[email-masked]]
> Sent: Friday, April 23, 2004 1:17 AM
> To: Susan Hares
> Cc: Yakov Rekhter; [email-masked]
> Subject: RE: [Idr] draft-chavali-bgp-prefixlimit-01.txt as an IDR WG
> document
> 
> 
> On Thu, 15 Apr 2004, Susan Hares wrote:
> > Can you clarify something here:
> > 	1) Your need - informing the remote peer of
> > 		warning limits, stop receive limits, and drop limits
> > 		and SNMP traps, logs etcs
> >=20
> > 		is the basis for the draft.
> 
> We don't really *need* this, because we're monitoring the number of
> prefixes advertised by peers.  If they go over the top, an alarm
> sounds in the NOC.  There is no need to inform the peer of the prefix
> limits we use, as no prefixes should be dropped based on that, and if
> they are, the peer has been badly misbehaving and deserves what it
> got.
> 
> Remember, if a peer advertises 100 prefixes, you don't set the prefix=20
> limits to 101 prefixes or even 110 prefixes, but probably something=20
> like 200 or 500 prefixes.
> 
> Our threat model here is, "we want to stop peers from accidentally
> advertising the whole Internet or a lot more routes than is normal to
> us."
> 
> I.e., a properly administered systems do not need this option.
> 
> But I would not object to having a simple option if that's what others
> see useful.  I would object to creating a complex option, because that
> seems to go too much beyond the cost/benefit curve for an option which
> is not needed at all in the first place.
> 
> > 	2)  Providers we talk to had 2 cases:
> > =09
> > 		1) creeping VPN prefix limits
> > 		2) dump of whole routing table
> >=20
> > 		The need to treat the two differently.
> 
> No, I think I disagree with this.  Why would they have to be treated=20
> differently?  It's the number of prefixes per peer that counts, not=20
> per AFI/SAFI etc. used, or the manner by which they're transmitted.
> 
> You protect your gear at the edge of the network, from either your
> peers or your customers (if you import their routes into VPN), so
> distinguishing per VPN doesn't seem to be all that useful.
> 
> > 	3)  Set until changed - that's the rub
> >=20
> > 	The providers wanted to negotiate the capabilties and
> > 	upgrade the capabilities without dropping the connect.
> >=20
> > 	Is that what you mean as well? If so, could you comment
> > 	on what is complex.
> 
> Currently, adding prefix-limits does not drop a session, so it's=20
> required that sessions aren't dropped if the prefix-limits are changed=20
> either.  That means that if prefix-limit negotiation is specified, it=20
> must not require a session reset, yes.
> =20
> > History:=20
> > 	We started this out with capabilities on open, and dynamic
> > 	capabilities.  Due to some vendor's request to include other
> > 	mechanism (ORF, Soft Notify) to support the dynamic features -=20
> > 	we added the rest.
> >=20
> > 	Other service providers said, Love the function but could you
> > 	do it by prefix lengths. =20
> >=20
> > 	In an effort to get something working for all these folks,
> > 	we made these other features optional. =20
> >=20
> > What part don't you like?  Cause everything you stated you wanted --
> > is the basic part of the initial draft?  Did you dis-like the =
> additions
> > (ORF, Soft Notify) and or the optional sub-codes?=20
> >
> > Do you think we should go back to the initial draft simplistic model?
> 
> It seems to me that if dynamic capabilities is a required-to-implement
> mechanism, soft-notify is useless or even problematic (what if you are
> doing both?).  Similarly, I fail to see any need for ORF (but
> admittedly, I haven't looked at it much) or using prefix lengths. =20
> Those who would like to distinguish prefix length in the
> prefix-limiter are probably confusing inbound policy with appropriate
> prefix-limits.
> 
> So, yes, draft-chavali-bgp-prefixlimit-00.txt looks very nice and=20
> compact to me.
> 
> --=20
> Pekka Savola                 "You each name yourselves king, yet the
> Netcore Oy                    kingdom bleeds."
> Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
> 
> 

From: Rahul Aggarwal <[email-masked]>
To: Yakov Rekhter <[email-masked]>
cc: [email-masked]
Subject: Re: [Idr] Soft-Notify as an IDR WG document
Sender: [email-masked]
Date: Mon, 26 Apr 2004 11:38:33 -0700 (PDT)

On Mon, 26 Apr 2004, Yakov Rekhter wrote:

> Folks,
>
> Please comment on the attached. The deadline for comments is
> May 10.
>

I don't think this document should be accepted as a WG document. Resetting
some of the nlris on the same session will not help in a several cases and
adds complexity. Also such an attempt at partial recovery may lead to the
session continuing to operate in a faulty/corrupted state.

rahul

> Date:    Tue, 20 Apr 2004 12:47:27 -0700
> From:    Gargi Nalawade <[email-masked]>
> To:      [email-masked]
> Subject: [Idr] Soft-Notify as IDR WG document
>
> Hi All,
>
> I would like to request that BGP Soft-Notify draft,
> draft-nalawade-bgp-soft-notify-00.txt be accepted as
> an IDR WG document.
>
> - -Gargi
>
>

Content-class: urn:content-classes:message
Subject: RE: [Idr] draft-chavali-bgp-prefixlimit-01.txt as an IDR WG document
From: "Susan Hares" <[email-masked]>
To: "Pekka Savola" <[email-masked]>
Cc: "Yakov Rekhter" <[email-masked]>, <[email-masked]>
Sender: [email-masked]
Date: Mon, 26 Apr 2004 13:53:43 -0400

Pekka:

Thanks for the input.  Your vote is for 
the simple version. 

Sue

-----Original Message-----
From: Pekka Savola [mailto:[email-masked]]
Sent: Friday, April 23, 2004 1:17 AM
To: Susan Hares
Cc: Yakov Rekhter; [email-masked]
Subject: RE: [Idr] draft-chavali-bgp-prefixlimit-01.txt as an IDR WG
document

On Thu, 15 Apr 2004, Susan Hares wrote:
> Can you clarify something here:
> 	1) Your need - informing the remote peer of
> 		warning limits, stop receive limits, and drop limits
> 		and SNMP traps, logs etcs
> 
> 		is the basis for the draft.

We don't really *need* this, because we're monitoring the number of
prefixes advertised by peers.  If they go over the top, an alarm
sounds in the NOC.  There is no need to inform the peer of the prefix
limits we use, as no prefixes should be dropped based on that, and if
they are, the peer has been badly misbehaving and deserves what it
got.

Remember, if a peer advertises 100 prefixes, you don't set the prefix 
limits to 101 prefixes or even 110 prefixes, but probably something 
like 200 or 500 prefixes.

Our threat model here is, "we want to stop peers from accidentally
advertising the whole Internet or a lot more routes than is normal to
us."

I.e., a properly administered systems do not need this option.

But I would not object to having a simple option if that's what others
see useful.  I would object to creating a complex option, because that
seems to go too much beyond the cost/benefit curve for an option which
is not needed at all in the first place.

> 	2)  Providers we talk to had 2 cases:
> 	
> 		1) creeping VPN prefix limits
> 		2) dump of whole routing table
> 
> 		The need to treat the two differently.

No, I think I disagree with this.  Why would they have to be treated 
differently?  It's the number of prefixes per peer that counts, not 
per AFI/SAFI etc. used, or the manner by which they're transmitted.

You protect your gear at the edge of the network, from either your
peers or your customers (if you import their routes into VPN), so
distinguishing per VPN doesn't seem to be all that useful.

> 	3)  Set until changed - that's the rub
> 
> 	The providers wanted to negotiate the capabilties and
> 	upgrade the capabilities without dropping the connect.
> 
> 	Is that what you mean as well? If so, could you comment
> 	on what is complex.

Currently, adding prefix-limits does not drop a session, so it's 
required that sessions aren't dropped if the prefix-limits are changed 
either.  That means that if prefix-limit negotiation is specified, it 
must not require a session reset, yes.
 
> History: 
> 	We started this out with capabilities on open, and dynamic
> 	capabilities.  Due to some vendor's request to include other
> 	mechanism (ORF, Soft Notify) to support the dynamic features - 
> 	we added the rest.
> 
> 	Other service providers said, Love the function but could you
> 	do it by prefix lengths.  
> 
> 	In an effort to get something working for all these folks,
> 	we made these other features optional.  
> 
> What part don't you like?  Cause everything you stated you wanted --
> is the basic part of the initial draft?  Did you dis-like the additions
> (ORF, Soft Notify) and or the optional sub-codes? 
>
> Do you think we should go back to the initial draft simplistic model?

It seems to me that if dynamic capabilities is a required-to-implement
mechanism, soft-notify is useless or even problematic (what if you are
doing both?).  Similarly, I fail to see any need for ORF (but
admittedly, I haven't looked at it much) or using prefix lengths.  
Those who would like to distinguish prefix length in the
prefix-limiter are probably confusing inbound policy with appropriate
prefix-limits.

So, yes, draft-chavali-bgp-prefixlimit-00.txt looks very nice and 
compact to me.

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

From: Pedro Roque Marques <[email-masked]>
To: Yakov Rekhter <[email-masked]>
Cc: [email-masked]
Subject: [Idr] Soft-Notify as an IDR WG document
Sender: [email-masked]
Date: Mon, 26 Apr 2004 10:04:09 -0700 (PDT)

Yakov Rekhter writes:

> Folks, Please comment on the attached. The deadline for comments is
> May 10.

I dont think this document should be accepted as a work-group
document. The unit of containment in bgp should be the session. We can
possibly have multiple sessions between a pair of systems either via
manual config or with the mecanism that Scudder is proposing.

Attempting to reset a subset of the nlri is something that won't work
in a considerable number of cases and that adds a very significant
ammount of complexity to BGP.

I would like to propose that the WG rejects this approach.

From: Henry Kilmer <[email-masked]>
To: "John G. Scudder" <[email-masked]>
Cc: [email-masked]
Subject: [Idr] Multisession as WG doc
Sender: [email-masked]
Date: Tue, 20 Apr 2004 11:04:44 -0400

John G. Scudder writes:
>Hi Folks,
>
>I'd like to suggest that Multisession BGP 
>(draft-scudder-bgp-multisession-00.txt) be considered as an IDR 
>working group document.

This document should definately be a WG document.

-Hank

To: [email-masked]
From: Yakov Rekhter <[email-masked]>
Subject: [Idr] Soft-Notify as an IDR WG document
Sender: [email-masked]
Date: Mon, 26 Apr 2004 08:01:36 -0700

Folks,

Please comment on the attached. The deadline for comments is
May 10.

Yakov.

Date:    Tue, 20 Apr 2004 12:47:27 -0700
From:    Gargi Nalawade <[email-masked]>
To:      [email-masked]
Subject: [Idr] Soft-Notify as IDR WG document

Hi All,

I would like to request that BGP Soft-Notify draft,
draft-nalawade-bgp-soft-notify-00.txt be accepted as
an IDR WG document.

- -Gargi

From: Jeffrey Haas <[email-masked]>
To: [email-masked]
Subject: [Idr] [[email-masked]: I-D ACTION:draft-ietf-idr-bgp4-mib-14.txt]
Sender: [email-masked]
Date: Mon, 26 Apr 2004 10:26:11 -0400

Gentles,

This document incorporates all last-call comments from Sharon.

----- Forwarded message from [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		: 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-14.txt
	Pages		: 35
	Date		: 2004-4-23
	
This memo is an extension to the SNMP MIB.  It obsoletes RFC 1657 and
RFC 1269.

[...]

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

----- End forwarded message -----

-- 
Jeff Haas 
NextHop Technologies

To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: [Idr] I-D ACTION:draft-ietf-idr-bgp4-mib-14.txt
Sender: [email-masked]
Date: Fri, 23 Apr 2004 15:36:33 -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		: 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-14.txt
	Pages		: 35
	Date		: 2004-4-23
	
This memo is an extension to the SNMP MIB.  It obsoletes RFC 1657 and
RFC 1269.

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.

This memo is intended to document deployed implementations of this
MIB in a historical context, provide clarifications of some items and
also note errors where the MIB fails to fully represent the BGP
protocol.  Work is currently in progress to replace this MIB with a
new one representing the current state of the BGP protocol and its
extensions.

Distribution of this memo is unlimited.  Please forward comments to
[email-masked].

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

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

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-14.txt".

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-idr-bgp4-mib-14.txt".

--NextPart

--OtherAccess

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

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

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-idr-bgp4-mib-14.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: Susan Hares <[email-masked]>
cc: Yakov Rekhter <[email-masked]>, <[email-masked]>
Subject: RE: [Idr] draft-chavali-bgp-prefixlimit-01.txt as an IDR WG document
Sender: [email-masked]
Date: Fri, 23 Apr 2004 08:16:48 +0300 (EEST)

On Thu, 15 Apr 2004, Susan Hares wrote:
> Can you clarify something here:
> 	1) Your need - informing the remote peer of
> 		warning limits, stop receive limits, and drop limits
> 		and SNMP traps, logs etcs
> 
> 		is the basis for the draft.

We don't really *need* this, because we're monitoring the number of
prefixes advertised by peers.  If they go over the top, an alarm
sounds in the NOC.  There is no need to inform the peer of the prefix
limits we use, as no prefixes should be dropped based on that, and if
they are, the peer has been badly misbehaving and deserves what it
got.

Remember, if a peer advertises 100 prefixes, you don't set the prefix 
limits to 101 prefixes or even 110 prefixes, but probably something 
like 200 or 500 prefixes.

Our threat model here is, "we want to stop peers from accidentally
advertising the whole Internet or a lot more routes than is normal to
us."

I.e., a properly administered systems do not need this option.

But I would not object to having a simple option if that's what others
see useful.  I would object to creating a complex option, because that
seems to go too much beyond the cost/benefit curve for an option which
is not needed at all in the first place.

> 	2)  Providers we talk to had 2 cases:
> 	
> 		1) creeping VPN prefix limits
> 		2) dump of whole routing table
> 
> 		The need to treat the two differently.

No, I think I disagree with this.  Why would they have to be treated 
differently?  It's the number of prefixes per peer that counts, not 
per AFI/SAFI etc. used, or the manner by which they're transmitted.

You protect your gear at the edge of the network, from either your
peers or your customers (if you import their routes into VPN), so
distinguishing per VPN doesn't seem to be all that useful.

> 	3)  Set until changed - that's the rub
> 
> 	The providers wanted to negotiate the capabilties and
> 	upgrade the capabilities without dropping the connect.
> 
> 	Is that what you mean as well? If so, could you comment
> 	on what is complex.

Currently, adding prefix-limits does not drop a session, so it's 
required that sessions aren't dropped if the prefix-limits are changed 
either.  That means that if prefix-limit negotiation is specified, it 
must not require a session reset, yes.
 
> History: 
> 	We started this out with capabilities on open, and dynamic
> 	capabilities.  Due to some vendor's request to include other
> 	mechanism (ORF, Soft Notify) to support the dynamic features - 
> 	we added the rest.
> 
> 	Other service providers said, Love the function but could you
> 	do it by prefix lengths.  
> 
> 	In an effort to get something working for all these folks,
> 	we made these other features optional.  
> 
> What part don't you like?  Cause everything you stated you wanted --
> is the basic part of the initial draft?  Did you dis-like the additions
> (ORF, Soft Notify) and or the optional sub-codes? 
>
> Do you think we should go back to the initial draft simplistic model?

It seems to me that if dynamic capabilities is a required-to-implement
mechanism, soft-notify is useless or even problematic (what if you are
doing both?).  Similarly, I fail to see any need for ORF (but
admittedly, I haven't looked at it much) or using prefix lengths.  
Those who would like to distinguish prefix length in the
prefix-limiter are probably confusing inbound policy with appropriate
prefix-limits.

So, yes, draft-chavali-bgp-prefixlimit-00.txt looks very nice and 
compact to me.

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

From: Pekka Savola <[email-masked]>
To: Yakov Rekhter <[email-masked]>
cc: [email-masked]
Subject: Re: [Idr] Last Call on draft-ietf-idr-rfc2796bis-00.txt
Sender: [email-masked]
Date: Thu, 22 Apr 2004 12:44:26 +0300 (EEST)

On Fri, 16 Apr 2004, Yakov Rekhter wrote:
> During the Last Call it would be greatly appreciated if folks would
> read the document and comment on it to the IDR mailing list. In
> other words, we need "yes, looks good" or "should fix this and
> that", not just silence.

In general, I think this should be rather close to being ready for 
going forward.

A few quick comments:

 - the text could use a lot more updates, but is readable as it is.
 
 - where are the implementation & interop reports?

 - several ID-nits or other process issues must be fixed, at least:
  o Status of this memo, Abstract, etc. must be unnumbered sections 
    (typically Introduction is section number 1)
  o No references in the abstract.
  o One cannot have normative references to documents of lower 
    maturity level.  I suggest moving everything except [1] (or 
    maybe also [7]) to a new Informational References section.
  o The document should probably say (in Abstract and Introduction) 
    that this document Obsoletes both 2796 and 1966 (note 2796 only 
    Updates 1966, which was probably a bug.)?
  o Standard IPR statement is needed at the end even if there is is no 
    IPR.  The date in the copyright statement is 4 years old as well..
  o every empty line in this memo is duplicated (due to flawed 
    DOS/WINDOWS -> Unix conversion?)

 - food for thought: should we kill two birds in one stone, and also 
   declare RFC1863 ("A BGP/IDRP Route Server alternative to a full 
   mesh routing") historic?  Is that useful anymore?

 - A few rewordings I spotted (I grew bored with the text soon after 
   the abstract, as there would have been a lot of changes):

                                         Currently in the Internet BGP
   deployments are configured such that that all BGP speakers within a
   single AS must be fully meshed so that any external routing
   information must be re-distributed to all other routers within that
   AS.
                                                                                
==> s/Currently in the Internet BGP deployments are configured such 
that that/Typically/ (the same in the Introduction)
                                                                                
   information, as is common in many of todays internet networks.
                                                                                
==> s/todays internet/today's Internet/

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

From: Pekka Savola <[email-masked]>
To: Pedro Roque Marques <[email-masked]>
cc: Yakov Rekhter <[email-masked]>, <[email-masked]>
Subject: Re: [Idr] draft-lange-flexible-bgp-communities-02.txt as an IDR WG document
Sender: [email-masked]
Date: Thu, 22 Apr 2004 12:17:53 +0300 (EEST)

Hi,

For what it's worth, it seems to me that this memo is a solution
looking for the problem.

Why do we need this in the first place?  To "standardize" commonly 
used communities?  To give the users more tools to mess up their 
routing, or to allow the users to make the ISP's policy more complex?

I'm skeptical about the usefulness of this approach.

A few nits:
 - if EX-COMM doesn't support IPv6 addresses, and that is important 
enough, the support MUST be added.
 - it might make sense to switch the order of Length and "ASN" fields 
for better alignment.  Length could also include the ASN field. (Maybe 
this would be a more typical TLV encoding?)

On Wed, 21 Apr 2004, Pedro Roque Marques wrote:
> Yakov Rekhter writes:
> > Folks, It would be greatly appreciated if folks would read the
> > document and comment on it to the IDR mailing list. In other words,
> > we need "yes, looks good" or "should fix this and that", not just
> > silence.
> 
> my recollection is that this draft has been discussed before and that
> the majority of the WG requested that encoding and applications of
> communities be kept separate.
> 
> reclying the comments: it does appear that the propossed applications
> are possible w/ existing protocol support. The author recognises that
> some of those applications may or may not be a good idea given that
> they seem to impose on an ISP a set of policies which the ISP may or
> may not wish to provide...
> 
> reading the document, it seems that the original comments are still
> relevant.
> 
> i also believe that embeding ipv4 and ipv6 addresses into communities is
> not a feature... addresses don't make for very good identifiers given
> that they may change.
> 
>   Pedro.
> 

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

From: Shane Amante <[email-masked]>
To: [email-masked]
Subject: Re: [Idr] Multisession as WG doc
Mail-Followup-To: [email-masked]
Sender: [email-masked]
Date: Tue, 20 Apr 2004 21:31:20 -0600

I support making this a WG document.

-shane

On Mon, Apr 19, 2004 at 03:42:25PM -0400, John G. Scudder wrote:
> Hi Folks,
> 
> I'd like to suggest that Multisession BGP 
> (draft-scudder-bgp-multisession-00.txt) be considered as an IDR 
> working group document.
> 
> Thanks,
> 
> --John
> 

From: Gargi Nalawade <[email-masked]>
Reply-To: [email-masked]
To: [email-masked]
Subject: [Idr] Soft-Notify as IDR WG document
Sender: [email-masked]
Date: Tue, 20 Apr 2004 12:47:27 -0700

Hi All,

I would like to request that BGP Soft-Notify draft,
draft-nalawade-bgp-soft-notify-00.txt be accepted as
an IDR WG document.

-Gargi

From: Parantap Lahiri <[email-masked]>
Subject: RE: [Idr] draft-chavali-bgp-prefixlimit-01.txt as an IDR WG document
To: "'Ash, Gerald R (Jerry), ALABS'" <[email-masked]>, [email-masked], "'Yakov Rekhter'" <[email-masked]>
Importance: Normal
Sender: [email-masked]
Date: Tue, 20 Apr 2004 14:22:14 -0400

This draft proposes some reasonable approach to solve some existing issues. 

In VPN world the number of prefixes can slowly creep up and an elaborate
mechanism for warning, stop and reset could be helpful but in public SP
world in most of the cases the SP maintains a static prefix-list for each
customer. Usually the customer needs to contact the SP if they need to
modify that prefix-list. 

Typically though, the SP accepts any prefixes which are more specific to the
ones maintained in the prefix-list filter. The problem arises when the
customer accidentally de-aggregates their prefixes. And when that happens
depending on the block that got de-aggregated, the number prefix send by
customer could experience a sudden sizeable jump. In today's world, there is
a snmp/syslog warning sent when it hits X% (e.g. 75%), and the session would
go down permanently if the max-prefix-limit is exceeded. It would take an
urgent operator intervention to bring it up again, of course the operator
would need to make sure the cause has been taken care off before bringing
the session up.

So if we want to use the draft approach to take care of this particular
scenario, a filtering mechanism depending on the specificity of a prefix
could become important. For, e.g., if a session hits the stop level, the
sender could resend all its prefixes after filtering out any prefix more
specific to /24 etc. Of course this specificity should be configurable.
However, if for example, /24 is chosen, it would ensure all the customer
prefixes are still globally routable, but some of their load-balancing
mechanism can get affected. So the price the customer pays for the mishap
gets less harsh.

On the other hand, the approach mentioned in the draft could be useful on
the BGP sessions used for peering with equivalent SP peers.

-Parantap

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Ash,
Gerald R (Jerry), ALABS
Sent: Tuesday, April 20, 2004 8:52 AM
To: [email-masked]; Yakov Rekhter
Cc: Ash, Gerald R (Jerry), ALABS
Subject: RE: [Idr] draft-chavali-bgp-prefixlimit-01.txt as an IDR WG
document

> We receive a request to accept draft-chavali-bgp-prefixlimit-01.txt
> as an IDR WG document. Please send comments to the list. The deadline
> for comments is April 29, 2004.

This draft addresses an important issue, and proposes a reasonable approach
to address the issue.  I support this becoming a WG document.

Jerry

To: [email-masked]
From: Yakov Rekhter <[email-masked]>
Subject: [Idr] draft-scudder-bgp-multisession-00.txt as an IDR WG document
Sender: [email-masked]
Date: Tue, 20 Apr 2004 07:36:41 -0700

Folks,

Please comment on the attached. The deadline for comments is
May 3.

Yakov.

Date:    Mon, 19 Apr 2004 15:42:25 -0400
From:    "John G. Scudder" <[email-masked]>
To:      [email-masked]
Subject: [Idr] Multisession as WG doc

Hi Folks,
  
I'd like to suggest that Multisession BGP 
(draft-scudder-bgp-multisession-00.txt) be considered as an IDR 
working group document.

Thanks,

- --John

From: "zafar ali" <[email-masked]>
To: "'idr'" <[email-masked]>
Subject: RE: [Idr] Multisession as WG doc
Organization: Cisco Systems
Importance: Normal
Sender: [email-masked]
Date: Tue, 20 Apr 2004 10:34:38 -0400

>
> Hi Folks,
>
> I'd like to suggest that Multisession BGP
> (draft-scudder-bgp-multisession-00.txt) be considered as an IDR 
> working group document.

I support this notion. 

Thanks

Regards... Zafar

From: David Meyer <[email-masked]>
To: idr <[email-masked]>
Subject: Re: [Idr] Multisession as WG doc
Sender: [email-masked]
Date: Tue, 20 Apr 2004 07:04:26 -0700

On Apr 19, 2004, at 1:42 PM, John G. Scudder wrote:

>Hi Folks,
>
>I'd like to suggest that Multisession BGP 
>(draft-scudder-bgp-multisession-00.txt) be considered as an IDR 
>working group document.

	I support this document becoming a WG document.

	Dave

To: Stephen Kent <[email-masked]>
cc: Alex Zinin <[email-masked]>, Steve Bellovin <[email-masked]>, [email-masked], [email-masked]
Subject: Re: [Idr] Re: [saag] draft-iesg-tcpmd5app-00.txt 
From: Yakov Rekhter <[email-masked]>
Sender: [email-masked]
Date: Tue, 20 Apr 2004 06:54:37 -0700

Steve,

> >>  >Steve, would you mind making a suggestion on how the text could 
> >>be improved?
> >>  >E.g., would a separate section in the main body of the document specifyi
ng
> >>  >the requirement for TCP-MD5 support be useful?
> >>
> >>  A reasonable approach would be to have a section of the document that
> >>  describes the use of this TCP option. It should explain why/when one
> >>  would use the option in the context of BGP links and what protection
> >>  it offers.
> >
> >Would you please produce the appropriate text for this section.
> >
> >Thanks in advance.
> >
> >Yakov.
> 
> I'll try to provide some text when I return from vacation, in early May.

Thanks !!! Looking forward to get the text.

Yakov.

To: Alex Zinin <[email-masked]>
cc: Pekka Savola <[email-masked]>, [email-masked], [email-masked]
Subject: Re: [Idr] FYI: Last Call: 'A Border Gateway Protocol 4 (BGP-4)' to Draft Standard 
From: Yakov Rekhter <[email-masked]>
Sender: [email-masked]
Date: Tue, 20 Apr 2004 06:53:01 -0700

Alex,

> Pekka,
> 
> [cc'ing IDR]
> 
> Thanks for a careful follow-up. Inline below, pls.
> 
> Monday, April 19, 2004, 2:23:48 PM, Pekka Savola wrote:
> > On Fri, 19 Mar 2004, Alex Zinin wrote:
> >> Below is the IETF LC announcement that should have made it to several
> >> lists and hasn't yet
> >> 
> >> http://www1.ietf.org/mail-archive/ietf-announce/Current/msg29135.html
> 
> > FWIW, I looked at this when it was at WG, and I noticed two 
> > operationally particularly bad things that have both bitten us a lot 
> > in our network (and many other networks):
> 
> >  1) the definition of route resolvability in the presence of 
> >     discard/null0/reject/etc. routes is very unfortunate.  That is, if 
> >     you happen to have to have a default route or an aggregate in your 
> >     iBGP, when a router goes down and the loopback matches that route, the 
> >     prefixes that were advertised by the router that went down aren't 
> >     considered unresolvable, but you have to wait for BGP timeout.
> 
> >     There seemed to be no consensus to change this at this point, as a 
> >     DDoS tracing technique depends on that discard/null0 resolvability
> >     "feature".
> >
> >
> >     This was discussed at idr thread:
> > 
> >       issue: bgp4-23: route resolvability and discard/null0 routes
> 
> If memory serves, the discussion resulted in a suggestion to put this
> consideration in one of the accompanying documents. Sue, Yakov, please
> check.

The suggestion on the mailing list was *not* to put this consideration
into one of the accompanying documents, but to produce a *separate*
Internet Draft that cover this (see e-mails on 3/12/2004).
  
> >  2) The definition of active route is bad.  This fails in the 
> >     situation where you need to export loopbacks/point-to-points to 
> >     eBGP, but you have them in youro IGP.  The specification does not
> >     consider them active (not used for forwarding), and they aren't 
> >     exported.
> > 
> >     When the next-hop of the IGP route is the same as BGP next-hop,
> >     obviously this is no problem.  Gargi Nalawade promised to submit 
> >     text, but hasn't, and I think Yakov said something about being 
> >     willing to incorporate that, but obviously hasn't.
> >
> >     This was discussed at idr thread:
> 
> >       issue 11.2: active route, again
> 
> > Otherwise, I think this was operationally good.
> 
> Sue, Yakov, please check if the ball was dropped re this one.

First of all, the consensus of the WG (as documented in 
draft-ietf-idr-bgp-issues) is to have the following 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.

While this text does not cover the case described by Pekka, it does
not preclude it either - handling the case described by Pekka
is just outside the scope of the spec.

With this in mind I suggest that the case described by Pekka
should be covered in a separate Internet Draft.

Yakov.

content-class: urn:content-classes:message
Subject: RE: [Idr] draft-chavali-bgp-prefixlimit-01.txt as an IDR WG document 
From: "Ash, Gerald R (Jerry), ALABS" <[email-masked]>
To: <[email-masked]>, "Yakov Rekhter" <[email-masked]>
Cc: "Ash, Gerald R (Jerry), ALABS" <[email-masked]>
Sender: [email-masked]
Date: Tue, 20 Apr 2004 07:52:08 -0500

> We receive a request to accept draft-chavali-bgp-prefixlimit-01.txt
> as an IDR WG document. Please send comments to the list. The deadline
> for comments is April 29, 2004.

This draft addresses an important issue, and proposes a reasonable approach to address the issue.  I support this becoming a WG document.

Jerry

From: Danny McPherson <[email-masked]>
Subject: Re: [Idr] Multisession as WG doc
To: idr <[email-masked]>
Sender: [email-masked]
Date: Mon, 19 Apr 2004 22:23:01 -0600

On Apr 19, 2004, at 1:42 PM, John G. Scudder wrote:

> Hi Folks,
>
> I'd like to suggest that Multisession BGP 
> (draft-scudder-bgp-multisession-00.txt) be considered as an IDR 
> working group document.

I support this - I'm in favor of making it a WG document.

-danny

To: [email-masked]
From: "John G. Scudder" <[email-masked]>
Subject: [Idr] Multisession as WG doc
Sender: [email-masked]
Date: Mon, 19 Apr 2004 15:42:25 -0400

Hi Folks,

I'd like to suggest that Multisession BGP 
(draft-scudder-bgp-multisession-00.txt) be considered as an IDR 
working group document.

Thanks,

--John

From: Alex Zinin <[email-masked]>
Reply-To: Alex Zinin <[email-masked]>
To: Pekka Savola <[email-masked]>
CC: [email-masked], [email-masked]
Subject: Re: [Idr] FYI: Last Call: 'A Border Gateway Protocol 4 (BGP-4)' to Draft Standard
Sender: [email-masked]
Date: Mon, 19 Apr 2004 14:53:55 -0700

Pekka,

[cc'ing IDR]

Thanks for a careful follow-up. Inline below, pls.

Monday, April 19, 2004, 2:23:48 PM, Pekka Savola wrote:
> On Fri, 19 Mar 2004, Alex Zinin wrote:
>> Below is the IETF LC announcement that should have made it to several
>> lists and hasn't yet
>> 
>> http://www1.ietf.org/mail-archive/ietf-announce/Current/msg29135.html

> FWIW, I looked at this when it was at WG, and I noticed two 
> operationally particularly bad things that have both bitten us a lot 
> in our network (and many other networks):

>  1) the definition of route resolvability in the presence of 
>     discard/null0/reject/etc. routes is very unfortunate.  That is, if 
>     you happen to have to have a default route or an aggregate in your 
>     iBGP, when a router goes down and the loopback matches that route, the 
>     prefixes that were advertised by the router that went down aren't 
>     considered unresolvable, but you have to wait for BGP timeout.

>     There seemed to be no consensus to change this at this point, as a 
>     DDoS tracing technique depends on that discard/null0 resolvability
>     "feature".

>     This was discussed at idr thread:

>       issue: bgp4-23: route resolvability and discard/null0 routes

If memory serves, the discussion resulted in a suggestion to put this
consideration in one of the accompanying documents. Sue, Yakov, please
check.

>  2) The definition of active route is bad.  This fails in the 
>     situation where you need to export loopbacks/point-to-points to 
>     eBGP, but you have them in youro IGP.  The specification does not
>     consider them active (not used for forwarding), and they aren't 
>     exported.

>     When the next-hop of the IGP route is the same as BGP next-hop,
>     obviously this is no problem.  Gargi Nalawade promised to submit 
>     text, but hasn't, and I think Yakov said something about being 
>     willing to incorporate that, but obviously hasn't.

>     This was discussed at idr thread:

>       issue 11.2: active route, again

> Otherwise, I think this was operationally good.

Sue, Yakov, please check if the ball was dropped re this one.

Thanks.

Alex

From: David Meyer <[email-masked]>
To: Alex Zinin <[email-masked]>
Cc: [email-masked]
Subject: Re: [Idr] AD-review comments on draft-ietf-idr-bgp-analysis-04.txt
Sender: [email-masked]
Date: Mon, 19 Apr 2004 13:33:44 -0700

	All, 

	Thanks for the comments. We're working on the update as
	we speak.

	BTW, wrt this:

>> >>    the size of the IPv4 Internet routing table is bounded by O(232 * M),
>> > 
>> > 232 or 2^32?
>> 
>>    Neither makes much sense. Usually one would simply say O(M).
>> 
>> >>    (where M is a slow-moving function describing the AS
>> >>    interconnectivity of the network),
>> > 
>> > slow-moving or slow-growing?
>> 
>>    I believe "slow-moving" is correct -- especially as compared to the
>> speed of the arm-waving inherent in this sentence. ;^)

	what I was trying to get at is that the size of the RIB
	is going to be bounded by something like 2^32
	*<something>, where the <something> represents the
	AS-meshiness, which (in practice) doesn't change at a
	very large rate. So O(M) is incorrect. The basic idea was
	to (attempt to) contrast the size of the RIB with its
	dynamic properties. So do people disagree that the size
	of the RIB is bounded in this way?

	Thanks,

	Dave

>>  I've received some more comments on this document included below.
>>  Please take them into consideration.
>> 
>>  Thanks.
>>  
>> -- 
>> Alex
>> http://www.psg.com/~zinin/
>> 
>> >>     # NLRI       Mean AS Distance       # AS's     Bandwidth (MR)
>>          ^          ^                        ^        ^
>>          N          M                        A        BW
>> >>     ----------   ----------------       ------    ----------------
>> >>     40,000       15                     400        184,000   bytes
>> >>     100,000      10                     10,000     800,000   bytes
>> >>     120,000      10                     15,000     1,080,000 bytes
>> >>     140,000      15                     20,000     1,760,000 bytes
>> >> 
>> >>     [note that most of this bandwidth is consumed by the NLRI exchange]
>> > 
>> > Is the caption for column 3 correct? It says "# AS's", which reads as
>> > "number of AS's" while it seems it should be the number of unique paths.
>> 
>>    The text is clear; but your caption would be better.
>> 
>>    At least here the arithmetic is right.
>> 
>>    BTW, the caption for column 4 is also wrong. "MR" hasn't been
>> introduced yet.
>> 
>> >>    During periods of Internet instability, changes to the reachability
>> >>    information are passed between routers in UPDATE messages.  The
>> > 
>> > While theoretically the text is correct and we could talk about periods
>> > of stability and instability of the Internet, I wonder if this text is
>> > still applicable from the practical perspective. I.e., the continuous
>> > churn that the Internet BGP speakers experience ensures that they
>> > practically always have something to process.
>> 
>>    Agreed: this is as "stable" as we're going to get; we shouldn't call
>> it "instability".
>> 
>> > Probably instead of talking about periods of "Internet stability" and
>> > "Internet instability" we could talk about something like "periods of
>> > stable state among BGP speakers when they do no have new updates to
>> > communicate to each other".
>> 
>>    That's accurate; but I wonder whether it's worth talking about.
>> 
>> > Not sure I follow here. What is meant by the "steady state" here? If it
>> > means convergence on a stable topology after the initial exchange of
>> > updates, then why talk about "stability of the Internet"?
>> 
>>    I took this to mean that whenever a BGP session starts, there's a
>> potentially long initial exchange of routes, and we mean to exclude
>> that startup transient.
>> 
>>    But, of course, we're back to the "stable Internet" paradigm. :^(
>> 
>> > In other words, if the Internet is unstable then can we say that the
>> > BGP speakers are in steady state?
>> 
>>    We can, but it's kind of confusing. I believe the intent was to
>> have a "slightly unstable" Internet causing CPU load which doesn't
>> become visible until we get past the startup transient.
>> 
>> > In the lack of topology changes, it seems that the consumption should
>> > instead depend on the number of peers (affects KEEPALIVE processing)
>> > and the number of persistently oscillating routes potentially present
>> > in the network...
>> 
>>    I'd rather talk in those terms; but it's a rather major rewrite of
>> this section.
>> 
>> >>                                                           This assumes
>> >>    that as the Internet grows,  the overall stability of the inter-AS
>> >>    connectivity of the Internet can be controlled.
>> > 
>> > please specify how it is assumed to be "controlled", e.g. through operational
>> > practices.
>> 
>>    I believe historically this meant route-flap damping.
>> 
>> >>                                                    In particular, while
>> >>    the size of the IPv4 Internet routing table is bounded by O(232 * M),
>> > 
>> > 232 or 2^32?
>> 
>>    Neither makes much sense. Usually one would simply say O(M).
>> 
>> >>    (where M is a slow-moving function describing the AS
>> >>    interconnectivity of the network),
>> > 
>> > slow-moving or slow-growing?
>> 
>>    I believe "slow-moving" is correct -- especially as compared to the
>> speed of the arm-waving inherent in this sentence. ;^)
>> 
>> >>                                       no such bound can be formulated
>> >>    for the dynamic properties (i.e., stability) of BGP.
>> 
>>    There's the "stability" word again. :^(
>> 
>> >>                                                          Although, the
>> >>    dynamic properties of the network cannot be quantitatively bounded,
>> >>    they can be controlled within BGP.  Beyond certain changes in the
>> >>    network, BGP can start to suppress such changes using BGP Route Flap
>> >>    Damping [RFC2439], pacing of its route updates, or BGP would be
>> >>    unable to keep up with the changes and force suppression of multiple
>> >>    changes over very short periods by causing the BGP peer socket to
>> >>    block on the sender.
>> 
>>    The arms are waving again. We list methods of suppressing _some_
>> multiple changes and claim this avoids suppression of multiple changes.
>> (This sentence would be quite correct if we said "force suppression of
>> _all_ changes...")
>> 
>> >> 6.1.2.  Memory requirements
>> >> 
>> >>    To quantify the worst case memory requirements for BGP, we denote the
>> >>    total number of networks in the Internet by N, the mean AS distance
>> >>    of the Internet by M (distance at the level of an autonomous system,
>> >>    expressed in terms of the number of autonomous systems), the total
>> >>    number of unique AS paths as A.  Then the worst case memory
>> >>    requirements (MR) can be expressed as
>> >> 
>> >>            MR = O(N + (M * A))
>> >> 
>> >>    Since a mean AS distance M is a slow moving function of the
>> >>    interconnectivity ("meshiness") of the Internet, for all practical
>> >>    purposes the worst case router memory requirements are on the order
>> >>    of the total number of networks in the Internet times the number of
>> >>    peers the local system is peering with.  We expect that the total
>> >>    number of networks in the Internet will grow much faster than the
>> >>    average number of peers per router.  As a result, BGP's memory
>> >>    scaling properties are linearly related to the total number of
>> >>    networks in the Internet.
>> >> 
>> >>    The following table illustrates typical memory requirements of a
>> >>    router running BGP.  We denote average number of routes advertised by
>> >>    each peer as N, the total number of unique AS paths as A, the mean AS
>> >>    distance of the Internet as M (distance at the level of an autonomous
>> >>    system, expressed in terms of the number of autonomous systems),
>> >>    number of bytes required to store a route as R, and number of bytes
>> >>    required to store one AS in an AS path as P.  It is assumed that each
>> >>    network is encoded as four bytes, each AS is encoded as two bytes,
>> >>    and each networks is reachable via some fraction of all of the peers
>> >>    (# BGP peers/per net).  For purposes of the estimates here, we will
>> >>    calculate MR = ((N * R) + (M * A) * P)
>> 
>>    One is forced to guess that R = 4.
>> 
>>    I think the intent was that P is two times the BGP-peers column.
>> 
>> >>      # Networks  Mean AS Distance # AS's # BGP peers/per net Memory Req (MR)
>>           ^         ^                  ^      ^                 ^
>>           N         M                  A      P (???)           MR
>> >>      ----------  ---------------- ------ ------------------- --------------
>> >>       100,000           20         3,000         20             1,040,000
>> >>       100,000           20        15,000         20             1,040,000
>> >>       120,000           10        15,000        100            75,000,000
>> >>       140,000           15        20,000        100           116,000,000
>> 
>>    Well, to tell truth, I've forgotten how I reproduced two of those MR
>> numbers. But it's certainly obvious they can't all be right; and today I
>> can't reproduce a single one of them.
>> 
>> >>    In analyzing BGP's memory requirements, we focus on the size of the
>> >>    forwarding table (and ignoring implementation details).  In
>> >>    particular, we derive upper bounds for the size of the forwarding
>> >>    table.
>> > 
>> > The above doesn't look like calculations for a forwarding table--the
>> > FIB doesn't normally contact AS-PATH info or all possible paths to a
>> > destination.
>> 
>>    Agreed. I didn't think that was a FIB calculation -- though I never
>> was sure what it was...
>> 
>> 
>> 

From: Alex Zinin <[email-masked]>
Reply-To: Alex Zinin <[email-masked]>
To: [email-masked]
Subject: Re: [Idr] AD-review comments on draft-ietf-idr-bgp-analysis-04.txt
Sender: [email-masked]
Date: Mon, 19 Apr 2004 13:06:50 -0700

Folks-

 I've received some more comments on this document included below.
 Please take them into consideration.

 Thanks.
 
-- 
Alex
http://www.psg.com/~zinin/

>>     # NLRI       Mean AS Distance       # AS's     Bandwidth (MR)
         ^          ^                        ^        ^
         N          M                        A        BW
>>     ----------   ----------------       ------    ----------------
>>     40,000       15                     400        184,000   bytes
>>     100,000      10                     10,000     800,000   bytes
>>     120,000      10                     15,000     1,080,000 bytes
>>     140,000      15                     20,000     1,760,000 bytes
>> 
>>     [note that most of this bandwidth is consumed by the NLRI exchange]
> 
> Is the caption for column 3 correct? It says "# AS's", which reads as
> "number of AS's" while it seems it should be the number of unique paths.

   The text is clear; but your caption would be better.

   At least here the arithmetic is right.

   BTW, the caption for column 4 is also wrong. "MR" hasn't been
introduced yet.

>>    During periods of Internet instability, changes to the reachability
>>    information are passed between routers in UPDATE messages.  The
> 
> While theoretically the text is correct and we could talk about periods
> of stability and instability of the Internet, I wonder if this text is
> still applicable from the practical perspective. I.e., the continuous
> churn that the Internet BGP speakers experience ensures that they
> practically always have something to process.

   Agreed: this is as "stable" as we're going to get; we shouldn't call
it "instability".

> Probably instead of talking about periods of "Internet stability" and
> "Internet instability" we could talk about something like "periods of
> stable state among BGP speakers when they do no have new updates to
> communicate to each other".

   That's accurate; but I wonder whether it's worth talking about.

> Not sure I follow here. What is meant by the "steady state" here? If it
> means convergence on a stable topology after the initial exchange of
> updates, then why talk about "stability of the Internet"?

   I took this to mean that whenever a BGP session starts, there's a
potentially long initial exchange of routes, and we mean to exclude
that startup transient.

   But, of course, we're back to the "stable Internet" paradigm. :^(

> In other words, if the Internet is unstable then can we say that the
> BGP speakers are in steady state?

   We can, but it's kind of confusing. I believe the intent was to
have a "slightly unstable" Internet causing CPU load which doesn't
become visible until we get past the startup transient.

> In the lack of topology changes, it seems that the consumption should
> instead depend on the number of peers (affects KEEPALIVE processing)
> and the number of persistently oscillating routes potentially present
> in the network...

   I'd rather talk in those terms; but it's a rather major rewrite of
this section.

>>                                                           This assumes
>>    that as the Internet grows,  the overall stability of the inter-AS
>>    connectivity of the Internet can be controlled.
> 
> please specify how it is assumed to be "controlled", e.g. through operational
> practices.

   I believe historically this meant route-flap damping.

>>                                                    In particular, while
>>    the size of the IPv4 Internet routing table is bounded by O(232 * M),
> 
> 232 or 2^32?

   Neither makes much sense. Usually one would simply say O(M).

>>    (where M is a slow-moving function describing the AS
>>    interconnectivity of the network),
> 
> slow-moving or slow-growing?

   I believe "slow-moving" is correct -- especially as compared to the
speed of the arm-waving inherent in this sentence. ;^)

>>                                       no such bound can be formulated
>>    for the dynamic properties (i.e., stability) of BGP.

   There's the "stability" word again. :^(

>>                                                          Although, the
>>    dynamic properties of the network cannot be quantitatively bounded,
>>    they can be controlled within BGP.  Beyond certain changes in the
>>    network, BGP can start to suppress such changes using BGP Route Flap
>>    Damping [RFC2439], pacing of its route updates, or BGP would be
>>    unable to keep up with the changes and force suppression of multiple
>>    changes over very short periods by causing the BGP peer socket to
>>    block on the sender.

   The arms are waving again. We list methods of suppressing _some_
multiple changes and claim this avoids suppression of multiple changes.
(This sentence would be quite correct if we said "force suppression of
_all_ changes...")

>> 6.1.2.  Memory requirements
>> 
>>    To quantify the worst case memory requirements for BGP, we denote the
>>    total number of networks in the Internet by N, the mean AS distance
>>    of the Internet by M (distance at the level of an autonomous system,
>>    expressed in terms of the number of autonomous systems), the total
>>    number of unique AS paths as A.  Then the worst case memory
>>    requirements (MR) can be expressed as
>> 
>>            MR = O(N + (M * A))
>> 
>>    Since a mean AS distance M is a slow moving function of the
>>    interconnectivity ("meshiness") of the Internet, for all practical
>>    purposes the worst case router memory requirements are on the order
>>    of the total number of networks in the Internet times the number of
>>    peers the local system is peering with.  We expect that the total
>>    number of networks in the Internet will grow much faster than the
>>    average number of peers per router.  As a result, BGP's memory
>>    scaling properties are linearly related to the total number of
>>    networks in the Internet.
>> 
>>    The following table illustrates typical memory requirements of a
>>    router running BGP.  We denote average number of routes advertised by
>>    each peer as N, the total number of unique AS paths as A, the mean AS
>>    distance of the Internet as M (distance at the level of an autonomous
>>    system, expressed in terms of the number of autonomous systems),
>>    number of bytes required to store a route as R, and number of bytes
>>    required to store one AS in an AS path as P.  It is assumed that each
>>    network is encoded as four bytes, each AS is encoded as two bytes,
>>    and each networks is reachable via some fraction of all of the peers
>>    (# BGP peers/per net).  For purposes of the estimates here, we will
>>    calculate MR = ((N * R) + (M * A) * P)

   One is forced to guess that R = 4.

   I think the intent was that P is two times the BGP-peers column.

>>      # Networks  Mean AS Distance # AS's # BGP peers/per net Memory Req (MR)
          ^         ^                  ^      ^                 ^
          N         M                  A      P (???)           MR
>>      ----------  ---------------- ------ ------------------- --------------
>>       100,000           20         3,000         20             1,040,000
>>       100,000           20        15,000         20             1,040,000
>>       120,000           10        15,000        100            75,000,000
>>       140,000           15        20,000        100           116,000,000

   Well, to tell truth, I've forgotten how I reproduced two of those MR
numbers. But it's certainly obvious they can't all be right; and today I
can't reproduce a single one of them.

>>    In analyzing BGP's memory requirements, we focus on the size of the
>>    forwarding table (and ignoring implementation details).  In
>>    particular, we derive upper bounds for the size of the forwarding
>>    table.
> 
> The above doesn't look like calculations for a forwarding table--the
> FIB doesn't normally contact AS-PATH info or all possible paths to a
> destination.

   Agreed. I didn't think that was a FIB calculation -- though I never
was sure what it was...

To: Yakov Rekhter <[email-masked]>
From: Stephen Kent <[email-masked]>
Subject: Re: [Idr] Re: [saag] draft-iesg-tcpmd5app-00.txt
Cc: Alex Zinin <[email-masked]>, Steve Bellovin <[email-masked]>, [email-masked], [email-masked]
Sender: [email-masked]
Date: Fri, 16 Apr 2004 18:50:54 -0400

At 1:38 PM -0700 4/14/04, Yakov Rekhter wrote:
>Steve,
>
>>  >	<SNIP>
>>  >
>>  >
>>  >Steve, would you mind making a suggestion on how the text could 
>>be improved?
>>  >E.g., would a separate section in the main body of the document specifying
>>  >the requirement for TCP-MD5 support be useful?
>>
>>  A reasonable approach would be to have a section of the document that
>>  describes the use of this TCP option. It should explain why/when one
>>  would use the option in the context of BGP links and what protection
>>  it offers.
>
>Would you please produce the appropriate text for this section.
>
>Thanks in advance.
>
>Yakov.

I'll try to provide some text when I return from vacation, in early May.

Steve

content-class: urn:content-classes:message
Priority: normal
Importance: normal
From: "Miri, Mohammad" <[email-masked]>
To: <[email-masked]>
Subject: [Idr] Peer Prefix Limits Exchange in BGP
Sender: [email-masked]
Date: Fri, 16 Apr 2004 07:28:35 -0500

This is a multi-part message in MIME format.

------_=_NextPart_001_01C423AE.569985C0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

        Title           : Peer Prefix Limits Exchange in BGP=20

        Author(s)       : V. Radoaca, et al.=20

        Filename        : draft-chavali-bgp-prefixlimit-01.txt=20

        Pages           : 14=20

        Date            : 2004-4-12=20

I would like to request this this draft becoming a working group draft.  =
Discussion during IETF=20

58, indicated there was interest from service providers to having this =
become a working group=20

draft.=20

*****
"The information transmitted is intended only for the person or entity =
to which it is addressed and may contain confidential, proprietary, =
and/or privileged material.  Any review, retransmission, dissemination =
or other use of, or taking of any action in reliance upon, this =
information by persons or entities other than the intended recipient is =
prohibited.  If you received this in error, please contact the sender =
and delete the material from all computers."  113

------_=_NextPart_001_01C423AE.569985C0
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<TITLE>Peer Prefix Limits Exchange in BGP </TITLE>
</HEAD>
<BODY>
<!-- Converted from text/plain format -->

<P><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
Title&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; : Peer =
Prefix Limits Exchange in BGP </FONT>
</P>

<P><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
Author(s)&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; : V. Radoaca, et al. =
</FONT>
</P>

<P><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
Filename&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; : =
draft-chavali-bgp-prefixlimit-01.txt </FONT>
</P>

<P><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
Pages&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; : 14 =
</FONT>
</P>

<P><FONT SIZE=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
Date&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; : =
2004-4-12 </FONT>
</P>

<P><FONT SIZE=3D2>I would like to request this this draft becoming a =
working group draft.&nbsp; Discussion during IETF </FONT>
</P>

<P><FONT SIZE=3D2>58, indicated there was interest from service =
providers to having this become a working group </FONT>
</P>

<P><FONT SIZE=3D2>draft. </FONT>
</P>

</BODY>
<!--[object_id=3D#bellsouth.com#]--><FONT face=3DTahoma size=3D2><FONT =
color=3D#0000ff>
<DIR><B><I>
<P align=3Dleft><FONT face=3DTahoma color=3D#000000 =
size=3D2>*****</FONT></P>
<P><FONT face=3DTahoma color=3D#000000 size=3D2>"The information =
transmitted is intended only for the person or entity to which it is =
addressed and may contain confidential, proprietary, and/or privileged =
material. Any review, retransmission, dissemination or other use of, or =
taking of any action in reliance upon, this information by persons or =
entities other than the intended recipient is prohibited. If you =
received this in error, please contact the sender and delete the =
material from all computers." <FONT =
size=3D1>113</P></FONT></FONT></DIR></B></I></FONT></FONT></HTML>
------_=_NextPart_001_01C423AE.569985C0--

To: [email-masked]
From: Yakov Rekhter <[email-masked]>
Subject: [Idr] draft-lange-flexible-bgp-communities-02.txt as an IDR WG document
Sender: [email-masked]
Date: Fri, 16 Apr 2004 14:22:50 -0700

Folks,

It would be greatly appreciated if folks would read the document and 
comment on it to the IDR mailing list. In other words, we need 
"yes, looks good" or "should fix this and that", not just silence.

Thanks in advance.

Yakov.

Date:    Wed, 14 Apr 2004 08:09:52 -0700
From:    Yakov Rekhter <[email-masked]>
To:      [email-masked]
cc:      [email-masked]
Subject: [Idr] draft-lange-flexible-bgp-communities-02.txt as an IDR WG documen
	  t

Folks,

We receive a request to accept draft-lange-flexible-bgp-communities-02.txt
as an IDR WG document. Please send comments to the list. The deadline
for comments is April 28, 2004. 

Yakov.

To: [email-masked]
From: Yakov Rekhter <[email-masked]>
Subject: [Idr] Last Call on draft-ietf-idr-rfc2796bis-00.txt
Sender: [email-masked]
Date: Fri, 16 Apr 2004 14:21:13 -0700

Folks,

During the Last Call it would be greatly appreciated if folks would
read the document and comment on it to the IDR mailing list. In
other words, we need "yes, looks good" or "should fix this and
that", not just silence.

Thanks in advance.

Yakov.

Date:    Wed, 14 Apr 2004 13:36:09 -0700
From:    Yakov Rekhter <[email-masked]>
To:      [email-masked]
Subject: [Idr] WG Last Call on draft-ietf-idr-rfc2796bis-00.txt

Folks,

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

- - --NextPart

	

Send a message to:
	[email-masked].
In the body type:

- - --NextPart

- - --OtherAccess

Content-Type: text/plain

ENCODING mime

- - --OtherAccess

Content-Type: text/plain

- - --OtherAccess--

- - --NextPart--

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

To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: [Idr] I-D ACTION:draft-ietf-idr-restart-09.txt
Sender: [email-masked]
Date: Thu, 15 Apr 2004 16:41:13 -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, et al.
	Filename	: draft-ietf-idr-restart-09.txt
	Pages		: 10
	Date		: 2004-4-15
	
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-09.txt

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

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-09.txt".

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-idr-restart-09.txt".

--NextPart

--OtherAccess

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

ENCODING mime
FILE /internet-drafts/draft-ietf-idr-restart-09.txt

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

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

--OtherAccess--

--NextPart--

Content-class: urn:content-classes:message
Subject: RE: [Idr] draft-chavali-bgp-prefixlimit-01.txt as an IDR WG document
From: "Susan Hares" <[email-masked]>
To: "Pekka Savola" <[email-masked]>, "Yakov Rekhter" <[email-masked]>
Cc: <[email-masked]>
Sender: [email-masked]
Date: Thu, 15 Apr 2004 16:26:00 -0400

Pekka:

<hat-notification-on>
	This is in my hat as an editor of the draft.
	Not in my co-chair hat. 
<hat-notification-off> 

Can you clarify something here:
	1) Your need - informing the remote peer of
		warning limits, stop receive limits, and drop limits
		and SNMP traps, logs etcs

		is the basis for the draft.

	2)  Providers we talk to had 2 cases:
	
		1) creeping VPN prefix limits
		2) dump of whole routing table

		The need to treat the two differently.

	3)  Set until changed - that's the rub

	The providers wanted to negotiate the capabilties and
	upgrade the capabilities without dropping the connect.

	Is that what you mean as well? If so, could you comment
	on what is complex.

History: 
	We started this out with capabilities on open, and dynamic
	capabilities.  Due to some vendor's request to include other
	mechanism (ORF, Soft Notify) to support the dynamic features - 
	we added the rest.

	Other service providers said, Love the function but could you
	do it by prefix lengths.  

	In an effort to get something working for all these folks,
	we made these other features optional.  

What part don't you like?  Cause everything you stated you wanted --
is the basic part of the initial draft?  Did you dis-like the additions
(ORF, Soft Notify) and or the optional sub-codes? 

Do you think we should go back to the initial draft simplistic model?

Sue

-----Original Message-----
From: Pekka Savola [mailto:[email-masked]]
Sent: Thursday, April 15, 2004 11:29 AM
To: Yakov Rekhter
Cc: [email-masked]
Subject: Re: [Idr] draft-chavali-bgp-prefixlimit-01.txt as an IDR WG
document

On Thu, 15 Apr 2004, Yakov Rekhter wrote:
> We receive a request to accept draft-chavali-bgp-prefixlimit-01.txt
> as an IDR WG document. Please send comments to the list. The deadline
> for comments is April 29, 2004. 

The applicability does not seem to be sufficiently clear.

That is, people use prefix limits for a *reason*.  Once set, they're 
set until they are changed.  There's no urgent need to specify 
anything here.

However, I agree that it might not hurt to have some option that could 
be used to inform the peer on your limits, so that:
 - the operator of the peer could notice this when examining the 
neighbor's info (i.e., when contemplating about advertising new 
prefixes), or
 - if the peer exceeded the prefix limits, the peer's operator would 
notice that a warning/stop threshold has been reached (this could 
result in an SNMP trap, flashing led, or whatever.)

I fail to see a need for anything more than that, and the current 
document *seems* to be more complex than that.

Unless I'm mistaken, I'm not sure if going forward with this draft is 
a good idea.

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

Content-class: urn:content-classes:message
Subject: RE: [Idr] draft-chavali-bgp-prefixlimit-01.txt as an IDR WG document
From: "Susan Hares" <[email-masked]>
To: "Jeff Barrows" <[email-masked]>, "Pekka Savola" <[email-masked]>
Cc: "Yakov Rekhter" <[email-masked]>, <[email-masked]>
Sender: [email-masked]
Date: Thu, 15 Apr 2004 16:05:29 -0400

Jeff:

	As an editor of the draft,
I'd like a little bit more detail on what
you think exceeds the level of effort or
complexity.

	The three parameters (warning, stop receive,
drop) [sub-codes 1-3] or the additional parameters
(sub-codes 4,5,6,etc). 

Sue

PS - the additional pieces were put in response to
	a discussion at the IETF.

-----Original Message-----
From: Jeff Barrows [mailto:[email-masked]]
Sent: Thursday, April 15, 2004 1:01 PM
To: Pekka Savola
Cc: Yakov Rekhter; [email-masked]
Subject: Re: [Idr] draft-chavali-bgp-prefixlimit-01.txt as an IDR WG
document

   Not to limit cool/smart thinking, but I believe that
   the level of effort and/or complexity here exceeds
   the return.

   This has never been an issue in any of the major SP
   networks that I've played with.

   While protecting at the edges is of interest, sharing or
   communicating policy [such as thresholds] has been more
   of an area of concern (risk-wise) than a priority.

   An e-mail, phone call, or contractual arrangement should
   suffice in other cases.

  - jsb

> Date: Thu, 15 Apr 2004 18:28:47 +0300 (EEST)
> From: Pekka Savola <[email-masked]>
> To: Yakov Rekhter <[email-masked]>
> Cc: [email-masked]
> Subject: Re: [Idr] draft-chavali-bgp-prefixlimit-01.txt as an IDR WG
>     document
>
> On Thu, 15 Apr 2004, Yakov Rekhter wrote:
> > We receive a request to accept draft-chavali-bgp-prefixlimit-01.txt
> > as an IDR WG document. Please send comments to the list. The deadline
> > for comments is April 29, 2004.
>
> The applicability does not seem to be sufficiently clear.
>
> That is, people use prefix limits for a *reason*.  Once set, they're
> set until they are changed.  There's no urgent need to specify
> anything here.
>
> However, I agree that it might not hurt to have some option that could
> be used to inform the peer on your limits, so that:
>  - the operator of the peer could notice this when examining the
> neighbor's info (i.e., when contemplating about advertising new
> prefixes), or
>  - if the peer exceeded the prefix limits, the peer's operator would
> notice that a warning/stop threshold has been reached (this could
> result in an SNMP trap, flashing led, or whatever.)
>
> I fail to see a need for anything more than that, and the current
> document *seems* to be more complex than that.
>
> Unless I'm mistaken, I'm not sure if going forward with this draft is
> a good idea.
>
> --
> Pekka Savola                 "You each name yourselves king, yet the
> Netcore Oy                    kingdom bleeds."
> Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
>
>

From: Jeff Barrows <[email-masked]>
To: Pekka Savola <[email-masked]>
cc: Yakov Rekhter <[email-masked]>, <[email-masked]>
Subject: Re: [Idr] draft-chavali-bgp-prefixlimit-01.txt as an IDR WG document
Sender: [email-masked]
Date: Thu, 15 Apr 2004 13:00:45 -0400 (EDT)

   Not to limit cool/smart thinking, but I believe that
   the level of effort and/or complexity here exceeds
   the return.

   This has never been an issue in any of the major SP
   networks that I've played with.

   While protecting at the edges is of interest, sharing or
   communicating policy [such as thresholds] has been more
   of an area of concern (risk-wise) than a priority.

   An e-mail, phone call, or contractual arrangement should
   suffice in other cases.

  - jsb

> Date: Thu, 15 Apr 2004 18:28:47 +0300 (EEST)
> From: Pekka Savola <[email-masked]>
> To: Yakov Rekhter <[email-masked]>
> Cc: [email-masked]
> Subject: Re: [Idr] draft-chavali-bgp-prefixlimit-01.txt as an IDR WG
>     document
>
> On Thu, 15 Apr 2004, Yakov Rekhter wrote:
> > We receive a request to accept draft-chavali-bgp-prefixlimit-01.txt
> > as an IDR WG document. Please send comments to the list. The deadline
> > for comments is April 29, 2004.
>
> The applicability does not seem to be sufficiently clear.
>
> That is, people use prefix limits for a *reason*.  Once set, they're
> set until they are changed.  There's no urgent need to specify
> anything here.
>
> However, I agree that it might not hurt to have some option that could
> be used to inform the peer on your limits, so that:
>  - the operator of the peer could notice this when examining the
> neighbor's info (i.e., when contemplating about advertising new
> prefixes), or
>  - if the peer exceeded the prefix limits, the peer's operator would
> notice that a warning/stop threshold has been reached (this could
> result in an SNMP trap, flashing led, or whatever.)
>
> I fail to see a need for anything more than that, and the current
> document *seems* to be more complex than that.
>
> Unless I'm mistaken, I'm not sure if going forward with this draft is
> a good idea.
>
> --
> Pekka Savola                 "You each name yourselves king, yet the
> Netcore Oy                    kingdom bleeds."
> Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
>
>

From: Keyur Patel <[email-masked]>
To: Alex Zinin <[email-masked]>
CC: [email-masked]
Subject: Re: [Idr] AD-review comments on draft-ietf-idr-bgp-analysis-04.txt
Sender: [email-masked]
Date: Thu, 15 Apr 2004 10:06:50 -0700

Alex:
Thanks for the comments. We will incorporate them.
-Keyur

Alex Zinin wrote:

>Folks-
>
>I have some technical comments regarding periods of stability and instability in
>the Internet, BGP steady state, and the security considerations, plus several
>editorial remarks.
>
>See inline below, please.
>
>  
>
>>2.1.  Key Features
>>    
>>
>...
>  
>
>>   One of the most important path attributes is the Autonomous System
>>   Path, or AS_PATH.  AS reachability information traverses the
>>    
>>
>                        ^^
>                        "As"
>
>  
>
>>   Internet, this information is augmented by the list of autonomous
>>   systems that have been traversed thus far, forming the AS_PATH.  The
>>   AS_PATH allows straightforward suppression of the looping of routing
>>   information.  In addition, the AS_PATH serves as a powerful and
>>   versatile mechanism for policy-based routing.
>>
>>   BGP enhances the AS_PATH attribute to include sets of autonomous
>>   systems as well as lists via the AS_SET attribute.  This extended
>>   format allows generated aggregate routes to carry path information
>>   from the more specific routes used to generate the aggregate.  It
>>   should be noted however, that as of this writing, AS_SETs are rarely
>>   used in the Internet [ROUTEVIEWS].
>>
>>
>>
>>2.2.  BGP Algorithms
>>
>>
>>   BGP uses an algorithm that is neither a pure distance vector
>>   algorithm or a pure link state algorithm.  It is instead a modified
>>   distance vector algorithm referred to as a "Path Vector" algorithm
>>   that uses path information to avoid traditional distance vector
>>   problems.  Each route within BGP pairs destination with path
>>   information to that destination.  Path information (also known as
>>   AS_PATH information) is stored within the AS_PATH attribute in BGP.
>>   This allows BGP to reconstruct large portions of overall topology
>>   whenever required.
>>    
>>
>
>I've always been uncomfortable with documents saying that BGP reconstructs the
>overall topology. It doesn't really do this like the link-state protocols do,
>for example.
>
>  
>
>>   BGP uses an incremental update strategy in order to conserve
>>   bandwidth and processing power.  That is, after initial exchange of
>>   complete routing information, a pair of BGP routers exchanges only
>>   changes to that information.  Such an incremental update design
>>   requires reliable transport between a pair of BGP routers to function
>>   correctly.  BGP solves this problem by using TCP for reliable
>>   transport.
>>    
>>
>
>Should also note that use of TCP as the transport mechanism helps control
>congestion and CPU utilization.
>
>  
>
>>   In addition to incremental updates, BGP has added the concept of
>>   route aggregation so that information about groups of networks may be
>>
>>
>>
>>Meyer and Patel                                   Section 2.2.  [Page 5]
>>
>>INTERNET-DRAFT             Expires: March 2004            September 2003
>>
>>
>>   aggregated and sent as a single Network Layer Reachability (NLRI).
>>    
>>
>
>this doesn't read well. Neither "reachability" nor "information" are countable.
>"Single prefix" instead?
>
>  
>
>>   Finally, note that BGP is a self-contained protocol.  That is, BGP
>>   specifies how routing information is exchanged both between BGP
>>   speakers in different autonomous systems, and between BGP speakers
>>   within a single autonomous system.
>>
>>
>>
>>2.3.  BGP Finite State Machine (FSM)
>>
>>
>>   The BGP FSM is a set of rules that are applied to a BGP speaker's set
>>   of configured peers for the BGP operation.  A BGP implementation
>>   requires that a BGP speaker must connect to and listen on TCP port
>>   179 for accepting any new BGP connections from its peers.  The BGP
>>   Finite State Machine, or FSM, must be initiated and maintained for
>>   each new incoming and outgoing peer connections.  However, in steady
>>   state operation, there will be only one BGP FSM per connection per
>>   peer.
>>
>>   There may exist a temporary period where in a BGP peer may have
>>   separate incoming and outgoing connections resulting into two
>>   different BGP FSMs for a peer (instead of one).  This can be resolved
>>   following BGP connection collision rules defined in the [BGP4].
>>
>>   Following are different states of BGP FSM for its peers:
>>
>>   IDLE:           State when BGP peer refuses any incoming
>>                   connections.
>>
>>   CONNECT:        State in which BGP peer is waiting for
>>                   its TCP connection to be completed.
>>
>>   ACTIVE:         State in which BGP peer is trying to acquire a
>>                   peer by listening and accepting TCP connection.
>>
>>   OPENSENT:       BGP peer is waiting for OPEN message from its
>>                   peer.
>>
>>   OPENCONFIRM:    BGP peer is waiting for KEEPALIVE or NOTIFICATION
>>                   message from its peer.
>>
>>   ESTABLISHED:    BGP peer connection is established and exchanges
>>                   UPDATE, NOTIFICATION, and KEEPALIVE messages with
>>                   its peer.
>>
>>   There are different BGP events that operate on above mentioned states
>>
>>
>>
>>Meyer and Patel                                   Section 2.3.  [Page 6]
>>
>>INTERNET-DRAFT             Expires: March 2004            September 2003
>>
>>
>>   of BGP FSM for its peers.  These BGP events are used for initiating and
>>   terminating peer connections.  They also assist BGP in identifying any
>>   persistent peer connection oscillations and provide a mechanism
>>   for controlling them.
>>
>>   Following are different BGP events:
>>
>>   Manual Start:           Manually start the peer connection.
>>
>>   Manual Stop:            Manually stop the peer connection.
>>
>>   Automatic Start:        Local system automatically starts the peer
>>                           connection.
>>
>>   Manual start with
>>   passive TCP flag:       Local system administrator manually starts the
>>                           peer connection with peer in passive mode.
>>
>>   Automatic start
>>   with passive TCP flag:  Local system administrator automatically starts
>>                           the peer connection with peer in passive mode.
>>
>>   Automatic start
>>   with bgp_stop_flap
>>   option set:             Local system administrator automatically starts
>>                           the peer connection with peer oscillation
>>                           damping enabled.
>>
>>   Automatic start with
>>   bgp_stop_flap option
>>   set and passive TCP
>>   establishment
>>   option set:             Local system administrator automatically starts
>>                           the peer connection with peer oscillation
>>                           damping enabled and with peer in passive mode.
>>
>>   Automatic stop:         Local system automatically stops the
>>                           BGP connection.
>>
>>   Both, Manual Start and Manual Stop are mandatory BGP events.  All
>>   other events are optional.
>>
>>    
>>
>
>Ummmm... the above are "administrative" events only. There are other events in
>the FSM, and most of other events are mandatory.
>
>  
>
>>
>>
>>
>>
>>
>>
>>Meyer and Patel                                   Section 2.3.  [Page 7]
>>
>>INTERNET-DRAFT             Expires: March 2004            September 2003
>>
>>
>>3.  BGP Capabilities
>>
>>
>>   The BGP Capability mechanism [RFC2842] provides an easy and flexible
>>   way to introduce new features within the protocol.  In particular,
>>   the BGP capability mechanism allows peers to negotiate various
>>   optional features during startup.  This allows the base BGP protocol
>>   to contain only essential functionality, while at the same time
>>   providing a flexible mechanism for signaling protocol extensions.
>>
>>
>>
>>4.  BGP Persistent Peer Oscillations
>>
>>
>>   Ideally, whenever a BGP speaker detects an error in any peer
>>   connection, it shuts down the peer and changes its FSM state to IDLE.
>>   BGP speaker requires a Start event to re-initiate its idle peer
>>   connection.  If the error remains persistent and BGP speaker
>>   generates Start event automatically then it may result in persistent
>>   peer flapping.  However, although peer oscillation is found to be
>>   wide-spread in BGP implementations, methods for preventing persistent
>>   peer oscillations are outside the scope of base BGP protocol
>>   specification.
>>
>>
>>
>>5.  Implementation Guidelines
>>
>>
>>   A robust BGP implementation is work conserving.  This means that if
>>   the number of prefixes is bound, arbitrarily high levels of route
>>   change can be tolerated with bounded impact on route convergence for
>>   occasionally changes in generally stable routes.
>>    
>>
>
>"occasional"?
>
>  
>
>>   A BGP implementation under high load conditions should empty as much
>>   inbound routing updates from its input streams, processing only the
>>   most recent route if the route for a given NLRI changes multiple
>>   times.  TCP also provides blocking on the writes on the sender side.
>>   A BGP implementation under load should expect blocks on write calls
>>   and send only the most recent routes when sockets unblock rather than
>>   sending entire history.
>>
>>   A robust implementation of BGP should have the following
>>   characteristics:
>>         1.  It is able to operate in almost arbitrarily high levels
>>             of route flap without loosing peerings (failing to send
>>             keepalives) or loosing other protocol adjacencies as a
>>
>>
>>
>>Meyer and Patel                                     Section 5.  [Page 8]
>>
>>INTERNET-DRAFT             Expires: March 2004            September 2003
>>
>>
>>             result of BGP load.
>>
>>         2.  Instability of a subset of routes should not affect the
>>             route advertisements or forwarding associated with the set
>>             of stable routes.
>>
>>         3.  High levels of instability and peers of different CPU speed
>>             or load resulting in faster or slower processing of routes
>>             should not cause instability and should have a bounded
>>             impact on the convergence time for generally stable routes.
>>
>>   Numerous robust BGP implementations exist.  Producing a robust
>>   implementation is not a trivial matter but clearly achievable.
>>
>>
>>
>>
>>6.  BGP Performance characteristics and Scalability
>>
>>
>>   In this section, we provide "order of magnitude" answers to the
>>   questions of how much link bandwidth, router memory and router CPU
>>   cycles the BGP protocol will consume under normal conditions.  In
>>   particular, we will address the scalability of BGP and its
>>   limitations.
>>
>>
>>
>>6.1.  Link bandwidth and CPU utilization
>>
>>
>>   Immediately after the initial BGP connection setup, BGP peers
>>   exchange complete set of routing information.  If we denote the total
>>   number of routes in the Internet by N, the mean AS distance of the
>>   Internet by M (distance at the level of an autonomous system,
>>   expressed in terms of the number of autonomous systems), the total
>>   number of unique AS paths by A, and assume that the networks are
>>   uniformly distributed among the autonomous systems, then the worst
>>   case amount of bandwidth consumed during the initial exchange between
>>   a pair of BGP speakers is
>>
>>           BW = O(N + (M * A))
>>
>>   The following table illustrates the typical amount of bandwidth
>>   consumed during the initial exchange between a pair of BGP speakers
>>   based on the above assumptions (ignoring bandwidth consumed by the
>>   BGP Header).  For purposes of the estimates here, we will calculate
>>   BW = 4 * (N + (M * A)).
>>
>>
>>
>>Meyer and Patel                                   Section 6.1.  [Page 9]
>>
>>INTERNET-DRAFT             Expires: March 2004            September 2003
>>
>>
>>    # NLRI       Mean AS Distance       # AS's     Bandwidth (MR)
>>    ----------   ----------------       ------    ----------------
>>    40,000       15                     400        184,000   bytes
>>    100,000      10                     10,000     800,000   bytes
>>    120,000      10                     15,000     1,080,000 bytes
>>    140,000      15                     20,000     1,760,000 bytes
>>
>>    [note that most of this bandwidth is consumed by the NLRI exchange]
>>    
>>
>
>Is the caption for column 3 correct? It says "# AS's", which reads as "number of
>AS's" while it seems it should be the number of unique paths.
>  
>
>>   BGP was created specifically to reduce the size of the set of NLRI
>>   entries which have to be carried and exchanged by border routers.
>>   The aggregation scheme, defined in RFC 1519 [RFC1519], describes the
>>   provider-based aggregation scheme in use in today's Internet.
>>
>>   Due to the advantages of advertising a few large aggregate blocks
>>   instead of many smaller class-based individual networks, it is
>>   difficult to estimate the actual reduction in bandwidth and
>>   processing that BGP has provided over BGP-3.  If we simply enumerate
>>   all aggregate blocks into their individual class-based networks, we
>>   would not take into account "dead" space that has been reserved for
>>   future expansion.  The best metric for determining the success of
>>   BGP's aggregation is to sample the number NLRI entries in the
>>   globally connected Internet today and compare it to projected growth
>>   rates before BGP was deployed.
>>
>>   At the time of this writing, the full set of exterior routes carried
>>   by BGP is approximately 120,000 network entries [ROUTEVIEWS].
>>
>>
>>
>>6.1.1.  CPU utilization
>>
>>
>>   An important and fundamental feature of BGP is that BGP's CPU
>>   utilization depends only on the stability of the Internet.  If the
>>   Internet is stable, then the only link bandwidth and router CPU
>>   cycles consumed by BGP are due to the exchange of the BGP KEEPALIVE
>>   messages.  The KEEPALIVE messages are exchanged only between peers.
>>   The suggested frequency of the exchange is 30 seconds.  The KEEPALIVE
>>   messages are quite short (19 octets), and require virtually no
>>   processing.  As a result, the bandwidth consumed by the KEEPALIVE
>>   messages is about 5 bits/sec.  Operational experience confirms that
>>   the overhead (in terms of bandwidth and CPU) associated with the
>>   KEEPALIVE messages should be viewed as negligible.
>>
>>   During periods of Internet instability, changes to the reachability
>>   information are passed between routers in UPDATE messages.  The
>>    
>>
>
>While theoretically the text is correct and we could talk about periods of
>stability and instability of the Internet, I wonder if this text is still
>applicable from the practical perspective. I.e., the continuous churn that the
>Internet BGP speakers experience ensures that they practically always have
>something to process.
>
>Probably instead of talking about periods of "Internet stability" and "Internet
>instability" we could talk about something like "periods of stable state among
>BGP speakers when they do no have new updates to communicate to each other".
>
>  
>
>>Meyer and Patel                                Section 6.1.1.  [Page 10]
>>
>>INTERNET-DRAFT             Expires: March 2004            September 2003
>>
>>
>>   greatest overhead per UPDATE message occurs when each UPDATE message
>>   contains only a single network.  It should be pointed out that in
>>   practice routing changes exhibit strong locality with respect to the
>>   AS path.  That is, routes that change are likely to have common AS
>>   path.  In this case, multiple networks can be grouped into a single
>>   UPDATE message, thus significantly reducing the amount of bandwidth
>>   required (see also Appendix F.1 of [BGP4]).
>>
>>   Since in the steady state the link bandwidth and router CPU cycles
>>   consumed by the BGP protocol are dependent only on the stability of
>>   the Internet, it follows that BGP should have no scaling problems in
>>   the areas of link bandwidth and router CPU utilization.
>>    
>>
>
>Not sure I follow here. What is meant by the "steady state" here? If it means
>convergence on a stable topology after the initial exchange of updates, then why
>talk about "stability of the Internet"? In other words, if the Internet is
>unstable then can we say that the BGP speakers are in steady state? In the lack
>of topology changes, it seems that the consumption should instead depend on the
>number of peers (affects KEEPALIVE processing) and the number of persistently
>oscillating routes potentially present in the network...
>
>  
>
>>This assumes
>>   that as the Internet grows,  the overall stability of the inter-AS
>>   connectivity of the Internet can be controlled.
>>    
>>
>
>please specify how it is assumed to be "controlled", e.g. through operational
>practices.
>
>  
>
>>In particular, while
>>   the size of the IPv4 Internet routing table is bounded by O(232 * M),
>>    
>>
>
>232 or 2^32?
>
>  
>
>>   (where M is a slow-moving function describing the AS
>>   interconnectivity of the network),
>>    
>>
>
>slow-moving or slow-growing?
>
>  
>
>>no such bound can be formulated
>>   for the dynamic properties (i.e., stability) of BGP.  Although, the
>>   dynamic properties of the network cannot be quantitatively bounded,
>>   they can be controlled within BGP.  Beyond certain changes in the
>>   network, BGP can start to suppress such changes using BGP Route Flap
>>   Damping [RFC2439], pacing of its route updates, or BGP would be
>>   unable to keep up with the changes and force suppression of multiple
>>   changes over very short periods by causing the BGP peer socket to
>>   block on the sender.
>>
>>
>>
>>6.1.2.  Memory requirements
>>
>>
>>   To quantify the worst case memory requirements for BGP, we denote the
>>   total number of networks in the Internet by N, the mean AS distance
>>   of the Internet by M (distance at the level of an autonomous system,
>>   expressed in terms of the number of autonomous systems), the total
>>   number of unique AS paths as A.  Then the worst case memory
>>   requirements (MR) can be expressed as
>>
>>
>>           MR = O(N + (M * A))
>>
>>
>>   Since a mean AS distance M is a slow moving function of the
>>   interconnectivity ("meshiness") of the Internet, for all practical
>>   purposes the worst case router memory requirements are on the order
>>   of the total number of networks in the Internet times the number of
>>   peers the local system is peering with.  We expect that the total
>>   number of networks in the Internet will grow much faster than the
>>
>>
>>
>>Meyer and Patel                                Section 6.1.2.  [Page 11]
>>
>>INTERNET-DRAFT             Expires: March 2004            September 2003
>>
>>
>>   average number of peers per router.  As a result, BGP's memory
>>   scaling properties are linearly related to the total number of
>>   networks in the Internet.
>>
>>   The following table illustrates typical memory requirements of a
>>   router running BGP.  We denote average number of routes advertised by
>>   each peer as N, the total number of unique AS paths as A, the mean AS
>>   distance of the Internet as M (distance at the level of an autonomous
>>   system, expressed in terms of the number of autonomous systems),
>>   number of bytes required to store a route as R, and number of bytes
>>   required to store one AS in an AS path as P.  It is assumed that each
>>   network is encoded as four bytes, each AS is encoded as two bytes,
>>   and each networks is reachable via some fraction of all of the peers
>>   (# BGP peers/per net).  For purposes of the estimates here, we will
>>   calculate MR = ((N * R) + (M * A) * P)
>>
>>
>>     # Networks  Mean AS Distance # AS's # BGP peers/per net Memory Req (MR)
>>     ----------  ---------------- ------ ------------------- --------------
>>      100,000           20         3,000         20             1,040,000
>>      100,000           20        15,000         20             1,040,000
>>      120,000           10        15,000        100            75,000,000
>>      140,000           15        20,000        100           116,000,000
>>
>>
>>   In analyzing BGP's memory requirements, we focus on the size of the
>>   forwarding table (and ignoring implementation details).  In
>>   particular, we derive upper bounds for the size of the forwarding
>>   table.
>>    
>>
>
>The above doesn't look like calculations for a forwarding table--the FIB doesn't
>normally contact AS-PATH info or all possible paths to a destination.
>
>  
>
>>11.  Security Considerations
>>
>>
>>   This document presents an analysis of the BGP protocol and as such
>>   presents no new security implications for BGP.
>>    
>>
>
>I'm afraid the IESG will expect to see some more here. Specifically, I would
>suggest that the document talks about available security mechanisms, and the
>analysis of how they affect processing overhead, BW, and scalability.
>Certainly a pointer to the bgp-vuln document would be useful.
>
>Alex
>
>

From: Srikanth Chavali <[email-masked]>
To: Pekka Savola <[email-masked]>
CC: Yakov Rekhter <[email-masked]>, [email-masked]
Subject: Re: [Idr] draft-chavali-bgp-prefixlimit-01.txt as an IDR WG document
Sender: [email-masked]
Date: Thu, 15 Apr 2004 12:06:36 -0400

Hi Pekka ,

Pekka Savola wrote:

>I fail to see a need for anything more than that, and the current 
>document *seems* to be more complex than that.
>
>Unless I'm mistaken, I'm not sure if going forward with this draft is 
>  
>
>a good idea.
>
The draft addresses the issue described on a per AFI/SAFI pair and hence 
the need for additional mechanism.
The requirement for different limits has come from the SPs which is why 
that is included. Thats the reason for
tailoring the mechanism around it.

srikanth chavali

From: Pekka Savola <[email-masked]>
To: Yakov Rekhter <[email-masked]>
cc: [email-masked]
Subject: Re: [Idr] draft-chavali-bgp-prefixlimit-01.txt as an IDR WG document
Sender: [email-masked]
Date: Thu, 15 Apr 2004 18:28:47 +0300 (EEST)

On Thu, 15 Apr 2004, Yakov Rekhter wrote:
> We receive a request to accept draft-chavali-bgp-prefixlimit-01.txt
> as an IDR WG document. Please send comments to the list. The deadline
> for comments is April 29, 2004. 

The applicability does not seem to be sufficiently clear.

That is, people use prefix limits for a *reason*.  Once set, they're 
set until they are changed.  There's no urgent need to specify 
anything here.

However, I agree that it might not hurt to have some option that could 
be used to inform the peer on your limits, so that:
 - the operator of the peer could notice this when examining the 
neighbor's info (i.e., when contemplating about advertising new 
prefixes), or
 - if the peer exceeded the prefix limits, the peer's operator would 
notice that a warning/stop threshold has been reached (this could 
result in an SNMP trap, flashing led, or whatever.)

I fail to see a need for anything more than that, and the current 
document *seems* to be more complex than that.

Unless I'm mistaken, I'm not sure if going forward with this draft is 
a good idea.

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

From: Srikanth Chavali <[email-masked]>
To: [email-masked]
Subject: [Idr] [Fwd: I-D ACTION:draft-chavali-bgp-prefixlimit-01.txt]
Sender: [email-masked]
Date: Thu, 15 Apr 2004 10:01:38 -0400

This is a multi-part message in MIME format.
--------------080105020709010800040801
Content-Type: multipart/alternative;
 boundary="------------020505080408090500090101"

--------------020505080408090500090101
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

FYI:

-------- Original Message --------
Subject: 	I-D ACTION:draft-chavali-bgp-prefixlimit-01.txt
Date: 	Mon, 12 Apr 2004 15:31:26 -0400
From: 	[email-masked]
Reply-To: 	[email-masked]
To: 	[email-masked]

	Title		: Peer Prefix Limits Exchange in BGP
	Author(s)	: V. Radoaca, et al.
	Filename	: draft-chavali-bgp-prefixlimit-01.txt
	Pages		: 14
	Date		: 2004-4-12
	
This document proposes a mechanism to allow BGP peers to coordinate
the setting of a limit on the number of prefixes which one BGP
speaker will send to its peer.  Coordination can prevent disruption
of the peering session or discarding of routes, which can occur when
a maximum prefix limit is configured on the 'receiving' peer, and the
'sending' peer exceeds the limit.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-chavali-bgp-prefixlimit-01.txt

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

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-chavali-bgp-prefixlimit-01.txt".

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-chavali-bgp-prefixlimit-01.txt".

--------------020505080408090500090101
Content-Type: text/html; charset=us-ascii
Content-Transfer-Encoding: 7bit

<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
  <meta http-equiv="Content-Type" content="text/html;charset=ISO-8859-1">
  <title></title>
</head>
<body text="#000000" bgcolor="#ffffff">
FYI:<br>
<br>
-------- Original Message --------
<table cellpadding="0" cellspacing="0" border="0">
  <tbody>
    <tr>
      <th valign="baseline" align="right" nowrap="nowrap">Subject: </th>
      <td>I-D ACTION:draft-chavali-bgp-prefixlimit-01.txt</td>
    </tr>
    <tr>
      <th valign="baseline" align="right" nowrap="nowrap">Date: </th>
      <td>Mon, 12 Apr 2004 15:31:26 -0400</td>
    </tr>
    <tr>
      <th valign="baseline" align="right" nowrap="nowrap">From: </th>
      <td><a class="moz-txt-link-abbreviated" href="mailto:[email-masked]">[email-masked]</a></td>
    </tr>
    <tr>
      <th valign="baseline" align="right" nowrap="nowrap">Reply-To: </th>
      <td><a class="moz-txt-link-abbreviated" href="mailto:[email-masked]">[email-masked]</a></td>
    </tr>
    <tr>
      <th valign="baseline" align="right" nowrap="nowrap">To: </th>
      <td><a class="moz-txt-link-abbreviated" href="mailto:[email-masked]">[email-masked]</a></td>
    </tr>
  </tbody>
</table>
<br>
<br>
<pre>A New Internet-Draft is available from the on-line Internet-Drafts directories.

	Title		: Peer Prefix Limits Exchange in BGP
	Author(s)	: V. Radoaca, et al.
	Filename	: draft-chavali-bgp-prefixlimit-01.txt
	Pages		: 14
	Date		: 2004-4-12
	
This document proposes a mechanism to allow BGP peers to coordinate
the setting of a limit on the number of prefixes which one BGP
speaker will send to its peer.  Coordination can prevent disruption
of the peering session or discarding of routes, which can occur when
a maximum prefix limit is configured on the 'receiving' peer, and the
'sending' peer exceeds the limit.

A URL for this Internet-Draft is:
<a class="moz-txt-link-freetext" href="http://www.ietf.org/internet-drafts/draft-chavali-bgp-prefixlimit-01.txt">http://www.ietf.org/internet-drafts/draft-chavali-bgp-prefixlimit-01.txt</a>

To remove yourself from the I-D Announcement list, send a message to 
<a class="moz-txt-link-abbreviated" href="mailto:[email-masked]">[email-masked]</a> with the word unsubscribe in the body of the message.  
You can also visit <a class="moz-txt-link-freetext" href="https://www1.ietf.org/mailman/listinfo/I-D-announce">https://www1.ietf.org/mailman/listinfo/I-D-announce</a> 
to change your subscription settings.

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-chavali-bgp-prefixlimit-01.txt".

A list of Internet-Drafts directories can be found in
<a class="moz-txt-link-freetext" href="http://www.ietf.org/shadow.html">http://www.ietf.org/shadow.html</a> 
or <a class="moz-txt-link-freetext" href="ftp://ftp.ietf.org/ietf/1shadow-sites.txt">ftp://ftp.ietf.org/ietf/1shadow-sites.txt</a>

Send a message to:
	<a class="moz-txt-link-abbreviated" href="mailto:[email-masked]">[email-masked]</a>.
In the body type:
	"FILE /internet-drafts/draft-chavali-bgp-prefixlimit-01.txt".

</pre>
</body>
</html>

--------------020505080408090500090101--

--------------080105020709010800040801
Content-Type: Message/External-body;
 name="draft-chavali-bgp-prefixlimit-01.txt"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
 filename="draft-chavali-bgp-prefixlimit-01.txt"
Content-Transfer-Encoding: 7bit

--------------080105020709010800040801--

To: [email-masked]
From: Yakov Rekhter <[email-masked]>
Subject: [Idr] draft-chavali-bgp-prefixlimit-01.txt as an IDR WG document
Sender: [email-masked]
Date: Thu, 15 Apr 2004 06:59:54 -0700

Folks,

We receive a request to accept draft-chavali-bgp-prefixlimit-01.txt
as an IDR WG document. Please send comments to the list. The deadline
for comments is April 29, 2004. 

Yakov.

To: [email-masked], [email-masked]
cc: [email-masked], [email-masked], [email-masked], [email-masked]
From: Yakov Rekhter <[email-masked]>
Subject: [Idr] BGP Cease subcodes to Proposed Standard
Sender: [email-masked]
Date: Thu, 15 Apr 2004 06:48:22 -0700

Alex and Bill,

The IDR WG would like to ask the IESG to advance BGP Cease Subcodes
(draft-ietf-idr-cease-subcode-04.txt) to a Proposed Standard.

The implementation report is in draft-chen-bgp-cease-subcode-survey-00.txt.

Yakov.

Content-class: urn:content-classes:message
From: "Susan Hares" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>
Subject: [Idr] draft-chavali-bgp-prefixlimit-01.txt
Sender: [email-masked]
Date: Thu, 15 Apr 2004 09:39:19 -0400

I would like to request this this draft becoming
a working group draft.  Discussion during IETF
58, indicated there was interest from service
providers to having this become a working group
draft.

Sue
----------

	Title		: Peer Prefix Limits Exchange in BGP
	Author(s)	: V. Radoaca, et al.
	Filename	: draft-chavali-bgp-prefixlimit-01.txt
	Pages		: 14
	Date		: 2004-4-12

Abstract:
This document proposes a mechanism to allow BGP peers to 
coordinate the setting of a lmit on the number of prefix 
which one BGP speaker will send to its peer. Coordination
can prevent disruption of the peering session or discarding 
of routes, which can occur when a maximum prefix limit is 
configured on the "receiving" peer, and the "sending" peer
exceeds the limit.

From: Alex Zinin <[email-masked]>
Reply-To: Alex Zinin <[email-masked]>
To: [email-masked]
Subject: [Idr] AD-review comments on draft-ietf-idr-bgp4-experience-protocol-03.txt
Sender: [email-masked]
Date: Wed, 14 Apr 2004 19:55:25 -0700

Folks-

 I'm generally quite happy with this document. The only comment I had was about
 the way the 2119 requirements language is used. In some places (simple search
 for "MUST" would reveal), the document reads as defining protocol procedures,
 which should be in the protocol spec. If the intention is to quote the spec,
 the wording should be changed accordingly.

 Refs to SBGP and SoBGP should be filled in.

 Thanks.

Alex

From: Alex Zinin <[email-masked]>
Reply-To: Alex Zinin <[email-masked]>
To: [email-masked]
Subject: [Idr] AD-review comments on draft-ietf-idr-bgp-implementation-00.txt
Sender: [email-masked]
Date: Wed, 14 Apr 2004 19:41:51 -0700

Folks-

Several comments inline below.

> 1.1 General
>     
>     This draft of BGP-4 attempts to bring BGP standard as described in 

Seems like this is out of context.

>     RFC 1771 in alignment with the deployments of the BGP-4 protocols.   
>     The changes with RFC 1771 are listed in the appendix A of[BGP4].   
>     BGP-4 as deployed in the Internet encompasses both this base 
>     specification and additional specifications such as TCP MD5 
>     [RFC2385], BGP Route Reflectors [RFC 2796], BGP Confederations   
>     [RFC3065], and BGP Route Refresh [RFC 2918].  
>             
>     BGP as a widely deployed cornerstone of Internet technology 
>     continues to add additional functionality as the needs within the 
>     Internet require. This survey had 259 detailed questions on the 
>     compliances with the standard.  3 implementers (Cisco, Laurel, 
>     NextHop) sent in implementation reports.  Sections X - Y provides 
>     the compilation of those results. 
>       
>     X implementers who responded below indicating inter-operability with 
>     other implementations.  Of these X implementations, Y also indicated 
>     the length of the survey was as problem. The editor recommends that 
>     other methods, such as enlisting existing testing vendors be 
>     employed to gather more implementation report. 
>      
>     Section Z provides the quick survey results on inter-operability.  
>     
>  
>  
> Hares & Retana          Expires - August 2004                [Page 3] 
> 
> 
> 
> 
>                  draft-ietf-idr-bgp-implementation-00    February 2004 
>  
>  

X, Y, and Z need to be filled out... ;)

> 1.2 Full Survey result summary 
>      
>     Significant Differences 
>       
>     All 259 survey points had two "y" or "y" and "O" except the 
>     following: 

At this point of the document, it is not clear what "y" and "0" are.

Generally, if we don't have at least two implementations for a specific feature,
it can't stay in the spec. The granularity of the BGP implementation report
is finer than on a per-feature basis, but we still need to see if the spec needs
to be fixed accordingly. More specific comments below:

>       MUST - Question 214 
>        
>       Question 214 about aggregation of  routes. section 9.1.4 had a "N" 
>       response from 3 implementers indicating that they install both 
>       routes, and 1 yes. 

when I look at section 2.43.214, I see:

       Alcatel Y/N/O/Comments: Y
       Cisco   Y/N/O/Comments: Y 
       Laurel  Y/N/O/Comments: Y 
       NextHop Y/N/O/Comments: Y 

wrong section?

>       SHALL NOT - Question 228, regarding section 9.2.2.2 
>        
>       Three vendors (Alcatel, Cisco, Laurel), answered "N" to shall not 
>       (meaning they did).  One vendor (NextHop) indicate "y" matching 
>       the specification. 
>        
>         text: Routes that have different MULTI_EXIT_DISC attribute SHALL 
>         NOT be aggregated. 

If this is considered to be important for protocol correctness, then the WG
may consider softening the requirements language and changing it to "SHOULD
NOT"--apparently some implementers found that under certain circumstances
such routes still need to be aggregated.

>       SHOULD - 2 in appendix F (questions 257, 258)
>        
>       Three vendors said no, one vendor said yes to question 257.  All 
>       four vendors indicated no to question 258. (Please note that 
>       Appendix F is an optional text section) 
>         
>        Text: section F.2 - A BGP speaker which needs to withdraw a 
>        destination and send an update about a more specific or less  
>        specific route SHOULD combine them into the same UPDATE message.  
>         
>        Text: Section F.6: The last instance (rightmost occurrence) of 
>        that AS number is kept.

Assuming that the appendices are not a normative part of the spec, the
2119 language should not be used there.

...
> 1.4 Implementations and interoperability
>     
>    Short informal summary of implementers reporting implementations and 
>    inter-operability 
>      
>      [This section will be added later but will have the format below ] 
>
>                     Alcatel Cisco Laurel  NextHop  
>        Alcatel                                 
>        Cisco                                   
>        Laurel                                                   
>        NextHop                                        

the above table needs to be filled out.

> 1.5 BGP Implementation Identification

This section does not specify the origin of code

>    1.5.0 Alcatel 
>     
>    1.5.1 Cisco 
>    Implementation Name/Version: Cisco BGP Implementation, 12.0(27)S 
>    Date: 11/26/2003 
>     
>    1.5.2 Laurel 
>     
>    1.5.3 NextHop Technologies 
>    Implementation Name/Version: Gated NGC 2.0, 2.2 
>    Date: January 2004  
>  
>  
> Hares & Retana          Expires - August 2004                [Page 5] 
> 
> 
> 
> 
>                  draft-ietf-idr-bgp-implementation-00    February 2004 
>  
>  
>     
> 2. BGP4 Implementation Report 
>     
>    For every item listed, the respondents indicated whether their 
>    implementation supports the Functionality/Description or not (Y/N) 
>    according to the RFC2119 [3] language indicated.

"according to the RFC 2119" should probably be removed. The implementation
either decides to support something the 2119 language prescribes in some form or
it doesn't.

> Any respondent 
>    comments are included.  If appropriate, the respondents indicated 
>    with O the fact that the support is neither Y/N (an alternate 
>    behavior, for example). Refer to the appropriate sections in the 
>    latest BGP-4 ID [4] for additional details. 

From: Alex Zinin <[email-masked]>
Reply-To: Alex Zinin <[email-masked]>
To: [email-masked]
Subject: [Idr] AD-review comments on draft-ietf-idr-bgp-analysis-04.txt
Sender: [email-masked]
Date: Wed, 14 Apr 2004 19:23:19 -0700

Folks-

I have some technical comments regarding periods of stability and instability in
the Internet, BGP steady state, and the security considerations, plus several
editorial remarks.

See inline below, please.

> 2.1.  Key Features
...
>    One of the most important path attributes is the Autonomous System
>    Path, or AS_PATH.  AS reachability information traverses the
                        ^^
                        "As"

>    Internet, this information is augmented by the list of autonomous
>    systems that have been traversed thus far, forming the AS_PATH.  The
>    AS_PATH allows straightforward suppression of the looping of routing
>    information.  In addition, the AS_PATH serves as a powerful and
>    versatile mechanism for policy-based routing.
> 
>    BGP enhances the AS_PATH attribute to include sets of autonomous
>    systems as well as lists via the AS_SET attribute.  This extended
>    format allows generated aggregate routes to carry path information
>    from the more specific routes used to generate the aggregate.  It
>    should be noted however, that as of this writing, AS_SETs are rarely
>    used in the Internet [ROUTEVIEWS].
> 
> 
> 
> 2.2.  BGP Algorithms
> 
> 
>    BGP uses an algorithm that is neither a pure distance vector
>    algorithm or a pure link state algorithm.  It is instead a modified
>    distance vector algorithm referred to as a "Path Vector" algorithm
>    that uses path information to avoid traditional distance vector
>    problems.  Each route within BGP pairs destination with path
>    information to that destination.  Path information (also known as
>    AS_PATH information) is stored within the AS_PATH attribute in BGP.
>    This allows BGP to reconstruct large portions of overall topology
>    whenever required.

I've always been uncomfortable with documents saying that BGP reconstructs the
overall topology. It doesn't really do this like the link-state protocols do,
for example.

>    BGP uses an incremental update strategy in order to conserve
>    bandwidth and processing power.  That is, after initial exchange of
>    complete routing information, a pair of BGP routers exchanges only
>    changes to that information.  Such an incremental update design
>    requires reliable transport between a pair of BGP routers to function
>    correctly.  BGP solves this problem by using TCP for reliable
>    transport.

Should also note that use of TCP as the transport mechanism helps control
congestion and CPU utilization.

> 
>    In addition to incremental updates, BGP has added the concept of
>    route aggregation so that information about groups of networks may be
> 
> 
> 
> Meyer and Patel                                   Section 2.2.  [Page 5]
> 
> INTERNET-DRAFT             Expires: March 2004            September 2003
> 
> 
>    aggregated and sent as a single Network Layer Reachability (NLRI).

this doesn't read well. Neither "reachability" nor "information" are countable.
"Single prefix" instead?

>    Finally, note that BGP is a self-contained protocol.  That is, BGP
>    specifies how routing information is exchanged both between BGP
>    speakers in different autonomous systems, and between BGP speakers
>    within a single autonomous system.
> 
> 
> 
> 2.3.  BGP Finite State Machine (FSM)
> 
> 
>    The BGP FSM is a set of rules that are applied to a BGP speaker's set
>    of configured peers for the BGP operation.  A BGP implementation
>    requires that a BGP speaker must connect to and listen on TCP port
>    179 for accepting any new BGP connections from its peers.  The BGP
>    Finite State Machine, or FSM, must be initiated and maintained for
>    each new incoming and outgoing peer connections.  However, in steady
>    state operation, there will be only one BGP FSM per connection per
>    peer.
> 
>    There may exist a temporary period where in a BGP peer may have
>    separate incoming and outgoing connections resulting into two
>    different BGP FSMs for a peer (instead of one).  This can be resolved
>    following BGP connection collision rules defined in the [BGP4].
> 
>    Following are different states of BGP FSM for its peers:
> 
>    IDLE:           State when BGP peer refuses any incoming
>                    connections.
> 
>    CONNECT:        State in which BGP peer is waiting for
>                    its TCP connection to be completed.
> 
>    ACTIVE:         State in which BGP peer is trying to acquire a
>                    peer by listening and accepting TCP connection.
> 
>    OPENSENT:       BGP peer is waiting for OPEN message from its
>                    peer.
> 
>    OPENCONFIRM:    BGP peer is waiting for KEEPALIVE or NOTIFICATION
>                    message from its peer.
> 
>    ESTABLISHED:    BGP peer connection is established and exchanges
>                    UPDATE, NOTIFICATION, and KEEPALIVE messages with
>                    its peer.
> 
>    There are different BGP events that operate on above mentioned states
> 
> 
> 
> Meyer and Patel                                   Section 2.3.  [Page 6]
> 
> INTERNET-DRAFT             Expires: March 2004            September 2003
> 
> 
>    of BGP FSM for its peers.  These BGP events are used for initiating and
>    terminating peer connections.  They also assist BGP in identifying any
>    persistent peer connection oscillations and provide a mechanism
>    for controlling them.
> 
>    Following are different BGP events:
> 
>    Manual Start:           Manually start the peer connection.
> 
>    Manual Stop:            Manually stop the peer connection.
> 
>    Automatic Start:        Local system automatically starts the peer
>                            connection.
> 
>    Manual start with
>    passive TCP flag:       Local system administrator manually starts the
>                            peer connection with peer in passive mode.
> 
>    Automatic start
>    with passive TCP flag:  Local system administrator automatically starts
>                            the peer connection with peer in passive mode.
> 
>    Automatic start
>    with bgp_stop_flap
>    option set:             Local system administrator automatically starts
>                            the peer connection with peer oscillation
>                            damping enabled.
> 
>    Automatic start with
>    bgp_stop_flap option
>    set and passive TCP
>    establishment
>    option set:             Local system administrator automatically starts
>                            the peer connection with peer oscillation
>                            damping enabled and with peer in passive mode.
> 
>    Automatic stop:         Local system automatically stops the
>                            BGP connection.
> 
>    Both, Manual Start and Manual Stop are mandatory BGP events.  All
>    other events are optional.
> 

Ummmm... the above are "administrative" events only. There are other events in
the FSM, and most of other events are mandatory.

> 
> 
> 
> 
> 
> 
> 
> 
> Meyer and Patel                                   Section 2.3.  [Page 7]
> 
> INTERNET-DRAFT             Expires: March 2004            September 2003
> 
> 
> 3.  BGP Capabilities
> 
> 
>    The BGP Capability mechanism [RFC2842] provides an easy and flexible
>    way to introduce new features within the protocol.  In particular,
>    the BGP capability mechanism allows peers to negotiate various
>    optional features during startup.  This allows the base BGP protocol
>    to contain only essential functionality, while at the same time
>    providing a flexible mechanism for signaling protocol extensions.
> 
> 
> 
> 4.  BGP Persistent Peer Oscillations
> 
> 
>    Ideally, whenever a BGP speaker detects an error in any peer
>    connection, it shuts down the peer and changes its FSM state to IDLE.
>    BGP speaker requires a Start event to re-initiate its idle peer
>    connection.  If the error remains persistent and BGP speaker
>    generates Start event automatically then it may result in persistent
>    peer flapping.  However, although peer oscillation is found to be
>    wide-spread in BGP implementations, methods for preventing persistent
>    peer oscillations are outside the scope of base BGP protocol
>    specification.
> 
> 
> 
> 5.  Implementation Guidelines
> 
> 
>    A robust BGP implementation is work conserving.  This means that if
>    the number of prefixes is bound, arbitrarily high levels of route
>    change can be tolerated with bounded impact on route convergence for
>    occasionally changes in generally stable routes.

"occasional"?

> 
>    A BGP implementation under high load conditions should empty as much
>    inbound routing updates from its input streams, processing only the
>    most recent route if the route for a given NLRI changes multiple
>    times.  TCP also provides blocking on the writes on the sender side.
>    A BGP implementation under load should expect blocks on write calls
>    and send only the most recent routes when sockets unblock rather than
>    sending entire history.
> 
>    A robust implementation of BGP should have the following
>    characteristics:
>          1.  It is able to operate in almost arbitrarily high levels
>              of route flap without loosing peerings (failing to send
>              keepalives) or loosing other protocol adjacencies as a
> 
> 
> 
> Meyer and Patel                                     Section 5.  [Page 8]
> 
> INTERNET-DRAFT             Expires: March 2004            September 2003
> 
> 
>              result of BGP load.
> 
>          2.  Instability of a subset of routes should not affect the
>              route advertisements or forwarding associated with the set
>              of stable routes.
> 
>          3.  High levels of instability and peers of different CPU speed
>              or load resulting in faster or slower processing of routes
>              should not cause instability and should have a bounded
>              impact on the convergence time for generally stable routes.
> 
>    Numerous robust BGP implementations exist.  Producing a robust
>    implementation is not a trivial matter but clearly achievable.
> 
> 
> 
> 
> 6.  BGP Performance characteristics and Scalability
> 
> 
>    In this section, we provide "order of magnitude" answers to the
>    questions of how much link bandwidth, router memory and router CPU
>    cycles the BGP protocol will consume under normal conditions.  In
>    particular, we will address the scalability of BGP and its
>    limitations.
> 
> 
> 
> 6.1.  Link bandwidth and CPU utilization
> 
> 
>    Immediately after the initial BGP connection setup, BGP peers
>    exchange complete set of routing information.  If we denote the total
>    number of routes in the Internet by N, the mean AS distance of the
>    Internet by M (distance at the level of an autonomous system,
>    expressed in terms of the number of autonomous systems), the total
>    number of unique AS paths by A, and assume that the networks are
>    uniformly distributed among the autonomous systems, then the worst
>    case amount of bandwidth consumed during the initial exchange between
>    a pair of BGP speakers is
> 
>            BW = O(N + (M * A))
> 
>    The following table illustrates the typical amount of bandwidth
>    consumed during the initial exchange between a pair of BGP speakers
>    based on the above assumptions (ignoring bandwidth consumed by the
>    BGP Header).  For purposes of the estimates here, we will calculate
>    BW = 4 * (N + (M * A)).
> 
> 
> 
> Meyer and Patel                                   Section 6.1.  [Page 9]
> 
> INTERNET-DRAFT             Expires: March 2004            September 2003
> 
> 
>     # NLRI       Mean AS Distance       # AS's     Bandwidth (MR)
>     ----------   ----------------       ------    ----------------
>     40,000       15                     400        184,000   bytes
>     100,000      10                     10,000     800,000   bytes
>     120,000      10                     15,000     1,080,000 bytes
>     140,000      15                     20,000     1,760,000 bytes
> 
>     [note that most of this bandwidth is consumed by the NLRI exchange]

Is the caption for column 3 correct? It says "# AS's", which reads as "number of
AS's" while it seems it should be the number of unique paths.
> 
>    BGP was created specifically to reduce the size of the set of NLRI
>    entries which have to be carried and exchanged by border routers.
>    The aggregation scheme, defined in RFC 1519 [RFC1519], describes the
>    provider-based aggregation scheme in use in today's Internet.
> 
>    Due to the advantages of advertising a few large aggregate blocks
>    instead of many smaller class-based individual networks, it is
>    difficult to estimate the actual reduction in bandwidth and
>    processing that BGP has provided over BGP-3.  If we simply enumerate
>    all aggregate blocks into their individual class-based networks, we
>    would not take into account "dead" space that has been reserved for
>    future expansion.  The best metric for determining the success of
>    BGP's aggregation is to sample the number NLRI entries in the
>    globally connected Internet today and compare it to projected growth
>    rates before BGP was deployed.
> 
>    At the time of this writing, the full set of exterior routes carried
>    by BGP is approximately 120,000 network entries [ROUTEVIEWS].
> 
> 
> 
> 6.1.1.  CPU utilization
> 
> 
>    An important and fundamental feature of BGP is that BGP's CPU
>    utilization depends only on the stability of the Internet.  If the
>    Internet is stable, then the only link bandwidth and router CPU
>    cycles consumed by BGP are due to the exchange of the BGP KEEPALIVE
>    messages.  The KEEPALIVE messages are exchanged only between peers.
>    The suggested frequency of the exchange is 30 seconds.  The KEEPALIVE
>    messages are quite short (19 octets), and require virtually no
>    processing.  As a result, the bandwidth consumed by the KEEPALIVE
>    messages is about 5 bits/sec.  Operational experience confirms that
>    the overhead (in terms of bandwidth and CPU) associated with the
>    KEEPALIVE messages should be viewed as negligible.
> 
>    During periods of Internet instability, changes to the reachability
>    information are passed between routers in UPDATE messages.  The

While theoretically the text is correct and we could talk about periods of
stability and instability of the Internet, I wonder if this text is still
applicable from the practical perspective. I.e., the continuous churn that the
Internet BGP speakers experience ensures that they practically always have
something to process.

Probably instead of talking about periods of "Internet stability" and "Internet
instability" we could talk about something like "periods of stable state among
BGP speakers when they do no have new updates to communicate to each other".

>
> Meyer and Patel                                Section 6.1.1.  [Page 10]
> 
> INTERNET-DRAFT             Expires: March 2004            September 2003
> 
> 
>    greatest overhead per UPDATE message occurs when each UPDATE message
>    contains only a single network.  It should be pointed out that in
>    practice routing changes exhibit strong locality with respect to the
>    AS path.  That is, routes that change are likely to have common AS
>    path.  In this case, multiple networks can be grouped into a single
>    UPDATE message, thus significantly reducing the amount of bandwidth
>    required (see also Appendix F.1 of [BGP4]).
> 
>    Since in the steady state the link bandwidth and router CPU cycles
>    consumed by the BGP protocol are dependent only on the stability of
>    the Internet, it follows that BGP should have no scaling problems in
>    the areas of link bandwidth and router CPU utilization.

Not sure I follow here. What is meant by the "steady state" here? If it means
convergence on a stable topology after the initial exchange of updates, then why
talk about "stability of the Internet"? In other words, if the Internet is
unstable then can we say that the BGP speakers are in steady state? In the lack
of topology changes, it seems that the consumption should instead depend on the
number of peers (affects KEEPALIVE processing) and the number of persistently
oscillating routes potentially present in the network...

> This assumes
>    that as the Internet grows,  the overall stability of the inter-AS
>    connectivity of the Internet can be controlled.

please specify how it is assumed to be "controlled", e.g. through operational
practices.

> In particular, while
>    the size of the IPv4 Internet routing table is bounded by O(232 * M),

232 or 2^32?

>    (where M is a slow-moving function describing the AS
>    interconnectivity of the network),

slow-moving or slow-growing?

> no such bound can be formulated
>    for the dynamic properties (i.e., stability) of BGP.  Although, the
>    dynamic properties of the network cannot be quantitatively bounded,
>    they can be controlled within BGP.  Beyond certain changes in the
>    network, BGP can start to suppress such changes using BGP Route Flap
>    Damping [RFC2439], pacing of its route updates, or BGP would be
>    unable to keep up with the changes and force suppression of multiple
>    changes over very short periods by causing the BGP peer socket to
>    block on the sender.
> 
> 
> 
> 6.1.2.  Memory requirements
> 
> 
>    To quantify the worst case memory requirements for BGP, we denote the
>    total number of networks in the Internet by N, the mean AS distance
>    of the Internet by M (distance at the level of an autonomous system,
>    expressed in terms of the number of autonomous systems), the total
>    number of unique AS paths as A.  Then the worst case memory
>    requirements (MR) can be expressed as
> 
> 
>            MR = O(N + (M * A))
> 
> 
>    Since a mean AS distance M is a slow moving function of the
>    interconnectivity ("meshiness") of the Internet, for all practical
>    purposes the worst case router memory requirements are on the order
>    of the total number of networks in the Internet times the number of
>    peers the local system is peering with.  We expect that the total
>    number of networks in the Internet will grow much faster than the
> 
> 
> 
> Meyer and Patel                                Section 6.1.2.  [Page 11]
> 
> INTERNET-DRAFT             Expires: March 2004            September 2003
> 
> 
>    average number of peers per router.  As a result, BGP's memory
>    scaling properties are linearly related to the total number of
>    networks in the Internet.
> 
>    The following table illustrates typical memory requirements of a
>    router running BGP.  We denote average number of routes advertised by
>    each peer as N, the total number of unique AS paths as A, the mean AS
>    distance of the Internet as M (distance at the level of an autonomous
>    system, expressed in terms of the number of autonomous systems),
>    number of bytes required to store a route as R, and number of bytes
>    required to store one AS in an AS path as P.  It is assumed that each
>    network is encoded as four bytes, each AS is encoded as two bytes,
>    and each networks is reachable via some fraction of all of the peers
>    (# BGP peers/per net).  For purposes of the estimates here, we will
>    calculate MR = ((N * R) + (M * A) * P)
> 
> 
>      # Networks  Mean AS Distance # AS's # BGP peers/per net Memory Req (MR)
>      ----------  ---------------- ------ ------------------- --------------
>       100,000           20         3,000         20             1,040,000
>       100,000           20        15,000         20             1,040,000
>       120,000           10        15,000        100            75,000,000
>       140,000           15        20,000        100           116,000,000
> 
> 
>    In analyzing BGP's memory requirements, we focus on the size of the
>    forwarding table (and ignoring implementation details).  In
>    particular, we derive upper bounds for the size of the forwarding
>    table.

The above doesn't look like calculations for a forwarding table--the FIB doesn't
normally contact AS-PATH info or all possible paths to a destination.

>
> 11.  Security Considerations
> 
> 
>    This document presents an analysis of the BGP protocol and as such
>    presents no new security implications for BGP.

I'm afraid the IESG will expect to see some more here. Specifically, I would
suggest that the document talks about available security mechanisms, and the
analysis of how they affect processing overhead, BW, and scalability.
Certainly a pointer to the bgp-vuln document would be useful.

Alex

To: [email-masked]
Cc: [email-masked], [email-masked], [email-masked]
From: Enke Chen <[email-masked]>
Subject: [Idr] Implementation survey for BGP Route Reflection
Sender: [email-masked]
Date: Wed, 14 Apr 2004 15:12:11 -0700

Hi, folks:

We need an implementation report to advance the BGP Route Reflection
draft (draft-ietf-idr-rfc2796bis-00.txt).  For folks who have done
the implementation, could you fill out the simple survey (attached),
and send to me by April 28, 2004?

Thanks.  -- Enke

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

           Implementation Report for BGP Route Reflection
               (draft-ietf-idr-rfc2796bis-00.txt)

  Organization:

  Person filling out this form:

  Does your implementation follow the procedures specified in the Operation
  Section when advertising an IBGP learned route to an IBGP peer?

  Does your implementation recognize the two new attributes (ORIGINATOR_ID
  and CLUSTER_LIST) defined in the document?

  Does your implementation perform routing information loop detection based
  on the ORIGINATOR_ID and the CLUSTER_LIST attributes as specified in the
  document?

  Does your implementation format the two new attributes (ORIGINATOR_ID and
  CLUSTER_LIST) as specified in the document when doing route reflection?

  Does your implementation take the ORIGNATOR_ID and the CLUSTER_LIST
  attributes into account in route selection as specified in the document?

  List other implementations that you have tested for BGP Route Reflection
  interoperability.

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

To: [email-masked]
Cc: [email-masked]
From: Enke Chen <[email-masked]>
Subject: [Idr] I-D ACTION:draft-chen-bgp-cease-subcode-survey-00.txt
Sender: [email-masked]
Date: Wed, 14 Apr 2004 15:06:16 -0700

FYI.  -- Enke

To: [email-masked]
From: [email-masked]
Subject: I-D ACTION:draft-chen-bgp-cease-subcode-survey-00.txt
Date: Wed, 14 Apr 2004 15:32:43 -0400

- --NextPart

	Title		: BGP Cease Subcode - Implementation Report
	Author(s)	: E. Chen
	Filename	: draft-chen-bgp-cease-subcode-survey-00.txt
	Pages		: 4
	Date		: 2004-4-14
	
This document provides an implementation report for the BGP Cease
   Subcodes.

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

To: Steve Bellovin <[email-masked]>
cc: [email-masked], Stephen Kent <[email-masked]>, Alex Zinin <[email-masked]>
Subject: Re: [Idr] Fwd: Re: [saag] draft-iesg-tcpmd5app-00.txt 
From: Yakov Rekhter <[email-masked]>
Sender: [email-masked]
Date: Wed, 14 Apr 2004 14:03:50 -0700

Steve,

> This is a forwarded message
> From: Steven M. Bellovin <[email-masked]>
> To: Stephen Kent <[email-masked]>
> Cc: Alex Zinin <[email-masked]>, [email-masked]
> Date: Wednesday, April 7, 2004, 8:13:10 AM
> Subject: [saag] draft-iesg-tcpmd5app-00.txt
> 
> ===8<==============Original message text===============
> In message <p06020401bc99b101fea7@[128.89.89.75]>, Stephen Kent writes:
> 
> >If you look at Steve's document, he uses the right terminology 
> >throughout, while referring to the document via its RFC number. 
> >That's a good model for any document that wants to avoid perpetuating 
> >the terminology error inherent in the title of 2385.
> >
> 
> It's probably worth putting a note in my document noting the erroneous 
> terminology in the title of 2385. It's not a bad idea having a similar 
> parenthetical note in the bgp document.

Could you send me the note, so that I'll include it in the bgp doc.

Thanks in advance.

Yakov.

To: Stephen Kent <[email-masked]>
cc: Alex Zinin <[email-masked]>, Steve Bellovin <[email-masked]>, [email-masked], [email-masked]
Subject: Re: [Idr] Re: [saag] draft-iesg-tcpmd5app-00.txt 
From: Yakov Rekhter <[email-masked]>
Sender: [email-masked]
Date: Wed, 14 Apr 2004 13:38:17 -0700

Steve,

> >	<SNIP>
> >
> >
> >Steve, would you mind making a suggestion on how the text could be improved?
> >E.g., would a separate section in the main body of the document specifying
> >the requirement for TCP-MD5 support be useful?
> 
> A reasonable approach would be to have a section of the document that 
> describes the use of this TCP option. It should explain why/when one 
> would use the option in the context of BGP links and what protection 
> it offers. 

Would you please produce the appropriate text for this section.

Thanks in advance.

Yakov.

To: [email-masked]
From: Yakov Rekhter <[email-masked]>
Subject: [Idr] WG Last Call on draft-ietf-idr-rfc2796bis-00.txt
Sender: [email-masked]
Date: Wed, 14 Apr 2004 13:36:09 -0700

Folks,

Yakov.

- --NextPart

	

Send a message to:
	[email-masked].
In the body type:

- --NextPart

- --OtherAccess

Content-Type: text/plain

ENCODING mime

- --OtherAccess

Content-Type: text/plain

- --OtherAccess--

- --NextPart--

To: Alex Zinin <[email-masked]>
cc: Stephen Kent <[email-masked]>, Steve Bellovin <[email-masked]>, [email-masked], [email-masked]
Subject: Re: [Idr] Re: [saag] draft-iesg-tcpmd5app-00.txt 
From: Yakov Rekhter <[email-masked]>
Sender: [email-masked]
Date: Wed, 14 Apr 2004 13:20:03 -0700

Alex,

> Thanks for looking at this. My comments inline below.
> 
> I've added the IDR mailing list, since your comments cover the base spec as
> well.
> 
> Wednesday, March 31, 2004, 1:34:47 PM, Stephen Kent wrote:
> > Steve,
> 
> > The text explaining why the MD5 checksum is not a good candidate for 
> > use in broader IETF protocol contexts is very well written.
> 
> > The discussion of why BGP-4 can't easily change at this time to 
> > another integrity mechanism is also very good. However, when I looked 
> > quickly at the new BGP draft (intended to replace the extant RFC) I 
> > was unable to find any discussion of using the MD5 option. There are 
> > references to RFC 2385 in the discussion of what has changed, and in 
> > the security considerations section, and the normative references 
> > section. But a search on "MD5," "RFC 2385," "authentication," 
> > "integrity," or "security" does not point a reader to any text that
> > says in any detail how to use this TCP option in the BGP context.
> 
> As you said, the spec refers to the RFC 2385. RFC 2385 titled "Protection of 
BGP
> Sessions via the TCP MD5 Signature Option", in turn, describes how the option
> can be used to secure a TCP sessions, for BGP in particular. Is there somethi
ng
> specific you were looking for?
> 
> > The
> > section entitled "TCP Options that may be used with BGP" makes no 
> > reference to it. Can someone point me to where the new BGP document 
> > actually says how this TCP option is used?
> 
> Appendix E "TCP options that may be used with BGP" could indeed mention that 
> the MD5 option can be used for BGP sessions. Yakov, please log this.

Sure.

Yakov.

To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: [Idr] I-D ACTION:draft-ietf-idr-rfc2796bis-00.txt
Sender: [email-masked]
Date: Wed, 14 Apr 2004 15:33: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		: BGP Route Reflection - An Alternative to Full Mesh IBGP
	Author(s)	: T. Bates, et al.
	Filename	: draft-ietf-idr-rfc2796bis-00.txt
	Pages		: 11
	Date		: 2004-4-14

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Send a message to:
	[email-masked].
In the body type:

--NextPart

--OtherAccess

Content-Type: text/plain

ENCODING mime

--OtherAccess

Content-Type: text/plain

--OtherAccess--

--NextPart--

To: [email-masked]
cc: [email-masked]
From: Yakov Rekhter <[email-masked]>
Subject: [Idr] draft-lange-flexible-bgp-communities-02.txt as an IDR WG document
Sender: [email-masked]
Date: Wed, 14 Apr 2004 08:09:52 -0700

Folks,

We receive a request to accept draft-lange-flexible-bgp-communities-02.txt
as an IDR WG document. Please send comments to the list. The deadline
for comments is April 28, 2004. 

Yakov.

To: Alex Zinin <[email-masked]>
From: Stephen Kent <[email-masked]>
Cc: Steve Bellovin <[email-masked]>, [email-masked], [email-masked]
Subject: [Idr] Re: [saag] draft-iesg-tcpmd5app-00.txt
Sender: [email-masked]
Date: Fri, 9 Apr 2004 11:40:58 -0400

Alex,

>	<SNIP>
>
>
>Steve, would you mind making a suggestion on how the text could be improved?
>E.g., would a separate section in the main body of the document specifying
>the requirement for TCP-MD5 support be useful?

A reasonable approach would be to have a section of the document that 
describes the use of this TCP option. It should explain why/when one 
would use the option in the context of BGP links and what protection 
it offers. Somewhere there should be a discussion of precautions 
should be taken re selection and use of keys, but maybe this is more 
of a BCP matter than a protocol standards matter.

>	<SNIP>
>
>I didn't mean to argue whether the terminology is right or wrong, 
>I'll leave up
>to you guys. My point was that we have to use the actual title of the document
>when referring to it, even though the title may not accurately describe what's
>inside. Anyway, Steve suggested that a clarifying note is put in the docs...

actually, one often refers to an RFC by number in the text, and 
includes the title only in the references section.

>	<SNIP>
>  > But, in a more fundamental sense, we have already
>>  endorsed the inappropriate use of MD5 in routing protocols in terms
>>  of OSPF, and we're merely continuing the tradition with BGP and LDP
>>  :-).
>
>It seems a discussion on why MD5 is inappropriate or insufficient in
>routing protocols would be interesting if we take it to RPSEC.
>

of course the issue is not MD5 per se, but the use of MD5 plus a 
secret bit string as a message authentication code, instead of HMAC, 
in any context.

Steve

From: Alex Zinin <[email-masked]>
Reply-To: Alex Zinin <[email-masked]>
To: Stephen Kent <[email-masked]>
CC: Steve Bellovin <[email-masked]>, [email-masked], [email-masked]
Subject: [Idr] Re: [saag] draft-iesg-tcpmd5app-00.txt
Sender: [email-masked]
Date: Thu, 8 Apr 2004 17:15:56 -0700

Steve-

 [putting IDR back on the Cc: list--I'd like the WG to be in the loop]

Wednesday, April 7, 2004, 8:09:53 AM, Stephen Kent wrote:
> At 4:26 PM -0700 4/6/04, Alex Zinin wrote:
>>Steve-
>>
>>>  the BGP document cites mandatory use of RFC 2385 as one of the
>>>  changes, up front, but then never makes any reference to the RFC in
>>>  the text. That's not a good way to communicate the intent of the
>>>  change, i.e., the intent of the change has not been integrated into
>>>  the body of the spec.
>>
>>It seems that you simply have missed the following reference in the "Security
>>Considerations" section:
>>
>>  draft-ietf-idr-bgp4-23.txt:
>>
>>     The authentication mechanism that an implementation of BGP MUST sup-
>>     port is specified in [RFC2385]. The authentication provided by this
>>     mechanism could be done on a per peer basis.
>>
>>     BGP vulnerabilities analysis is discussed in [BGP_VULN].

> No, I didn't miss it, Alex. I consider it a trivial reference that 
> fails to do an adequate job. The Security Considerations section of a 
> document is not where one first specifies a requirement for a 
> protocol. It is a place to comment upon what has already been 
> specified, putting it in context relative to security.

Steve, would you mind making a suggestion on how the text could be improved?
E.g., would a separate section in the main body of the document specifying
the requirement for TCP-MD5 support be useful?

>>  > in the context of Steve Bellovin's document there is no reason to
>>>  perpetuate the error of the RFC 2385 title, i.e., to continue to
>>>  refer to the message authentication code created by the use of a
>>>  shared secret and a hash function as a "signature."  One might even
>>>  take this opportunity to point out that the title of the RFC is
>>>  misleading and should not be confused with digital signature
>>>  technologies.
>>
>>My understanding is that Steve used the wording from the 2385's title on
>>purpose, since we're talking about a specific document with a specific title,
>>plus about a TCP option with a specific name (though now considered 
>>misleading).

> Alex, the terminology was always wrong, and I pointed that out to the 
> IESG when the RFC was out for last call years ago. But Jeff Schiller 
> apparently didn't think the terminology error was worth fixing, and I 
> doubt that the rest of the IESG was concerned back then. Don't phrase 
> this as though we're in the realm of revisionist political 
> correctness. It was wrong then, and it's still wrong.

I didn't mean to argue whether the terminology is right or wrong, I'll leave up
to you guys. My point was that we have to use the actual title of the document
when referring to it, even though the title may not accurately describe what's
inside. Anyway, Steve suggested that a clarifying note is put in the docs...

>>	<SNIP>
>>
>>>  For contrast, RFC xxxx specifies use of MD5 in the same
>>>  fashion for OSPF security, but nobody is suggesting that this be
>>>  approved, presumably because there is no large, installed base, right?
>>
>>RFC 2328 includes the OSPF MD5 authentication option (similar to 
>>TCP-MD5 in its
>>transport nature). It's widely deployed and is a full IETF Standard. 
>>If you mean
>>"OSPF with Digital Signatures" (RFC2154), then it is EXP, and I have heard of
>>only one or two implementations.

> Sorry, I meant to fill in the xxxx before sending but forgot to. Yes, 
> I was referring to 2238. We have a slightly odd situation here. 
> Steve's document explains why BGP is being progressed even though it 
> contains a normative reference to an RFC (TCP MD5 ...) that will not 
> be progressed. The argument is that the latter RFC is technically 
> poor, but it's not so awful to use it with BGP considering the 
> context, because it is widely deployed, and because it is the only 
> point-to-point authentication mechanism defined for BGP.  Then there 
> is the minor mention of LDP at te end.

> You suggest, above, that OSPF's use of MD5 is also widely deployed, 
> something of which I was not aware. (Or did you just mean that many 
> OSPF implementations support the feature, but you don't know if it is 
> tuend on?)

All more-or-less mature OSPF implementations I know of certainly support the
feature. As for deployment, OSPF MD5 _is_ being used in both SP and enterprise
networks. I do not have numbers for you, but even as of 3-4 years ago (when I
worked close with operators on a regular basis), it was not uncommon to see it
configured.

> OSPF does not use the TCP MD5 option, but rather uses MD5 
> in the same marginal way internally. So, in one sense there is no 
> need to mention this in Steve's document, because it is just 
> explaining why the IESG is making an exception for BGP, and LDP in 
> the future.

Agreed.

> But, in a more fundamental sense, we have already 
> endorsed the inappropriate use of MD5 in routing protocols in terms 
> of OSPF, and we're merely continuing the tradition with BGP and LDP 
> :-).

It seems a discussion on why MD5 is inappropriate or insufficient in
routing protocols would be interesting if we take it to RPSEC.

Thanks.

Alex

> 	<SNIP>

>>  > you are right that the primary focus of this discussion is
>>  > progression of BGP. But, since you argued that LDP is appropriately
>>  > included in the rationale discussion for this document, I assume you
>>  > will want to progress that RFC too,
>>  > otherwise why bother mentioning it now?  I would rather not have to
>>  > revisit this at that time, so I suggest you ask the MPLS WG to make a
>>  > note of this error now.
>>
>>Looking at the LDP spec, it uses the word "signature" as part of the reference
>>to the "TCP MD5 Signature Option", specified in 2385. While it could be argued
>>that 2385 uses incorrect terminology, it would be confusing to refer to it as
>>something like "TCP MD5 Message Digest Option" or "TCP MD5 Authentication
>>Option", as this is not what 2385 specifies.

> If you look at Steve's document, he uses the right terminology 
> throughout, while referring to the document via its RFC number. 
> That's a good model for any document that wants to avoid perpetuating 
> the terminology error inherent in the title of 2385.

> Steve

From: Alex Zinin <[email-masked]>
Reply-To: Alex Zinin <[email-masked]>
To: [email-masked]
CC: Stephen Kent <[email-masked]>, Steve Bellovin <[email-masked]>
Subject: [Idr] Fwd: Re: [saag] draft-iesg-tcpmd5app-00.txt
Sender: [email-masked]
Date: Thu, 8 Apr 2004 16:52:04 -0700

This is a forwarded message
From: Stephen Kent <[email-masked]>
To: Alex Zinin <[email-masked]>
Cc: Steve Bellovin <[email-masked]>, [email-masked]
Date: Wednesday, April 7, 2004, 8:09:53 AM
Subject: [saag] draft-iesg-tcpmd5app-00.txt

===8<==============Original message text===============
At 4:26 PM -0700 4/6/04, Alex Zinin wrote:
>Steve-
>
>>  the BGP document cites mandatory use of RFC 2385 as one of the
>>  changes, up front, but then never makes any reference to the RFC in
>>  the text. That's not a good way to communicate the intent of the
>>  change, i.e., the intent of the change has not been integrated into
>>  the body of the spec.
>
>It seems that you simply have missed the following reference in the "Security
>Considerations" section:
>
>  draft-ietf-idr-bgp4-23.txt:
>
>     The authentication mechanism that an implementation of BGP MUST sup-
>     port is specified in [RFC2385]. The authentication provided by this
>     mechanism could be done on a per peer basis.
>
>     BGP vulnerabilities analysis is discussed in [BGP_VULN].

No, I didn't miss it, Alex. I consider it a trivial reference that 
fails to do an adequate job. The Security Considerations section of a 
document is not where one first specifies a requirement for a 
protocol. It is a place to comment upon what has already been 
specified, putting it in context relative to security.

>  > in the context of Steve Bellovin's document there is no reason to
>>  perpetuate the error of the RFC 2385 title, i.e., to continue to
>>  refer to the message authentication code created by the use of a
>>  shared secret and a hash function as a "signature."  One might even
>>  take this opportunity to point out that the title of the RFC is
>>  misleading and should not be confused with digital signature
>>  technologies.
>
>My understanding is that Steve used the wording from the 2385's title on
>purpose, since we're talking about a specific document with a specific title,
>plus about a TCP option with a specific name (though now considered 
>misleading).

Alex, the terminology was always wrong, and I pointed that out to the 
IESG when the RFC was out for last call years ago. But Jeff Schiller 
apparently didn't think the terminology error was worth fixing, and I 
doubt that the rest of the IESG was concerned back then. Don't phrase 
this as though we're in the realm of revisionist political 
correctness. It was wrong then, and it's still wrong.

>	<SNIP>
>
>>  For contrast, RFC xxxx specifies use of MD5 in the same
>>  fashion for OSPF security, but nobody is suggesting that this be
>>  approved, presumably because there is no large, installed base, right?
>
>RFC 2328 includes the OSPF MD5 authentication option (similar to 
>TCP-MD5 in its
>transport nature). It's widely deployed and is a full IETF Standard. 
>If you mean
>"OSPF with Digital Signatures" (RFC2154), then it is EXP, and I have heard of
>only one or two implementations.

Sorry, I meant to fill in the xxxx before sending but forgot to. Yes, 
I was referring to 2238. We have a slightly odd situation here. 
Steve's document explains why BGP is being progressed even though it 
contains a normative reference to an RFC (TCP MD5 ...) that will not 
be progressed. The argument is that the latter RFC is technically 
poor, but it's not so awful to use it with BGP considering the 
context, because it is widely deployed, and because it is the only 
point-to-point authentication mechanism defined for BGP.  Then there 
is the minor mention of LDP at te end.

You suggest, above, that OSPF's use of MD5 is also widely deployed, 
something of which I was not aware. (Or did you just mean that many 
OSPF implementations support the feature, but you don't know if it is 
tuend on?) OSPF does not use the TCP MD5 option, but rather uses MD5 
in the same marginal way internally. So, in one sense there is no 
need to mention this in Steve's document, because it is just 
explaining why the IESG is making an exception for BGP, and LDP in 
the future. But, in a more fundamental sense, we have already 
endorsed the inappropriate use of MD5 in routing protocols in terms 
of OSPF, and we're merely continuing the tradition with BGP and LDP 
:-).

	<SNIP>

>  > you are right that the primary focus of this discussion is
>  > progression of BGP. But, since you argued that LDP is appropriately
>  > included in the rationale discussion for this document, I assume you
>  > will want to progress that RFC too,
>  > otherwise why bother mentioning it now?  I would rather not have to
>  > revisit this at that time, so I suggest you ask the MPLS WG to make a
>  > note of this error now.
>
>Looking at the LDP spec, it uses the word "signature" as part of the reference
>to the "TCP MD5 Signature Option", specified in 2385. While it could be argued
>that 2385 uses incorrect terminology, it would be confusing to refer to it as
>something like "TCP MD5 Message Digest Option" or "TCP MD5 Authentication
>Option", as this is not what 2385 specifies.

If you look at Steve's document, he uses the right terminology 
throughout, while referring to the document via its RFC number. 
That's a good model for any document that wants to avoid perpetuating 
the terminology error inherent in the title of 2385.

Steve

===8<===========End of original message text===========

From: Alex Zinin <[email-masked]>
Reply-To: Alex Zinin <[email-masked]>
To: [email-masked]
CC: Stephen Kent <[email-masked]>, Steve Bellovin <[email-masked]>
Subject: [Idr] Fwd: Re: [saag] draft-iesg-tcpmd5app-00.txt
Sender: [email-masked]
Date: Thu, 8 Apr 2004 16:52:18 -0700

This is a forwarded message
From: Steven M. Bellovin <[email-masked]>
To: Stephen Kent <[email-masked]>
Cc: Alex Zinin <[email-masked]>, [email-masked]
Date: Wednesday, April 7, 2004, 8:13:10 AM
Subject: [saag] draft-iesg-tcpmd5app-00.txt

===8<==============Original message text===============
In message <p06020401bc99b101fea7@[128.89.89.75]>, Stephen Kent writes:

>If you look at Steve's document, he uses the right terminology 
>throughout, while referring to the document via its RFC number. 
>That's a good model for any document that wants to avoid perpetuating 
>the terminology error inherent in the title of 2385.
>

It's probably worth putting a note in my document noting the erroneous 
terminology in the title of 2385.  It's not a bad idea having a similar 
parenthetical note in the bgp document.

		--Steve Bellovin, http://www.research.att.com/~smb

===8<===========End of original message text===========

To: IETF-Announce :;
From: The IESG <[email-masked]>
Reply-to: [email-masked]
Subject: [Idr] Last Call: 'BGP Extended Communities Attribute' to Proposed Standard
Sender: [email-masked]
Date: Tue, 06 Apr 2004 12:04:48 -0400

The IESG has received a request from the Inter-Domain Routing WG to 
consider the following document:

- 'BGP Extended Communities Attribute '
   <draft-ietf-idr-bgp-ext-communities-07.txt> as a Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action.  Please send any comments to the
[email-masked] or [email-masked] mailing lists by 2004-04-20.

The implementation report can be found in the accompanying document:

- 'BGP Extended Communities Attribute - Implementation Survey'
  <draft-rekhter-ext-communities-survey-02.txt>

The files can be obtained via
http://www.ietf.org/internet-drafts/draft-ietf-idr-bgp-ext-communities-
07.txt
http://www.ietf.org/internet-drafts/draft-rekhter-ext-communities-survey-
02.txt

To: Alex Zinin <[email-masked]>
From: Stephen Kent <[email-masked]>
Cc: Steve Bellovin <[email-masked]>, [email-masked], [email-masked], Stephen  Kent <[email-masked]>
Subject: [Idr] Re: [saag] draft-iesg-tcpmd5app-00.txt
Sender: [email-masked]
Date: Mon, 5 Apr 2004 09:49:49 -0400

--============_-1130942848==_ma============
Content-Type: text/plain; charset="us-ascii" ; format="flowed"

At 7:03 PM -0800 4/2/04, Alex Zinin wrote:
>Steve-
>
>Thanks for looking at this. My comments inline below.
>
>I've added the IDR mailing list, since your comments cover the base spec as
>well.
>
>Wednesday, March 31, 2004, 1:34:47 PM, Stephen Kent wrote:
>>  Steve,
>
>>  The text explaining why the MD5 checksum is not a good candidate for
>>  use in broader IETF protocol contexts is very well written.
>
>>  The discussion of why BGP-4 can't easily change at this time to
>>  another integrity mechanism is also very good. However, when I looked
>>  quickly at the new BGP draft (intended to replace the extant RFC) I
>>  was unable to find any discussion of using the MD5 option. There are
>>  references to RFC 2385 in the discussion of what has changed, and in
>>  the security considerations section, and the normative references
>>  section. But a search on "MD5," "RFC 2385," "authentication,"
>>  "integrity," or "security" does not point a reader to any text that
>>  says in any detail how to use this TCP option in the BGP context.
>
>As you said, the spec refers to the RFC 2385. RFC 2385 titled 
>"Protection of BGP
>Sessions via the TCP MD5 Signature Option", in turn, describes how the option
>can be used to secure a TCP sessions, for BGP in particular. Is 
>there something
>specific you were looking for?

the BGP document cites mandatory use of RFC 2385 as one of the 
changes, up front, but then never makes any reference to the RFC in 
the text. That's not a good way to communicate the intent of the 
change, i.e., the intent of the change has not been integrated into 
the body of the spec.

in the context of Steve Bellovin's document there is no reason to 
perpetuate the error of the RFC 2385 title, i.e., to continue to 
refer to the message authentication code created by the use of a 
shared secret and a hash function as a "signature."  One might even 
take this opportunity to point out that the title of the RFC is 
misleading and should not be confused with digital signature 
technologies.

>  > The
>>  section entitled "TCP Options that may be used with BGP" makes no
>>  reference to it. Can someone point me to where the new BGP document
>>  actually says how this TCP option is used?
>
>Appendix E "TCP options that may be used with BGP" could indeed 
>mention that the
>MD5 option can be used for BGP sessions. Yakov, please log this.
>
>>  Also, I note that the document abstract says:
>
>>  "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."
>
>>  The term "solely" seems inappropriate, since it ignores the role that
>>  local policy plays in route selection, right? I think I know what the
>>  authors meant to say, but the text does not seem to be correct in
>>  this regard.
>
>It seems that the abstract is correct, actually. Routers indeed _forward_
>packets using solely the destination address from the packet, as opposed to
>using say destination and source address, or even more granular forwarding
>decisions. Policies are taken into consideration when the RIB and FIB are
>constructed, which is not part of forwarding.

Good point.

>  > LDP is a much newer protocol and so there is less of a "large
>>  installed base that has been using this for years" sense.
>
>We do have quite considerable installed base for LDP and strictly speaking it
>has been there for a few years. So, though the statement may not 
>sound as strong
>when applied to LDP, it is correct.

then the text should say that LDP represents as big an installed base 
as BGP's use of MD5, if that is the case. If not, then find some 
accurate but similarly persuasive characterization that justifies 
this use. For contrast, RFC xxxx specifies use of MD5 in the same 
fashion for OSPF security, but nobody is suggesting that this be 
approved, presumably because there is no large, installed base, right?

>
>>   I am also
>>  disturbed that the LDP spec (RFC 3036) refers to this as a signature
>>  as well, and incorporates bad text from the old BGP RFC, e.g., "...
>>  acts like a signature for that segment .." further perpetuating the
>>  confusion between message authentication codes and digital
>>  signatures. Any chance we can get this fixed in both the BGP document
>>  before it progresses and in the next rev of 3036?
>
>The BGP spec (neither old nor new) does not include this 
>terminology, so I don't
>think we need to fix it from this perspective.
>
>Improvement of the LDP spec could be considered by the MPLS WG when it starts
>working on a new revision of the spec.
>
>Thank you.
>
>Alex

you are right that the primary focus of this discussion is 
progression of BGP. But, since you argued that LDP is appropriately 
included in the rationale discussion for this document, I assume you 
will want to progress that RFC too,
otherwise why bother mentioning it now?  I would rather not have to 
revisit this at that time, so I suggest you ask the MPLS WG to make a 
note of this error now.

Steve
--============_-1130942848==_ma============
Content-Type: text/html; charset="us-ascii"

<!doctype html public "-//W3C//DTD W3 HTML//EN">
<html><head><style type="text/css"><!--
blockquote, dl, ul, ol, li { padding-top: 0 ; padding-bottom: 0 }
 --></style><title>Re: [saag]
draft-iesg-tcpmd5app-00.txt</title></head><body>
<div>At 7:03 PM -0800 4/2/04, Alex Zinin wrote:</div>
<blockquote type="cite" cite>Steve-<br>
<br>
Thanks for looking at this. My comments inline below.<br>
<br>
I've added the IDR mailing list, since your comments cover the base
spec as<br>
well.<br>
<br>
Wednesday, March 31, 2004, 1:34:47 PM, Stephen Kent wrote:<br>
&gt; Steve,<br>
<br>
&gt; The text explaining why the MD5 checksum is not a good candidate
for<br>
&gt; use in broader IETF protocol contexts is very well written.<br>
<br>
&gt; The discussion of why BGP-4 can't easily change at this time
to<br>
&gt; another integrity mechanism is also very good. However, when I
looked<br>
&gt; quickly at the new BGP draft (intended to replace the extant RFC)
I<br>
&gt; was unable to find any discussion of using the MD5 option. There
are<br>
&gt; references to RFC 2385 in the discussion of what has changed, and
in<br>
&gt; the security considerations section, and the normative
references<br>
&gt; section. But a search on &quot;MD5,&quot; &quot;RFC 2385,&quot;
&quot;authentication,&quot;<br>
&gt; &quot;integrity,&quot; or &quot;security&quot; does not point a
reader to any text that<br>
&gt; says in any detail how to use this TCP option in the BGP
context.<br>
<br>
As you said, the spec refers to the RFC 2385. RFC 2385 titled
&quot;Protection of BGP<br>
Sessions via the TCP MD5 Signature Option&quot;, in turn, describes
how the option<br>
can be used to secure a TCP sessions, for BGP in particular. Is there
something</blockquote>
<blockquote type="cite" cite>specific you were looking
for?</blockquote>
<div><br></div>
<div>the BGP document cites mandatory use of RFC 2385 as one of the
changes, up front, but then never makes any reference to the RFC in
the text. That's not a good way to communicate the intent of the
change, i.e., the intent of the change has not been integrated into
the body of the spec.</div>
<div><br></div>
<div>in the context of Steve Bellovin's document there is no reason to
perpetuate the error of the RFC 2385 title, i.e., to continue to refer
to the message authentication code created by the use of a shared
secret and a hash function as a &quot;signature.&quot;&nbsp; One might
even take this opportunity to point out that the title of the RFC is
misleading and should not be confused with digital signature
technologies.</div>
<div><br></div>
<blockquote type="cite" cite>&gt; The<br>
&gt; section entitled &quot;TCP Options that may be used with BGP&quot;
makes no<br>
&gt; reference to it. Can someone point me to where the new BGP
document<br>
&gt; actually says how this TCP option is used?<br>
<br>
Appendix E &quot;TCP options that may be used with BGP&quot; could
indeed mention that the<br>
MD5 option can be used for BGP sessions. Yakov, please log this.<br>
<br>
&gt; Also, I note that the document abstract says:<br>
<br>
&gt; &quot;Routing information exchanged via BGP supports only the
destination-<br>
&gt;&nbsp;&nbsp;&nbsp;&nbsp; based forwarding paradigm, which assumes
that a router forwards a<br>
&gt;&nbsp;&nbsp;&nbsp;&nbsp; packet based solely on the destination
address carried in the IP<br>
&gt;&nbsp;&nbsp;&nbsp;&nbsp; header of the packet. This, in turn,
reflects the set of policy<br>
&gt;&nbsp;&nbsp;&nbsp;&nbsp; decisions that can (and can not) be
enforced using BGP. BGP can<br>
&gt;&nbsp;&nbsp;&nbsp;&nbsp; support only the policies conforming to
the destination-based<br>
&gt;&nbsp;&nbsp;&nbsp;&nbsp; forwarding paradigm.&quot;<br>
<br>
&gt; The term &quot;solely&quot; seems inappropriate, since it ignores
the role that<br>
&gt; local policy plays in route selection, right? I think I know what
the<br>
&gt; authors meant to say, but the text does not seem to be correct
in<br>
&gt; this regard.<br>
<br>
It seems that the abstract is correct, actually. Routers indeed
_forward_<br>
packets using solely the destination address from the packet, as
opposed to<br>
using say destination and source address, or even more granular
forwarding<br>
decisions. Policies are taken into consideration when the RIB and FIB
are<br>
constructed, which is not part of forwarding.</blockquote>
<div><br></div>
<div>Good point.</div>
<div><br></div>
<blockquote type="cite" cite>&gt; LDP is a much newer protocol and so
there is less of a &quot;large<br>
&gt; installed base that has been using this for years&quot;
sense.<br>
<br>
We do have quite considerable installed base for LDP and strictly
speaking it<br>
has been there for a few years. So, though the statement may not sound
as strong<br>
when applied to LDP, it is correct.</blockquote>
<div><br></div>
<div>then the text should say that LDP represents as big an installed
base as BGP's use of MD5, if that is the case. If not, then find some
accurate but similarly persuasive characterization that justifies this
use. For contrast, RFC xxxx specifies use of MD5 in the same fashion
for OSPF security, but nobody is suggesting that this be approved,
presumably because there is no large, installed base, right?</div>
<div><br></div>
<blockquote type="cite" cite><br>
&gt;&nbsp; I am also<br>
&gt; disturbed that the LDP spec (RFC 3036) refers to this as a
signature<br>
&gt; as well, and incorporates bad text from the old BGP RFC, e.g.,
&quot;...<br>
&gt; acts like a signature for that segment ..&quot; further
perpetuating the<br>
&gt; confusion between message authentication codes and digital<br>
&gt; signatures. Any chance we can get this fixed in both the BGP
document<br>
&gt; before it progresses and in the next rev of 3036?<br>
<br>
The BGP spec (neither old nor new) does not include this terminology,
so I don't</blockquote>
<blockquote type="cite" cite>think we need to fix it from this
perspective.
<blockquote><br></blockquote>
</blockquote>
<blockquote type="cite" cite>Improvement of the LDP spec could be
considered by the MPLS WG when it starts<br>
working on a new revision of the spec.<br>
<br>
Thank you.<br>
<br>
Alex</blockquote>
<div><br></div>
<div>you are right that the primary focus of this discussion is
progression of BGP. But, since you argued that LDP is appropriately
included in the rationale discussion for this document, I assume you
will want to progress that RFC too,</div>
<div>otherwise why bother mentioning it now?&nbsp; I would rather not
have to revisit this at that time, so I suggest you ask the MPLS WG to
make a note of this error now.</div>
<div><br></div>
<div>Steve</div>
</body>
</html>
--============_-1130942848==_ma============--

To: IETF-Announce: ;
Cc: [email-masked]
From: [email-masked]
Reply-to: [email-masked]
Subject: [Idr] I-D ACTION:draft-ietf-idr-cease-subcode-05.txt
Sender: [email-masked]
Date: Thu, 25 Mar 2004 15:38:28 -0500

--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-05.txt
	Pages		: 5
	Date		: 2004-3-25
	
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-05.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-05.txt".

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-idr-cease-subcode-05.txt".

--NextPart

--OtherAccess

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

ENCODING mime
FILE /internet-drafts/draft-ietf-idr-cease-subcode-05.txt

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

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

--OtherAccess--

--NextPart--

From: Alex Zinin <[email-masked]>
Reply-To: Alex Zinin <[email-masked]>
To: Stephen Kent <[email-masked]>
CC: Steve Bellovin <[email-masked]>, [email-masked], [email-masked]
Subject: [Idr] Re: [saag] draft-iesg-tcpmd5app-00.txt
Sender: [email-masked]
Date: Tue, 6 Apr 2004 16:26:38 -0700

Steve-

> the BGP document cites mandatory use of RFC 2385 as one of the 
> changes, up front, but then never makes any reference to the RFC in 
> the text. That's not a good way to communicate the intent of the 
> change, i.e., the intent of the change has not been integrated into 
> the body of the spec.

It seems that you simply have missed the following reference in the "Security
Considerations" section:

 draft-ietf-idr-bgp4-23.txt:

    The authentication mechanism that an implementation of BGP MUST sup-
    port is specified in [RFC2385]. The authentication provided by this
    mechanism could be done on a per peer basis.

    BGP vulnerabilities analysis is discussed in [BGP_VULN].

> in the context of Steve Bellovin's document there is no reason to
> perpetuate the error of the RFC 2385 title, i.e., to continue to 
> refer to the message authentication code created by the use of a 
> shared secret and a hash function as a "signature."  One might even 
> take this opportunity to point out that the title of the RFC is 
> misleading and should not be confused with digital signature 
> technologies.

My understanding is that Steve used the wording from the 2385's title on
purpose, since we're talking about a specific document with a specific title,
plus about a TCP option with a specific name (though now considered misleading).

>>  > LDP is a much newer protocol and so there is less of a "large
>>>  installed base that has been using this for years" sense.
>>
>>We do have quite considerable installed base for LDP and strictly speaking it
>>has been there for a few years. So, though the statement may not 
>>sound as strong
>>when applied to LDP, it is correct.

> then the text should say that LDP represents as big an installed base 
> as BGP's use of MD5, if that is the case. If not, then find some 
> accurate but similarly persuasive characterization that justifies 
> this use.

OK. We'll see if the wording can be improved.

> For contrast, RFC xxxx specifies use of MD5 in the same 
> fashion for OSPF security, but nobody is suggesting that this be 
> approved, presumably because there is no large, installed base, right?

RFC 2328 includes the OSPF MD5 authentication option (similar to TCP-MD5 in its
transport nature). It's widely deployed and is a full IETF Standard. If you mean
"OSPF with Digital Signatures" (RFC2154), then it is EXP, and I have heard of
only one or two implementations.

>>>   I am also
>>>  disturbed that the LDP spec (RFC 3036) refers to this as a signature
>>>  as well, and incorporates bad text from the old BGP RFC, e.g., "...
>>>  acts like a signature for that segment .." further perpetuating the
>>>  confusion between message authentication codes and digital
>>>  signatures. Any chance we can get this fixed in both the BGP document
>>>  before it progresses and in the next rev of 3036?
>>
>>The BGP spec (neither old nor new) does not include this 
>>terminology, so I don't
>>think we need to fix it from this perspective.
>>
>>Improvement of the LDP spec could be considered by the MPLS WG when it starts
>>working on a new revision of the spec.
>>
>>Thank you.
>>
>>Alex

> you are right that the primary focus of this discussion is 
> progression of BGP. But, since you argued that LDP is appropriately 
> included in the rationale discussion for this document, I assume you 
> will want to progress that RFC too,
> otherwise why bother mentioning it now?  I would rather not have to 
> revisit this at that time, so I suggest you ask the MPLS WG to make a 
> note of this error now.

Looking at the LDP spec, it uses the word "signature" as part of the reference
to the "TCP MD5 Signature Option", specified in 2385. While it could be argued
that 2385 uses incorrect terminology, it would be confusing to refer to it as
something like "TCP MD5 Message Digest Option" or "TCP MD5 Authentication
Option", as this is not what 2385 specifies.

Thanks

Alex

From: Alex Zinin <[email-masked]>
Reply-To: Alex Zinin <[email-masked]>
To: Stephen Kent <[email-masked]>
CC: Steve Bellovin <[email-masked]>, [email-masked], [email-masked]
Subject: [Idr] Re: [saag] draft-iesg-tcpmd5app-00.txt
Sender: [email-masked]
Date: Fri, 2 Apr 2004 19:03:02 -0800

Steve-

Thanks for looking at this. My comments inline below.

I've added the IDR mailing list, since your comments cover the base spec as
well.

Wednesday, March 31, 2004, 1:34:47 PM, Stephen Kent wrote:
> Steve,

> The text explaining why the MD5 checksum is not a good candidate for 
> use in broader IETF protocol contexts is very well written.

> The discussion of why BGP-4 can't easily change at this time to 
> another integrity mechanism is also very good. However, when I looked 
> quickly at the new BGP draft (intended to replace the extant RFC) I 
> was unable to find any discussion of using the MD5 option. There are 
> references to RFC 2385 in the discussion of what has changed, and in 
> the security considerations section, and the normative references 
> section. But a search on "MD5," "RFC 2385," "authentication," 
> "integrity," or "security" does not point a reader to any text that
> says in any detail how to use this TCP option in the BGP context.

As you said, the spec refers to the RFC 2385. RFC 2385 titled "Protection of BGP
Sessions via the TCP MD5 Signature Option", in turn, describes how the option
can be used to secure a TCP sessions, for BGP in particular. Is there something
specific you were looking for?

> The
> section entitled "TCP Options that may be used with BGP" makes no 
> reference to it. Can someone point me to where the new BGP document 
> actually says how this TCP option is used?

Appendix E "TCP options that may be used with BGP" could indeed mention that the
MD5 option can be used for BGP sessions. Yakov, please log this.

> Also, I note that the document abstract says:

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

> The term "solely" seems inappropriate, since it ignores the role that 
> local policy plays in route selection, right? I think I know what the 
> authors meant to say, but the text does not seem to be correct in 
> this regard.

It seems that the abstract is correct, actually. Routers indeed _forward_
packets using solely the destination address from the packet, as opposed to
using say destination and source address, or even more granular forwarding
decisions. Policies are taken into consideration when the RIB and FIB are
constructed, which is not part of forwarding.

> LDP is a much newer protocol and so there is less of a "large 
> installed base that has been using this for years" sense.

We do have quite considerable installed base for LDP and strictly speaking it
has been there for a few years. So, though the statement may not sound as strong
when applied to LDP, it is correct.

>  I am also 
> disturbed that the LDP spec (RFC 3036) refers to this as a signature 
> as well, and incorporates bad text from the old BGP RFC, e.g., "... 
> acts like a signature for that segment .." further perpetuating the 
> confusion between message authentication codes and digital 
> signatures. Any chance we can get this fixed in both the BGP document 
> before it progresses and in the next rev of 3036?

The BGP spec (neither old nor new) does not include this terminology, so I don't
think we need to fix it from this perspective.

Improvement of the LDP spec could be considered by the MPLS WG when it starts
working on a new revision of the spec.

Thank you.

Alex

To: Alex Zinin <[email-masked]>, Bill Fenner <[email-masked]>
cc: [email-masked], [email-masked], [email-masked], [email-masked]
From: Yakov Rekhter <[email-masked]>
Subject: [Idr] BGP Extended Communities to Proposed Standard
Sender: [email-masked]
Date: Fri, 02 Apr 2004 06:27:14 -0800

Alex and Bill,

The IDR WG would like to ask the IESG to advance BGP Extended Communities
to a Proposed Standard.

The spec is draft-ietf-idr-bgp-ext-communities-07.txt.
The implementation report is draft-rekhter-ext-communities-survey-02.txt.

Yakov.