Subject: RE: Review of draft-ietf-idr-bgp4-17.txt

From: "Natale, Jonathan" <[email-masked]>
Date: Wed, 11 Sep 2002 13:46:45 -0400

(your page nums are wrong)

1. agree, but cap. Is not a msg type
2. agree
3. disagree, but maybe:
IGP = network was explicitly introduced into bgp (network cmd)
INCOMPLETE = network was implicitly introduced into bgp (redistribute)
EGP = other
Also, maybe a discussion/reference on how this is used in decision process.
(I have seen folks infer that EGP == EBGP, so this has been a source of
confusion.  May add a note that this is historic???  What do operators use
Origin = EGP for??? (comments?))
4. disagree (covered elsewhere)

-----Original Message-----
From: Abarbanel, Benjamin [mailto:[email-masked]] 
Sent: Wednesday, September 11, 2002 10:59 AM
To: [email-masked]'
Subject: Review of draft-ietf-idr-bgp4-17.txt

Part I:

Editorial Comments:
===================
1. P. 7 Type: Need to add the new message types such as, Capability
Negotiations (RFC2842), Route Refresh, etc.

2. P. 9, right after "This document defines the following optional
parameters:"
Need to mention possible options, such as: Capabilitites (RFC2842),
Multiprotocol extensions (RFC2858), Route Refresh (RFC2918).

3. P. 13, EGP, are there other EGP protocols other than BGP that are in use?
If not, change EGP to BGP.

4. P.23, change the following: 

"The MULTI_EXIT_DISC attribute may be used on external (inter-AS)
 links to discriminate among multiple exit or entry points to the same
 neighboring AS ..."

 To the following:

"The MULTI_EXIT_DISC is an optional non-transitive attribute which may be
used on external (inter-AS) links to discriminate among multiple exit or
entry points to the same neighboring AS ..."

5. In section 8, there are a number of Timers, Counters, etc. that need to
be explicitly defined before they are used by the FSM. Perhaps these
definitions should go in the Glossary section.

---

From: Curtis Villamizar <[email-masked]>
Date: Wed, 11 Sep 2002 18:17:27 -0400

In message <[email-masked]
> 4. disagree (covered elsewhere)

We might want to say the value EGP in the ORIGIN field (which does
mean the EGP protocol, not any EGP type protocol) is depricated since
the EGP protocol has been moved to historic but retain the value to
document what it used to mean.

Curtis

ps - Page numbers should be taken from the .txt file.  All other
formats are supplemental and only the .txt file is authoritative.
[Easier to grep too.]

---

From: Jeffrey Haas <[email-masked]>
Date: Thu, 12 Sep 2002 10:47:46 -0400

> document what it used to mean.

I would ask us to consider carefully before deprecating it.
While no longer used (from what I've seen or heard) as the origin
of the route being from the EGP protocol, people *are* using it in
their route-maps to bias route selection.

-- 
Jeff Haas 
NextHop Technologies

---

From: [email-masked]
Date: Thu, 12 Sep 2002 17:19:22 +0200

I tend to agree with this.
please note that EGP is still not depreciated as such (RFC904 is still not
overruled!)

Hans De Vleeschouwer
Alcatel.

---

From: Curtis Villamizar <[email-masked]>
Date: Fri, 13 Sep 2002 14:24:18 -0400

> their route-maps to bias route selection.

We should at least change the wording to indicate that EGP referred to
a now historical protocol.

The applications statement 1772-bis can mention the out of spec usage
that is occurring.  (Give them a knob and who knows what they'll do
with it).

Curtis