One document matched: draft-ietf-idr-bgp-issues-04.xml
<?xml version="1.0"?>
<!DOCTYPE rfc SYSTEM "rfc3978.dtd">
<?rfc strict="yes" ?>
<?rfc toc="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<rfc ipr="trust200902" category="info">
<front>
<title abbrev="BGP Issues"> Issues in Revising BGP-4 (RFC1771 to RFC4271) </title>
<author initials="A." surname="Lange" fullname="Andrew S. Lange">
<organization>Alcatel-Lucent</organization>
<address>
<email>andrew.lange@alcatel-lucent.com</email>
</address>
</author>
<date year="2011" />
<area>Routing</area>
<workgroup>IDR</workgroup>
<keyword>I-D</keyword>
<keyword>Internet-Draft</keyword>
<keyword>BGP BGP-4 Routing</keyword>
<abstract><t>
This document records the issues discussed and the consensus reached in
the Interdomain Routing (IDR) Working Group during its efforts to revise
and bring up to date the base specification for the BGP-4 protocol as documented in RFC1771. The results of these efforts are encoded in RFC4271.
</t></abstract>
</front>
<middle>
<section anchor="Introduction" title="Introduction">
<t> This document records the issues discussed and the consensus reached in
the Interdomain Routing (IDR) Working Group during its efforts to revise
and bring up to date the base specification for the BGP-4 protocol as documented in RFC1771. The results of these efforts are encoded in RFC4271. The
rational for doing this is simple: Experience has demonstrated that the same
issues and questions tend to come up again and again. This memo will
document not only the decisions on these issues but also how and why
the working group reached those conclusions. We hope that this will
help make future discussions more fruitful by providing them with a
historical context.
</t>
<t>
This document traces the evolution of the BGP-4 base specification from
its incarnation as draft-ietf-idr-bgp4-17.txt through the big revision
and update push culminating in draft-ietf-idr-bgp4-19.txt. It is divided
into two main sections. The first deals with the issues discussed between
-17 and -18, and the second deals with the issues discussed between -18
and -19.
</t>
<t>
N.B. There is no rhyme or reason to the numbering scheme other than
unique tags to address the issues.
</t>
</section>
<section anchor="The Issues from -17 to -18" title="The Issues from -17 to -18">
<t>
This section lists the issues discussed on the list from late August
to late October 2002.
</t>
<section anchor="IDR WG Charter" title="IDR WG Charter">
<t>
Status: Consensus
<vspace />
Change: Yes
<vspace />
Summary: New charter adopted.
</t>
<t>
Discussion:
</t>
<t>
A variety of discussions surrounded the new charter. The rough
consensus is to accept the new charter that the AD's have proposed,
and to push as hard a possible to get the base spec to RFC status
so other drafts that are dependent can also move forward.
</t>
<t>
For our information, Alex has provided these approximate time lines:
</t>
<t>
Stage Anticipated delay Comment
--------------------------------------------------------------------
AD-review 1-4 weeks The document may go back
depending on to the WG for the
workload AD-review comments to be
addressed; this would
introduce additional
delay.
</t>
<t>
IETF LC 2 weeks Same as above
</t>
<t>
IESG review & 1-2 weeks depending Same as above
telechat on when the IETF LC ends
--------------------------------------------------------------------
</t>
<t>
Note that if the document is sent back to the WG at some stage, required
changes may warrant an additional WG Last Call.
</t>
<t>
I can personally commit to a 2-week upper bound for the AD-review
period. Bill may have a different timer granularity.
</t>
<t>
The opinions expressed on this were 7 in favor, 4 against.
</t>
<t>
This thread has messages subjects of "BGP spec and IDR WG charter"
and "IDR WG charter".
</t>
</section>
<section anchor="TCP Port" title="TCP Port">
<t>
Status: Consensus
<vspace />
Change: Yes
<vspace />
Summary:
<list>
<t>
Change:
<vspace />
"BGP uses TCP port 179 for establishing its connections."
</t>
<t>
To:
<vspace />
"BGP listens on TCP port 179."
</t>
</list>
</t>
<t>
Discussion:
</t>
<t>
There has been a discussion on clarifying the wording in Section 2,
on which port BGP uses. The original text was:
</t>
<t>
"BGP uses TCP port 179 for establishing its connections."
</t>
<t>
The proposed new text is:
</t>
<t>
"BGP listens on TCP port 179."
</t>
<t>
There seems to be a rough consensus that the new text is better.
</t>
<t>
This thread has a message subject of "Review: Section 2, TCP Port 179"
</t>
</section>
<section anchor="FSM wording for what state BGP accepts connections in" title="FSM wording for what state BGP accepts connections in">
<t>
Status: Consensus
<vspace />
Change: No
<vspace />
Summary: No change necessary
</t>
<t>
Discussion:
</t>
<t>
An issue was brought up later in the "Review: Section 2, TCP Port 179"
thread about the words in the FSM for what state BGP accepts connections
in. The consensus is that the existing wording is clear.
</t>
</section>
<section anchor="BGP Identifier/Router ID" title="BGP Identifier/Router ID">
<t>
Status: Consensus
<vspace />
Change: No
<vspace />
Summary: No change necessary to base draft. Perhaps in a BCP.
</t>
<t>
Discussion:
</t>
<t>
The "admin dist/gp spec proposal", "Router ID" and "bgp spec proposal"
threads discussed the BGP Identifier and how close or not it is to IGP's
Router ID. The consensus was that this discussion is better saved for a
BCP draft, and that it does not need to be contained in the base spec.
</t>
</section>
<section anchor="Direct EBGP Peers" title="Direct EBGP Peers">
<t>
Status: Consensus
Change: No
Summary: A recollection that ebgp peers must be direct. No text
proposed, no discussion.
</t>
<t>
Discussion:
</t>
<t>
Jonathan recalled something that stated that ebgp peers must be direct.
No specific sections were quoted.
</t>
<t>
Yakov responded to this with:
</t>
<t>
Section 5.1.3 talks about both the case where ebgp peers are 1 IP
hop away from each other:
</t>
<t>
2) When sending a message to an external peer X, and the peer is
one IP hop away from the speaker:
</t>
<t>
as well as the case where they are multiple IP hops away from each
other:
</t>
<t>
3) When sending a message to an external peer X, and the peer is
multiple IP hops away from the speaker (aka "multi hop EBGP"):
</t>
<t>
And emphasized that multi hop EBGP does exist.
</t>
<t>
This came up in the "bgp draft review" thread.
</t>
</section>
<section anchor="Disallow Private Addresses" title="Disallow Private Addresses">
<t>
Status: Consensus
<vspace />
Change: No
<vspace />
Summary: No change necessary
</t>
<t>
Discussion:
</t>
<t>
In the thread entitled "bgp draft review":
</t>
<t>
Mentioned explicitly disallowing private addresses. The
consensus was that there is no reason to disallow them. Which IP
addresses peers use is an operational issue.
</t>
</section>
<section anchor="Renumber Appendix Sections" title="Renumber Appendix Sections">
<t>
Status: Consensus
<vspace />
Change: Yes
<vspace />
Summary:
Rename/renumber appendix sections so they do not have the
same numbers as sections of the main text.
</t>
<t>
Discussion:
</t>
<t>
In the tread entitled "bgp draft review":
</t>
<t>
This thread brought up renaming sections in the appendix to avoid
confusion with sections of the same number in the main text.
</t>
<t>
Yakov responded that he would do so in the next edition.
</t>
</section>
<section anchor="Jitter Text" title="Jitter Text">
<t>
Status: Consensus
<vspace />
Change: Yes
<vspace />
Summary:
<list>
<t>
Get rid of section 9.2.1.3 ("Jitter").
Move the text to an Appendix: "BGP Timers"
Expand text to indicate that jitter applies to all timers, including
ConnectRetry.
</t>
<t>
The text for the appendix is listed at the end of the discussion.
</t>
</list>
</t>
<t>
Discussion:
</t>
<t>
In the tread entitled "bgp draft review":
The thread also proposed:
</t>
<t>
"jitter should be applied to the
timers associated with MinASOriginationInterval, Keepalive, and MinRouteAdvertisementInterval"
</t>
<t>
Be changed to:
</t>
<t>
"jitter should be applied to the
timers associated with ConnectRetry timer"
</t>
<t>
Yakov agreed with making some changes and suggested that we make sure
that jitter is applied to all timers. Specifically, he proposes we
get rid of section 9.2.1.3 ("Jitter"), move the text of this
section into Appendix "BGP Timers", and expand the text to indicate
that jitter applies to ConnectRetry timer as well.
</t>
<t>
Jonathan, the original commenter, agreed with Yakov's suggestion.
</t>
<t>
In a follow-up to this issue, there was a question raised about the values
we have specified for timers in the document. Specifically:
</t>
<t>
The ConnectRetry timer is should have a value that is 'sufficiently
large to allow TCP initialization. Application of jitter can reduce the this
value (by up to 25%). A configuration which the ConnectRetry timer has been
pegged at a value close to TCP connection time may cause a connection to be
terminated as a result of this jitter. Is this a cause for concern ?
</t>
<t>
The default value suggested for ConnectRetry (120 seconds) is
sufficiently large that event with a jitter of 0.75, it will be greater than
TCP's connection establishment timer.
</t>
<t>
Is adding a jitter to the ConnectRetry timer a standard practice ? What
benefit does this provide ?
</t>
<t>
Curtis responded to this with:
</t>
<t>
The TCP connection establishment timer is 75 seconds (sysctl yield
"net.inet.tcp.keepinit: 75000" in BSD-oids).
</t>
<t>
The ConnectRetry determines when to make a second attempt after a
prior attempt to connect has failed. It is to avoid a rapid
succession of retries on immediate failures (for example "Connection
refused" if the peer was in the middle of a reboot, Network
Unreachable if you can't get there from here, etc) but also covers the
case where the TCP SYN goes off and is never heard from again.
</t>
<t>
And Jonathan replied with this information about current practice:
</t>
<t>
It seems to me that if you bring up all bgp peers at once it
may lead to load spikes on the network. Cisco seems to wait
27.5 +/- 2.5 seconds for IBGP, and 40 +/- 5 seconds for
EBGP--20 sec. from config time to the "open active, delay"
jittered delay assignment plus the jittered delay (5 to 10
sec. for IBGP, and 15 to 25 sec. for EBGP). This would also
apply for "no neighbor x.x.x.x shutdown". Their value of
ConnectRetry is 60sec. though, not sure how this value is used
(based on above). Maybe some Cisco folks can chime in on
this one???
</t>
<t>
I did not check Juniper.
</t>
<t>
Also, interestingly, they do not apply jitter to
the other timers (as far as I can tell), but I don't see
a problem with this.
</t>
<t>
Another timer that they use that is not mentioned in
the draft/rfc is the next hop resolution timer which is 30
seconds. Although it would be nice to have this in the spec,
I will concede that it is out of scope and/or
implementation dependent.
</t>
<t>
So the question that arises from this followup, is how does this question
affect the text of the appendix on jitter?
</t>
<t>
Curtis replied that we need to only state that jitter should be applied
to all timers. Whether a vendor does so or not is a minor deficiency and
does not bear on interoperability. Therefore, specifying exact details
are not necessary.
</t>
<t>
After Jonathan's response Curtis and Jonathan agreed that jitter should
be added to all timers and that we should state so in the text.
</t>
<t>
Yakov proposed the following text for the appendix to discuss jitter:
</t>
<t>
I'd like to propose the following text for "BGP Timers" section:
</t>
<t>
BGP employs five timers: ConnectRetry (see Section 8), Hold Time
(see Section 4.2), KeepAlive (see Section 8), MinASOriginationInterval
(see Section 9.2.1.2), and MinRouteAdvertisementInterval (see
Section 9.2.1.1).
</t>
<t>
The suggested value for the ConnectRetry timer is 120 seconds.
</t>
<t>
The suggested value for the Hold Time is 90 seconds.
</t>
<t>
The suggested value for the KeepAlive timer is 1/3 of the Hold
Time.
</t>
<t>
The suggested value for the MinASOriginationInterval is 15
seconds.
</t>
<t>
The suggested value for the MinRouteAdvertisementInterval is 30
seconds.
</t>
<t>
An implementation of BGP MUST allow the Hold Time timer to be
configurable, and MAY allow the other timers to be configurable.
</t>
<t>
To minimize the likelihood that the distribution of BGP messages
by a given BGP speaker will contain peaks, jitter should be
applied to the timers associated with MinASOriginationInterval,
Keepalive, MinRouteAdvertisementInterval, and ConnectRetry. A
given BGP speaker shall apply the same jitter to each of these
quantities regardless of the destinations to which the updates
are being sent; that is, jitter will not be applied on a "per
peer" basis.
</t>
<t>
The amount of jitter to be introduced shall be determined by
multiplying the base value of the appropriate timer by a random
factor which is uniformly distributed in the range from 0.75 to
1.0.
</t>
<t>
Jeff & Ben agreed with this.
</t>
<t>
Justin suggested that we move the range from 0.75 to 1.25 to ensure that the
average is around the configured value. Yakov agreed with Justin's changes.
Jonathan disagreed, arguing that it was out-of-scope for the task of
clarifying the text only. Justin agreed and withdrew his comment.
</t>
<t>
Curtis liked the general text, but suggested these modifications:
</t>
<t>
minor improvement (not really an objection) --
s/suggested value/suggested default value/g
</t>
<t>
Also
</t>
<t>
s/shall apply the same jitter/may apply the same jitter/
(to each of these quantities regardless of ...).
</t>
<t>
s/jitter will not be applied/jitter need not be configured/
(on a "per peer" basis).
</t>
<t>
He stated that in Avici's implementation they allow a lot of granularity
in timer settings, so this reflects current practice.
</t>
<t>
Curtis also suggested changing the last paragraph:
</t>
<t>
The suggested default amount of jitter shall be determined by
multiplying the base value of the appropriate timer by a random
factor which is uniformly distributed in the range from 0.75 to
1.0. A new random value should be picked each time the timer is
set. The range of the jitter random value MAY be configurable.
</t>
<t>
This would make it clear that it is possible to have this timer as
configurable and still be within spec.
</t>
<t>
Other comments on Yakov's text pointed out that IOS uses 5 seconds as
the default IBGP MinRouteAdvertisementInterval.
</t>
<t>
Tom pointed out that there seems to be a discrepancy between this text
and the FSM: The FSM has an OpenDelay timer. And the FSM suggests a
HoldTimer of 4 minutes.
</t>
<t>
In following up on this issue, Yakov stated:
</t>
<t>
Here is the final text for the BGP Timers section:
</t>
<t>
BGP employs five timers: ConnectRetry (see Section 8), Hold Time
(see Section 4.2), KeepAlive (see Section 8), MinASOriginationInterval
(see Section 9.2.1.2), and MinRouteAdvertisementInterval (see
Section 9.2.1.1).
</t>
<t>
The suggested default value for the ConnectRetry timer is 120
seconds.
</t>
<t>
The suggested default value for the Hold Time is 90 seconds.
</t>
<t>
The suggested default value for the KeepAlive timer is 1/3 of
the Hold Time.
</t>
<t>
The suggested default value for the MinASOriginationInterval is
15 seconds.
</t>
<t>
The suggested default value for the MinRouteAdvertisementInterval
is 30 seconds.
</t>
<t>
An implementation of BGP MUST allow the Hold Time timer to be
configurable, and MAY allow the other timers to be configurable.
</t>
<t>
To minimize the likelihood that the distribution of BGP messages
by a given BGP speaker will contain peaks, jitter should be
applied to the timers associated with MinASOriginationInterval,
Keepalive, MinRouteAdvertisementInterval, and ConnectRetry. A
given BGP speaker may apply the same jitter to each of these
quantities regardless of the destinations to which the updates
are being sent; that is, jitter need not be configured on a "per
peer" basis.
</t>
<t>
The suggested default amount of jitter shall be determined by
multiplying the base value of the appropriate timer by a random
factor which is uniformly distributed in the range from 0.75 to
1.0. A new random value should be picked each time the timer
is set. The range of the jitter random value MAY be configurable.
</t>
<t>
With this in mind, I would suggest we mark this issue as closed.
</t>
<t>
Jonathan suggested adding "per peer" to the text, Yakov responded with
this text:
</t>
<t>
An implementation of BGP MUST allow the Hold Time timer to be configurable
on a per peer basis, and MAY allow the other timers to be configurable.
</t>
<t>
This proposal met with general agreement. This issue is at consensus.
</t>
</section>
<section anchor="Reference to RFC904 - EGP Protocol" title="Reference to RFC904 - EGP Protocol">
<t>
Status: Consensus
<vspace />
Change: Yes
<vspace />
Summary: Add a reference to RFC904
</t>
<t>
Discussion:
</t>
<t>
The "Review Comment: Origin Attribute pg 14" thread suggested adding a
reference to RFC904(?), to refer to the EGP protocol. There was no
discussion.
</t>
<t>
Yakov agreed to this, and Jonathan seconded it.
</t>
</section>
<section anchor="Extending AS_PATH Attribute" title="Extending AS_PATH Attribute">
<t>
Status: Consensus
<vspace />
Change: Yes
<vspace />
Summary:
Add this to 9.2:
</t>
<t>
If due to the limits on the maximum size of an UPDATE message
(see Section 4) a single route doesn't fit into the message,
the BGP speaker MUST not advertise the route to its peers and
may choose to log an error locally.
</t>
<t>
</t>
<t>
Discussion:
</t>
<t>
The "Extending AS_PATH attribute length en route" thread brought up
the issue of what action should we specify when we receive a route
with an AS_PATH that exceeds the defined maximum length. There was
some discussion, and it was suggested that, after logging the error,
the route not be propagated.
</t>
<t>
Yakov stated that:
</t>
<t>
The real issue here is how to handle the case when a route
(a single address prefix + path attributes) doesn't fit into
4K bytes (as the max BGP message size is 4 K). To address
this issue I would suggest to add the following to 9.2:
</t>
<t>
After some discussion, Yakov's proposed text's last sentence was dropped
and we arrived at:
</t>
<t>
If due to the limits on the maximum size of an UPDATE message
(see Section 4) a single route doesn't fit into the message,
the BGP speaker may choose not to advertise the route to its
peers.
</t>
<t>
In response to Andrew's clarification question to the list, Curtis
responded:
</t>
<t>
Wording would be more like:
</t>
<t>
If the attributes for a specific prefix becomes too large to fit
the prefix into the maximum sized BGP UPDATE message, the prefix
should not be advertised further. Truncation or omission of
attributes should not occur unless policies for such modifications
are specifically configured. Such policies may contribute to the
formation of route loops and are not within the scope of this
protocol specification.
</t>
<t>
After some additional discussion, it was decided that we add "and may
choose to log an error locally." to the end of Yakov's text.
</t>
<t>
Also, we agreed to change "may choose not to advertise..." to
"MUST NOT advertise...".
</t>
<t>
So the text on the table right now is:
</t>
<t>
If due to the limits on the maximum size of an UPDATE message
(see Section 4) a single route doesn't fit into the message,
the BGP speaker MUST not advertise the route to its peers and
may choose to log an error locally.
</t>
<t>
This met with one agreement and no disagreements. We have a consensus.
</t>
</section>
<section anchor="Rules for routes from Loc-RIB to Adj-RIB-Out - Section 9.1" title="Rules for routes from Loc-RIB to Adj-RIB-Out - Section 9.1">
<t>
Status: Consensus
<vspace />
Change: Yes
<vspace />
Summary: Add this text:
</t>
<t>
The local speaker SHALL then install that route in the Loc-RIB,
replacing any route to the same destination that is currently being
held in the Loc-RIB. When the new BGP route is installed in the Rout-
ing Table, care must be taken to ensure that existing routes to the
same destination that are now considered invalid are removed from the
Routing Table. Whether or not the new BGP route replaces an existing
non-BGP route in the Routing Table depends on the policy configured
on the BGP speaker.
</t>
<t>
Discussion:
</t>
<t>
The "Proxy: comments on section 9.1.3" thread brought up some lack of
clarity in the section discussing the rules for which routes get propagated
from the Loc-RIB into the Adj-RIB-Out. These discussions resulted in
a number of suggestions for new text.
</t>
<t>
The first new text was proposed to clarify the issue that the thread
first brought up:
</t>
<t>
I agree that this could use some clarification. How about adding
to b) in section 9.1:
</t>
<t>
</t>
<t>
The Loc-RIB must contain only one route per destination; further, it
must include all routes that the BGP speaker is using.
</t>
<t>
changing c) in section 9.1.2 to:
</t>
<t>
c) is selected as a result of the Phase 2 tie breaking rules specified
in 9.1.2.2, or
</t>
<t>
and adding
</t>
<t>
d) when routing protocols other than BGP are in use, is determined by
some other local means to be the route that will actually be used to
reach a particular destination.
</t>
<t>
This text was never discussed or a consensus formed on putting it in the
document.
</t>
<t>
This modification to 9.1.2 was also proposed to address the same concern:
</t>
<t>
How about changing the paragraph after c) in 9.1.2 to:
</t>
<t>
The local speaker SHALL then install that route in the Loc-RIB,
replacing any route to the same destination that is currently being
held in the Loc-RIB. This route SHALL then also be installed in
the BGP speakers forwarding table.
</t>
<t>
There was one response in the negative to this change, arguing that is
is not necessary.
</t>
<t>
Yakov replied to this that:
</t>
<t>
Wrt "adding to b) in section 9.1", the second part (after ";") is
redundant as this point is already stated in 3.2. Wrt the first
point about Loc-RIB containing just one route per destination, I
would suggest to add it to section 3.2, where Loc-RIB is first
introduced, rather than adding it to 9.1.
</t>
<t>
Wrt "changing c)... and adding...", I have no objections to add/modify
the text, as suggested above.
</t>
<t>
I am not sure though that changing the paragraph after c) in 9.1.2
is really necessary though, so I would prefer to keep it as is.
</t>
<t>
The "issue 11" thread this was being discussed in then digressed to the
topic, now covered in issue 11.3.
</t>
<t>
Ben re-addressed the original issue with this input:
</t>
<t>
I have somewhat of an issue with the paragraph after item c section 9.1.2
as discussed.
</t>
<t>
which is =>
</t>
<t>
"The local speaker SHALL then install that route in the Loc-RIB,
replacing any route to the same destination that is currently being
held in the Loc-RIB. If the new BGP route is installed in the Routing
Table (as a result of the local policy decision), care must be taken
to ensure that invalid BGP routes to the same destination are removed
from the Routing Table. Whether or not the new route replaces an
already existing non-BGP route in the routing table depends on the
policy configured on the BGP speaker."
</t>
<t>
Can we assume that its OK to have a route present in the Loc-RIB and
possibly in the adj-RIB-Out but not in the Routing table due to some policy.
Won't we violate rule number 1? Only advertise what you use.
</t>
<t>
As conversely implied in this sentence =>
</t>
<t>
"If the new BGP route is installed in the Routing Table (as a result of the
local policy decision), care must be taken to ensure that invalid BGP routes
to the same destination are removed from the Routing Table"
</t>
<t>
I would rephrase the paragraph as follows =>
</t>
<t>
"The local speaker SHALL then install that route in the Loc-RIB,
replacing any route to the same destination that is currently being
held in the Loc-RIB. When the new BGP route is installed in the Routing
Table, care must be taken to ensure that existing routes to the same
destination that are now considered invalid are removed from the
Routing Table. Whether or not the new BGP route replaces an existing
non-BGP route in the routing table depends on the policy configured
on the BGP speaker."
</t>
<t>
Jeff replied:
</t>
<t>
With the exception that Routing Table should be capitalized throughout,
I'd suggest we take this as consensus.
</t>
<t>
Yakov agreed. We are at consensus.
</t>
<section anchor="Rules for routes from Loc-RIB to Adj-RIB-Out - Section 9.1.3" title="Rules for routes from Loc-RIB to Adj-RIB-Out - Section 9.1.3">
<t>
Status: Consensus
<vspace />
Change: Yes
<vspace />
Summary: The text below will be added to the -18 version.
</t>
<t>
Discussion:
</t>
<t>
In further discussions around this issue, this text was also proposed:
</t>
<t>
How about adding to section 9.1.3, at the end:
</t>
<t>
Any local-policy which results in reachability being added to an
Adj-RIB-Out without also being added to the local BGP speaker's
forwarding table is beyond the scope of this document.
</t>
<t>
This suggestion received one response that agreed to this change.
</t>
<t>
This text will be added to the -18 version, and since there were no
objections, this issue has been moved to consensus.
</t>
</section>
<section anchor="Rules for routes from Loc-RIB to Adj-RIB-Out - Section 2" title="Rules for routes from Loc-RIB to Adj-RIB-Out - Section 2">
<t>
Status: Consensus
<vspace />
Change: Yes
<vspace />
Summary: Add this text:
</t>
<t>
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.
</t>
<t>
Discussion:
</t>
<t>
Additionally this thread produced this section of new text, in section 2:
</t>
<t>
<OLD>
</t>
<t>
"one must focus on the rule that a BGP speaker advertises
to its peers (other BGP speakers which it communicates with) in
neighboring ASs only those routes that it itself uses."
</t>
<t>
Should be changed to
</t>
<t>
<NEW #1>
</t>
<t>
"one must focus on the rule that a BGP speaker advertises
to its peers (other BGP speakers which it communicates with) in
neighboring ASs only routes whose NLRIs are locally reachable."
</t>
<t>
<NEW #2>
</t>
<t>
"one must focus on the rule that a BGP speaker advertises
to its peers (other BGP speakers which it communicates with) in
neighboring ASs only routes which are locally reachable. Local
reachability can be achieved by having any protocol route to
the given destination in the routing table."
</t>
<t>
There were a lot of emails exchanged on this topic with a variety of
texts proposed (see early in the "Active Route" thread). This issue
reopened with Jonathan, who brought up the issue originally, stating that:
</t>
<t>
The issue I raised, and would like to be [re-]considered is with:
</t>
<t>
"one must focus on the rule that a BGP speaker advertises to its peers
(other BGP speakers which it communicates with) in neighboring ASs only
those routes that it itself uses."
</t>
<t>
Curtis replied that:
</t>
<t>
That is called route origination and it is allowed by:
</t>
<t>
9.4 Originating BGP routes
</t>
<t>
A BGP speaker may originate BGP routes by injecting routing
information acquired by some other means (e.g. via an IGP) into BGP.
[...] The decision whether to distribute non-BGP
acquired routes within an AS via BGP or not depends on the
environment within the AS (e.g. type of IGP) and should be controlled
via configuration.
</t>
<t>
Advice on what to put in the AS_PATH and NEXT_HOP is in the document.
</t>
<t>
He continued with:
</t>
<t>
I don't think there was ever consensus on what to do with the
statement "a BGP speaker advertises to its peers (other BGP speakers
which it communicates with) in neighboring ASs only those routes that
it itself uses". Some reasonable choices are:
</t>
<t>
1. Omit it (the implied consensus of the rewrite of the paragraph
in 32.2).
</t>
<t>
2. Leave it as is and put it in another paragraph to separate it
from the destination based routing statement.
</t>
<t>
3. Clean up the wording and put it in another paragraph to separate
it from the destination based routing statement.
</t>
<t>
The separate paragraph for 2 would be the exact sentence we now have.
</t>
<t>
A BGP speaker advertises to its peers (other BGP speakers which it
communicates with) in neighboring ASs only those routes that it
itself uses.
</t>
<t>
In possibility 3 we (try to) clear up the ambiguity about the meaning
of the word "use" in this sentence.
</t>
<t>
A BGP speaker advertises to its peers (other BGP speakers which it
communicates with) in neighboring ASs 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 either directly
used in forwarding or in a specifically configured case where the
BGP route would be forwarded internally but IGP forwarding
information is used. The latter case reflects a usage in which the
IGP is used for forwarding but BGP is originated to IBGP to carry
attributes that cannot be carried by the IGP (for example, BGP
communities [N]). Other special cases such as virtual routers and
multiple instances of BGP on a single router are beyond the scope
of this document but for each of these the statement "a BGP speaker
advertises to its peers (other BGP speakers which it communicates
with) in neighboring ASs only those routes that it itself uses" can
(and should in the definition of the extension) be made true with
an appropriate definition of the word "use".
</t>
<t>
Unless someone volunteers better wording this may be a good starting
point. I thing the last sentence borders on ridiculous in a protocol
spec but may be necessary to address specific objections raised on
this mailing list. If we want to elaborate on the meaning of the word
"use" and address the objections this is what we end up with.
</t>
<t>
Of course looking at what we ended up with, I'd also go along with the
other two options (leave it out or put the one sentence in a separate
paragraph as is).
</t>
<t>
After some additional discussion (in the "issue 11.2" thread), we have
come to a consensus on this text:
</t>
<t>
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.
</t>
<t>
This issue is at consensus.
</t>
</section>
<section anchor="Documenting IBGP Multipath" title="Documenting IBGP Multipath">
<t>
Status: Consensus
<vspace />
Change: Yes
<vspace />
Summary: The documenting of IBGP Multipath is left to another Internet
Draft. The consensus is that it should not be in the base spec.
</t>
<t>
Discussion:
</t>
<t>
This thread began in the "issue 11" discussion. In it it was proposed
that:
</t>
<t>
There is support in some router vendors to allow more than one BGP route
to be installed, for the purpose for load balancing. Given that this is a
current practice, and seems to be a useful feature as well, should we insist
that only one route be installed in the Loc-RIB ?
</t>
<t>
I would like to suggest that all sections which use MUST in the context
of only one route in Loc-RIB be relaxed a little to a SHOULD, and a section
added that states that it is possible for a n implementation to add more
than one route to the Loc-RIB for the purposes of load balancing.
</t>
<t>
While it will be useful to describe how this situation is the handler,
it is perhaps sufficient to even state that handling of this situation is
outside the scope of this RFC.
</t>
<t>
I am including some proposed text for this purpose:
</t>
<t>
For the part:
</t>
<t>
> The Loc-RIB must contain only one route per destination;
</t>
<t>
consider instead,
</t>
<t>
% The Loc-RIB SHOULD contain only one route per destination.
% An implementation may choose to install multiple routes to
% a destination (for the purposes of load balancing). The
% handling of such a configuration, however, is outside the
% scope of this RFC.
</t>
<t>
Perhaps, this can be in section 3.2 instead.
</t>
<t>
After much discussion back and forth, it was agreed that documenting
IBGP Multipath behavior is a good thing. However, it is something that
belongs in another draft.
</t>
<t>
Alex opened this issue up again. There were a flurry of responses, most
all of them agreeing with the original consensus that we should document
this feature in a different draft, since it doesn't affect the core
interoperability requirements, and we want to advance the spec in a
timely manner.
</t>
<t>
Alex persisted in his assertion that this belongs in the base specification.
Right now, the issue is still open.
</t>
<t>
This discussion later expanded in scope to include all BGP multipath.
</t>
<t>
Curtis laid out a good description of the various flavors of multipath:
</t>
<t>
In addition to IGP multihop, there are two cases of BGP multipath.
</t>
<t>
In IGP multihop there is one BGP advertisement but to ways to reach th
BGP NEXT_HOP via the IGP.
</t>
<t>
In one case of BGP multihop, two (or more) IBGP routers peering with
the same external AS have equal routes to a destination and are an
equal cost away from a third router. BGP multihop is applicable to
that third router. Without BGP multihop, BGP would normally pick the
BGP NEXT_HOP of the advertisement from only one of those IBGP peers
(using BGP Identifier) and use that. The IGP lookup would yield one
next hop. With BGP multihop, BGP uses the BGP NEXT_HOP of both
advertisements. Each BGP NEXT_HOP has a different IGP next hop (one
or more IGP next hop).
</t>
<t>
The second case is where all of the candidates routes for BGP
multipath are external. Seldom does IGP multipath come into play for
EBGP (odd tunneled EBGP multihop cases maybe). Typically the load is
split among two (or more) routers in the same AS.
</t>
<t>
If in EBGP multipath you split among routers in difference AS, an
aggregate should be formed. This is still prior to the IGP cost rule
in the route selection.
</t>
<t>
Normally one would not combine IBGP and EBGP in multihop given that
the decision point for multihop is after "d" in 9.1.2.2. If the
multihop decision was prior to "d", then two routers each with an
external peering would forward some of the traffic to each other and
for some src/dst pairs, they'd form a loop. [So don't do that!]
</t>
<t>
This is getting to be a lot to add to the base spec. I hope we've
convinced you that we should put it in another document.
</t>
<t>
Curtis later added specific text, that could serve as a start for the
new document (or added to the base spec if the consensus ended up
going the other way):
</t>
<t>
BGP specifies how to select the single best route. OSPF
specifically defines procedures for handling equal cost multipath
(ECMP) [cite OSPF]. The same technique has been applied to ISIS.
A similar technique has been used with BGP. Variations exist but
the decision to support BGP multipath, the specific variation of
BGP multipath, or not to support it, does not affect
interoperability.
</t>
<t>
A naive implementations of ECMP can cause severe performance
degradation for TCP flows. To avoid this, implementations of BGP
multipath SHOULD maintain packet ordering within microflows as
described in [cite rfc2991, rfc2992].
</t>
<t>
BGP multipath, if implemented, SHOULD be disabled by default.
</t>
<t>
In addition to IGP multipath (OSPF ECMP and ISIS equivalent), there
are two variations of BGP multipath described here. A BGP
implementation may offer both, either one, or neither variation of
BGP multipath. Other variations of BGP multipath may exist, but no
guarantees can be made in this protocol specification of their
properties or impact on interoperability.
</t>
<t>
Where IGP multipath is used, there is an interaction with BGP
learned routes. The lookup of a BGP NEXT_HOP in the IGP can
result in the selection of an IGP multipath entry. This is not a
variation of BGP multipath. When this occurs, one BGP route is
selected as the best but there is more than one way to reach the BGP
NEXT_HOP via the IGP.
</t>
<t>
In one variation of BGP multipath, a set of more than one IBGP
routers peering with the same external AS have equal routes to a
destination and are an equal IGP cost away from a second set of one
or more routers. BGP multipath is applicable to the latter set of
routers. Without BGP multipath, BGP would pick the BGP NEXT_HOP of
the advertisement from only one of those IBGP peers (using BGP
Identifier) and use only that BGP route. With BGP multipath, BGP
uses the BGP NEXT_HOP of more than one of these equal cost
advertisements, yielding more than one BGP NEXT_HOP. Each BGP
NEXT_HOP has a different IGP next hop (one or more IGP next hop if
IGP multipath is in use).
</t>
<t>
The second case is where all of the candidates routes for BGP
multipath are external and learned by a single BGP peer. Without
BGP multipath this peer would select only one of the BGP routes and
obtain only one BGP NEXT_HOP. With BGP multipath, more than one
equal cost route is selected yielding more than one BGP NEXT_HOP.
Seldom does IGP multipath come into play when looking up an EBGP
NEXT_HOP but could in principle be applicable.
</t>
<t>
If in EBGP multipath traffic is split among routers in difference
AS, an aggregate SHOULD be formed so as to propagate a route with
an accurate AS_PATH. If the resulting aggregate is not more
specific than the components, the AS_SET SHOULD NOT be dropped.
</t>
<t>
The decision point for multipath is after step "d" in Section
9.1.2.2 (prefer externally learned routes). IBGP learned and EBGP
learned routes MUST NOT be combined in multipath. If the multipath
decision is prior to "d", then two routers each with an external
peering would form a routing loop.
</t>
<t>
The decision point for multipath is generally after step "e" in
Section 9.1.2.2. Some relaxation of the "equal cost" rule (also
applicable to IGP multipath) is possible. In addition to the equal
cost BGP NEXT_HOPS available at BGP route selection, if the IGP
next hop for other BGP NEXT_HOPs are of lower cost, then those may
be used as well. This relaxation of the step "e" is possible but
is not widely implemented (and may not be implemented at all).
</t>
<t>
The consensus of the majority of the IDR WG is to keep this in a
separate draft and out of the base spec.
</t>
</section>
</section>
<section anchor="TCP Behavior Wording" title="TCP Behavior Wording">
<t>
Status: Consensus
<vspace />
Change: No
<vspace />
Summary: In issue 19 we decided to remove this section entirely. As a
result the previous consensus on this issue (no change) is needed
moot.
</t>
<t>
Discussion:
The subject-less "your mail" thread discussed a wording clarification from:
</t>
<t>
"An implementation that would "hang" the routing information process while
trying to read from a peer could set up a message buffer (4096 bytes) per
peer and fill it with data as available until a complete message has been
received. "
</t>
<t>
To something that is more TCP-correct, such as:
</t>
<t>
"An implementation that would "hang" the routing information process while
trying to received from a peer could set up a message buffer (4096 bytes) per
peer and fill it with data as available until a complete message has been
received. "
</t>
<t>
(only change: "read" to "received" This was one of a couple of suggested
changes.)
</t>
<t>
This suggestion was quite contentious, and although there were a variety
of alternate texts proposed, the only consensus was that this was a very
minor issue, and probably not worth changing.
</t>
<t>
In issue 19 we decided to remove this section entirely.
</t>
</section>
<section anchor="Next Hop for Originated Route" title="Next Hop for Originated Route">
<t>
Status: Consensus
<vspace />
Change: No
<vspace />
Summary: No responses, assumed consensus to keep things the same.
</t>
<t>
Discussion:
</t>
<t>
There was a one-message thread entitled "next hop for originated route".
This message received no response, so the assumption is that there is
a consensus to keep things as they are.
</t>
<t>
For related discussion see issue 61.
</t>
</section>
<section anchor="NEXT_HOP to Internal Peer" title="NEXT_HOP to Internal Peer">
<t>
Status: Consensus
<vspace />
Change: No
<vspace />
Summary: Closed in favor of issue 61.
</t>
<t>
Discussion:
</t>
<t>
The thread entitled "NEXT_HOP to internal peer" starts with this question:
</t>
<t>
When sending a locally originated route to an internal peer, what should
NEXT_HOP be set to?
</t>
<t>
One response suggested that we add a line stating that the NEXT_HOP address
originates from the IGP.
</t>
<t>
Since this issue and issue 61 are basically the same, except 61 proposes
text, we'll close this issue in favor of 61.
</t>
</section>
<section anchor="Grammar Fix" title="Grammar Fix">
<t>
Status: Consensus
<vspace />
Change: Yes
<vspace />
Summary:
Change:
"The Prefix field contains IP address prefixes ..."
To:
"contains an IP address prefix ..."
</t>
<t>
Discussion:
The thread entitled "Review comment: bottom of page 16" corrects a grammar
mistake by suggesting we change:
</t>
<t>
"The Prefix field contains IP address prefixes ..."
</t>
<t>
to:
</t>
<t>
"contains an IP address prefix ..."
</t>
<t>
Yakov responded that this will be fixed in -18.
</t>
<t>
The consensus seems to be to correct this, and go with the new text.
</t>
</section>
<section anchor="Need ToC, Glossary and Index" title="Need ToC, Glossary and Index">
<t>
Status: Consensus
<vspace />
Change: Yes
<vspace />
Summary: Need to add a Table of Contents (ToC), Glossary and Index to the
draft. Will be added in draft -18.
</t>
<t>
Discussion:
</t>
<t>
The "Review Comments: draft-ietf-idr-bgp4-17.txt" thread suggests:
</t>
<t>
1. Document needs, Table of Contents, Glossary, and Index
</t>
<t>
2. Paths, Routes, and Prefixes need to be defined in the spec early on (like
in a glossary), so it is obvious what is implied.
</t>
<t>
Yakov responded that draft -18 will have a ToC and definition of commonly
used terms.
</t>
</section>
<section anchor="Add References to other RFC-status BGP docs to base spec" title="Add References to other RFC-status BGP docs to base spec">
<t>
Status: Consensus
<vspace />
Change: Yes
<vspace />
Summary: Add references to other RFC-status BGP docs to the base spec.
</t>
<t>
Discussion:
</t>
<t>
The "Review Comments: draft-ietf-idr-bgp4-17.txt" thread then changes
titles to: "Review of draft-ietf-idr-bgp4-17.txt" and goes on to
suggest:
</t>
<t>
3. All BGP Extensions described in other documents that made it to RFC
status should be at least referenced in the Reference section P.64. This is
justifiable since it's the core BGP standard spec.
</t>
<t>
Yakov responded that this will be added to the -18 review.
</t>
<t>
Jonathan agreed.
</t>
</section>
<section anchor="IP Layer Fragmentation" title="IP Layer Fragmentation">
<t>
Status: Consensus
<vspace />
Change: No
<vspace />
Summary: No need to mention IP Layer Fragmentation in the BGP specification,
since this is taken care of at the TCP level.
</t>
<t>
Discussion:
</t>
<t>
1. P.6 section 4. Message Formats, its possible for the source BGP peer IP
layer to fragment a message such that the receiving BGP peer socket layer
would have to reassemble it. Need to mention this, since BGP implementations
are required to do this.
</t>
<t>
The response to this was that, while true, reassembly is something that
is inherent in the TCP layer that BGP rides over. Therefore, this is
something that is in the TCP spec, and needn't be repeated in the BGP spec.
This comment was reaffirmed. There seems to be consensus that this isn't
something that needs to be in the BGP spec.
</t>
</section>
<section anchor="Appendix Section 6.2: Processing Messages on a Stream Protocol" title="Appendix Section 6.2: Processing Messages on a Stream Protocol">
<t>
Status: Consensus
<vspace />
Change: Yes
<vspace />
Summary: Remove the section entirely, as this is something that does not
belong in the base spec.
</t>
<t>
Discussion:
</t>
<t>
This first came up in response to Issue 17:
</t>
<t>
There was one comment suggesting that section 6.2 (Processing Messages
on a Stream Protocol" mentioned this.
</t>
<t>
The original reviewer responded that the out-of-scope comment was out-of-place
and referred the responder to section 6.2 (appendix 6)
</t>
<t>
The original reviewer stated that he is happy with just adding a
reference to section 6.2 in appendix 6 and leaving it at that.
</t>
<t>
Curtis suggested we just add a reference to Stevens in appendix 6. 6.2
and be done with it. Specifically:
</t>
<t>
6.2 Processing Messages on a Stream Protocol
</t>
<t>
BGP uses TCP as a transport mechanism. If you are unsure as to
how to handle asynchronous reads and writes on TCP sockets please
refer to Unix Network Programming [RWStevens] or other
introductory text for programming techniques for the operating
system and TCP implementation that you are using.
</t>
<t>
There were further suggestions to remove the section entirely as out-of-scope.
At least 3 people agreed with this.
</t>
<t>
Alex responded that he sees no reason to remove it, but wouldn't have a
problem if the WG decides to do so.
</t>
<t>
There seems to be general agreement that this section should be removed.
</t>
<t>
N.B. This also affects issue 12.
</t>
</section>
<section anchor="Wording fix in Section 4.3" title="Wording fix in Section 4.3">
<t>
Status: Consensus
<vspace />
Change: Yes
<vspace />
Summary: A small change for clarity in section 4.3
</t>
<t>
Discussion:
</t>
<t>
This suggestion grew out of the discussion on Issue 18.
</t>
<t>
The following change was suggested in section 4.3, second line of the
first paragraph:
</t>
<t>
s/UPDATE packet/UPDATE message/
</t>
<t>
Yakov agreed to this change and updated the draft.
</t>
</section>
<section anchor="Authentication Text Update" title="Authentication Text Update">
<t>
Status: Consensus
<vspace />
Change: No
<vspace />
Summary: The consensus is that additional references to RFC2385 are not
necessary.
</t>
<t>
Discussion:
</t>
<t>
P. 10, "Authentication Data:" section you might want to add this,
It is also possible to use MD5 (RFC2385) at the transport layer to validate
the entire BGP message.
</t>
<t>
Yakov replied to this:
</t>
<t>
There is already text that covers this:
</t>
<t>
"Any authentication scheme used by TCP (e.g., RFC2385 [RFC2385])
may be used in addition to BGP's own authentication mechanisms."
</t>
<t>
....
</t>
<t>
"In addition, BGP supports the ability to authenticate its data
stream by using [RFC2385]."
</t>
<t>
So, I see no need to add the text proposed above.
</t>
<t>
Ishi agreed with Yakov. Jonathan disagreed since he thought no one uses
BGP auth. Ishi replied that there are lots of people who do use it.
Jonathan replied with a clarification question: "Who uses *BGP's own*
authentication mechanisms???" Ron Bonica replied that they use BGP auth.
There was some additional discussion over who implements simple password
authentication vs. MD5.
</t>
<t>
After further discussion, the consensus seems to be that we should leave
the text as it is for the reasons Yakov pointed out. There was some
discussion over opening a new issue to discuss deprecating the BGP
auth mechanism discussed in RFC1771 in favor of the mechanism in RFC2385.
</t>
<t>
The issue of Deprecating BGP AUTH is discussed in issue 62.
</t>
</section>
<section anchor="Scope of Path Attribute Field" title="Scope of Path Attribute Field">
<t>
Status: Consensus
<vspace />
Change: Yes
<vspace />
Summary: This is already being covered by text that has been added to
the -18 draft.
</t>
<t>
Discussion:
</t>
<t>
P. 12, right after "Path Attributes". The following sentence should be
added to this section to clarify the scope of the Path Attribute field.
"All attributes in the Path Attribute field represent the characteristics of
all the route prefixes defined in the NLRI field of the message".
</t>
<t>
Yakov replied to this that:
</t>
<t>
This will be covered by the following text in 3.1 that will be in the
-18 version (see also issue 54).
</t>
<t>
Routes are advertised between BGP speakers in UPDATE messages.
Multiple routes that have the same path attributes can be
advertised in a single UPDATE message by including multiple
prefixes in the NLRI field of the UPDATE message.
</t>
<t>
Therefore there is no need to add the sentence proposed above.
</t>
<t>
There were no objections to this statement, so this issue has been moved
into consensus.
</t>
</section>
<section anchor="Withdrawn and Updated routes in the same UPDATE message" title="Withdrawn and Updated routes in the same UPDATE message">
<t>
Status: Consensus
<vspace />
Change: No
<vspace />
Summary: For various reasons, not least of which is compatibility with
existing implementations, the decision was made to keep thing the way
they are.
</t>
<t>
Discussion:
</t>
<t>
4. P.16, last paragraph in section 4.3 as stated,
"An UPDATE message should not include the same address prefix in the
WITHDRAWN ROUTES and Network Layer Reachability Information fields,
however a BGP speaker MUST be able to process UPDATE messages in this
form. A BGP speaker should treat an UPDATE message of this form as if
the WITHDRAWN ROUTES doesn't contain the address prefix."
</t>
<t>
This complexity could have been avoided if withdrawn routes and NLRI
prefixes with their attributes were mutually exclusive of each other and
appeared in different update messages. If that was the case, the priority of
which field to process first would have been as simple as using "first come,
first served" message processing approach.
</t>
<t>
Yakov commented that this would make the case where they are both in the
same message unspecified.
</t>
<t>
John commented that this is something we don't want to change this late in
the game. Although it was acknowledged that this might be a good change
if we were working from a clean slate.
</t>
<t>
Ben acceded that this was somewhat wishful thinking on his part.
</t>
<t>
Curtis's comment seems to coincide with this message, stating:
</t>
<t>
The existing rules are very clear.
</t>
<t>
Summarized:
</t>
<t>
If an UPDATE contains only a withdraw for a prefix, then withdraw
whatever route the peer had previously sent.
</t>
<t>
If an UPDATE contains the prefix only in the NLRI section, replace
whatever route had previously been advertised by the peer or add a
route if there was no previous route, in both cases adding a route
with the current attributes.
</t>
<t>
Don't put the same prefix in the same in both the withdraw and NLRI
section of the same update.
</t>
<t>
If you receive an UPDATE with the same prefix in both the withdraw
and NLRI, ignore the withdraw. [Some older implementations thought
this was a good way to say "delete then add".]
</t>
<t>
Process UPDATEs from the same peer in the order received.
</t>
<t>
And goes on to say, that to him, these rules are clear from the existing
text.
</t>
<t>
Consensus is that while this would be nice, we need to stick with what
we have, and move on.
</t>
</section>
<section anchor="Addition or Deletion of Path Attributes" title="Addition or Deletion of Path Attributes">
<t>
Status: Consensus
<vspace />
Change: Yes
<vspace />
Summary:
Add the following to section 3.1:
</t>
<t>
Changing the attributes of a route is accomplished by advertising a
replacement route. The replacement route carries new (changed)
attributes and has the same NLRI as the original route.
</t>
<t>
Discussion:
</t>
<t>
5. P. 20 Its not stated how we delete or modify Path Attributes associated
with NLRI prefixes.
</t>
<t>
A response to this comment said that this is implicit in the definition
of "route" and the general withdraw/replace behavior and therefore doesn't
need to be repeated.
</t>
<t>
Ben responded saying that, while there was an assumption, there was
no well defined mechanism, and this leads to ambiguity.
</t>
<t>
John responded, no need to define everything explicitly, or we'll be here
forever.
</t>
<t>
Picking this thread up again, Yakov argued:
</t>
<t>
By *definition* a route is a <path attribute, NLRI> pair. From that
definition it follows that changing one or more path attributes of
a route means changing a route, which means withdrawing the old
route (route with the old attributes) from service and advertising
a new route (route with the new attributes). Procedures for doing
this are well-defined (see section 3.1), and therefore no new text
to cover this is needed.
</t>
<t>
Jonathan agreed with this statement, but Ben argued that the text in
section 3 is insufficient the way it is currently written. After
two iterations, Ben and Yakov agreed on this formulation for an
update to section 3.1:
</t>
<t>
Changing the attributes of a route is accomplished by advertising a
replacement route. The replacement route carries new (changed)
attributes and has the same NLRI as the original route.
</t>
<t>
Jeff objected somewhat to the wording, since, because of a bgp route
is defined as a <path attribute, NLRI> pair, changing either part of
that pair, by definition, changes the route. He acknowledged that
this might fall under the category of implementation detail.
</t>
<t>
Yakov presented the view that he thought we were at consensus with the
text he proposed above. Jonathan agreed. There were no objections, so
this is moved to Consensus.
</t>
</section>
<section anchor="NEXT_HOP Semantics" title="NEXT_HOP Semantics">
<t>
Status: Consensus
<vspace />
Change: No
<vspace />
Summary: After responders pointed out another sentence, this comment
was resolved. Things will stay the way they are.
</t>
<t>
Discussion:
</t>
<t>
1. P.28, 2nd to last paragraph. The line that reads, "To be semantically
correct, the IP address in the NEXT_HOP must not be the IP address of the
receiving speaker, and the NEXT_HOP IP address must either be the sender's
IP address (used to establish the BGP session), or the interface associated
with the NEXT_HOP IP address must share a common subnet with the receiving
BGP speaker..."
</t>
<t>
This is not always true, what if the current ASBR BGP router is advertising
an external AS route (to a IBGP Peer) whose NEXT_HOP IP address is the IP
address of the EBGP peer in the other AS?
</t>
<t>
A response to this pointed out that right before this is a sentence stating
that this only applied to eBGP links, and only when the peers are one hop
from each other, so a modification is unnecessary. This response was
confirmed with another.
</t>
<t>
The original reviewer acknowledged this and withdrew the comment.
</t>
<t>
The consensus is to leave things the way they are.
</t>
</section>
<section anchor="Attributes with Multiple Prefixes" title="Attributes with Multiple Prefixes">
<t>
Status: Consensus
<vspace />
Change: No
<vspace />
Summary: After some discussion, the consensus is to keep things the same
since the suggested behavior is defined in the message format.
</t>
<t>
Discussion:
</t>
<t>
2. P. 29, Section 6.3. Add this rule near the attribute rules.
"Multiple prefixes that require the same attribute type with different
values must never appear in the same update message".
</t>
<t>
A response to this suggested that this text is unnecessary since this
behavior is ruled out by the way the message format is defined.
</t>
<t>
The original commenter agrees with the responder. The consensus is to
leave things the way they are.
</t>
</section>
<section anchor="Allow All Non-Destructive Messages to Refresh Hold Timer" title="Allow All Non-Destructive Messages to Refresh Hold Timer">
<t>
Status: Consensus
<vspace />
Change: No
<vspace />
Summary: It is agreed that this is a change that exceeds the original
goal of this draft revision. This goal is to document existing
practice in an interoperable way.
</t>
<t>
Discussion:
</t>
<t>
3. P. 29, Section 6.5, Please rewrite this sentence from:
"If a system does not receive successive KEEPALIVE and/or UPDATE
and/or NOTIFICATION messages within the period specified in the Hold
Time field of the OPEN message ..."
</t>
<t>
To This:
"If a system does not receive successive KEEPALIVE and/or UPDATE
and/or any other BGP message within the period specified in the Hold
Time field of the OPEN message ..."
</t>
<t>
There is disagreement on this change. It has been discussed in other
threads.
</t>
<t>
The original commenter acknowledged that this is something that would
be "adding a new feature" as opposed to the stated goal of "documenting
what exists." He suggested that the ADs decide if we should open the
door for new features or not.
</t>
<t>
Yakov replied to this that he would suggest we keep things as is, since
the purpose is to document current implementations.
</t>
<t>
This did not meet with any objections, so this issue has been moved into
consensus.
</t>
</section>
<section anchor="BGP Identifier as Variable Quantity" title="BGP Identifier as Variable Quantity">
<t>
Status: Consensus
<vspace />
Change: No
<vspace />
Summary: The consensus is that changing the BGP Identifier in the base
draft is out-of-scope at this point in the draft evolution.
</t>
<t>
Discussion:
</t>
<t>
4. P. 31, section 6.8, Please rewrite this sentence from:
"Comparing BGP Identifiers is done by treating them as (4-octet long)
unsigned integers."
</t>
<t>
To This:
"Comparing BGP Identifiers is done by treating them as large numbers based
on their IP Address type (e.g. IPv4, IPv6, etc.)."
</t>
<t>
A response to this was that since BGP Identifier is defined in the base
spec as a 4 byte unsigned integer, and not a variable quantity, the
sentence as written is acceptable. This was also confirmed by another
response.
</t>
<t>
The original commenter was thinking of IPv6, and providing sufficient
space to allow a full v6 address to be used.
</t>
<t>
Again, responders said that this is out-of-scope for the current draft.
</t>
</section>
<section anchor="State Why Unresolveable Routes Should Be Kept in Adj-RIB-In" title="State Why Unresolveable Routes Should Be Kept in Adj-RIB-In">
<t>
Status: Consensus
<vspace />
Change: Yes
<vspace />
Summary:
Add:
</t>
<t>
"in case they become resolvable" after the last sentence on p. 46.
</t>
<t>
Discussion:
</t>
<t>
5. P.46, last sentence, "However, corresponding unresolvable routes SHOULD
be kept in the Adj-RIBs-In." It would helpful if the author states why
unresolvable routes should be kept in Adj-RIBs-In?
</t>
<t>
A response to this stated "In case they become resolvable"
</t>
<t>
Yakov responded that:
</t>
<t>
I suggest we add "in case they become resolvable" after the last sentence
on p. 46.
</t>
<t>
The original commenter stated that:
Then the point that the peer will not refresh the route if we drop
them (unless we use Route Refresh) because they are unreachable should be
made.
</t>
<t>
Yakov also responded that:
</t>
<t>
This should be clear from the following text in Section 3:
</t>
<t>
The initial data flow is the portion of the BGP routing table that
is allowed by the export policy, called the Adj-Ribs-Out (see 3.2).
Incremental updates are sent as the routing tables change. BGP does
not require periodic refresh of the routing table.
</t>
<t>
Jonathan, who was the original commenter, agreed with both the changed
text and the clarity of section 3.
</t>
</section>
<section anchor="Mention Other Message Types" title="Mention Other Message Types">
<t>
Status: Consensus
<vspace />
Change: Yes
<vspace />
Summary: Add a reference to RFC2918 at the end of the type code list.
</t>
<t>
Discussion:
</t>
<t>
1. P. 7 Type: Need to add the new message types such as, Capability
Negotiations (RFC2842), Route Refresh, etc.
</t>
<t>
One response argued that these are out-of-scope of the base document.
One response agreed, but thought that it should be capability and not
message type. The original commenter responded about Message type
from the capability draft.
</t>
<t>
Sue mentioned this would be added in the second round.
</t>
<t>
Yakov replied that:
</t>
<t>
The only new message type that is covered by an RFC (rather than
just an Internet Draft) is the Refresh message. With this in mind
how about replacing the following:
</t>
<t>
The following type codes are defined:
</t>
<t>
1 - OPEN
2 - UPDATE
3 - NOTIFICATION
4 - KEEPALIVE
</t>
<t>
with
</t>
<t>
This document defines the following type codes:
</t>
<t>
1 - OPEN
2 - UPDATE
3 - NOTIFICATION
4 - KEEPALIVE
</t>
<t>
[RFC2918] defines one more type code.
</t>
<t>
Jonathan agreed with this change. This issue has been moved to consensus.
</t>
</section>
<section anchor="Add References to Additional Options" title="Add References to Additional Options">
<t>
Status: Consensus
<vspace />
Change: Yes
<vspace />
Summary: Consensus to add:
</t>
<t>
[RFC2842] defines another Optional Parameter.
</t>
<t>
Discussion:
</t>
<t>
2. P. 9, right after "This document defines the following optional
parameters:"
Need to mention possible options, such as: Capabilities (RFC2842),
Multiprotocol extensions (RFC2858), Route Refresh (RFC2918).
</t>
<t>
One response agreed that adding references would be fine.
A second response agreed.
</t>
<t>
Yakov replied that:
</t>
<t>
Please note that only rfc2842 defines an OPEN optional parameter.
Neither rfc2858 nor rfc2918 defines an OPEN optional parameter.
</t>
<t>
With this in mind I would suggest to add the following text:
</t>
<t>
[RFC2842] defines another Optional Parameter.
</t>
<t>
The original poster agreed with this modification. This issue is at
consensus.
</t>
</section>
<section anchor="Clarify EGP Reference" title="Clarify EGP Reference">
<t>
Status: Consensus
<vspace />
Change: No
<vspace />
Summary: The consensus is that this was addressed in 32.1, so we can close
this.
</t>
<t>
Discussion:
</t>
<t>
3. P. 13, EGP, are there other EGP protocols other than BGP that are in use?
If not, change EGP to BGP.
</t>
<t>
A response to this suggested that we add a reference to [1] (the EGP
spec) here.
</t>
<t>
Another response clarified that this refers to EGP-the-protocol and
NOT the class.
</t>
<t>
Another response disagreed, but suggested that:
</t>
<t>
IGP = network was explicitly introduced into bgp (network cmd)
INCOMPLETE = network was implicitly introduced into bgp (redistribute)
EGP = other
</t>
<t>
The original commenter thought that this referred to EGP-the-class of
protocols. And why not use BGP therefore, as the only EGP.
</t>
<t>
There was some discussion over whether or not we should mention something
that is historical.
</t>
<t>
Jeff suggested a footnote in the Origin section about EGP.
</t>
<t>
Curtis suggested that we state that the EGP in ORIGIN is deprecated,
but retain the value to document what it used to mean.
</t>
<t>
This reviewer thinks a statement about whether this "EGP" origin refers
to the protocol or the class or protocols would be useful.
</t>
<t>
Yakov replied that an EGP reference will be added (see issue 9).
</t>
<t>
Yakov also stated that he doesn't see what is wrong with the current text,
and suggested we keep it. This includes leaving out any reference to the
status of the EGP spec. He sees that it is clear from context that we
are talking about "the EGP" [RFC904].
</t>
<t>
Jeff noted that this issue has been sufficiently addressed in the solution
to 32.1. This met with agreement. We are at consensus.
</t>
<section anchor="EGP ORIGIN Clarification" title="EGP ORIGIN Clarification">
<t>
Status: Consensus
<vspace />
Change: Yes
<vspace />
Summary:
Change section 5.1.1 to read:
</t>
<t>
ORIGIN is a well-known mandatory attribute. The ORIGIN attribute
shall be generated by the speaker that originates the
associated routing information. Its value SHOULD NOT be
changed by any other speaker."
</t>
<t>
Consensus to change:
</t>
<t>
1 EGP - Network Layer Reachability Information
learned via the EGP protocol
</t>
<t>
to:
</t>
<t>
1 EGP - Network Layer Reachability Information
learned via the EGP protocol [RFC904]
</t>
<t>
</t>
<t>
Discussion:
</t>
<t>
This discussion is picked up again in the "Review of draft-ietf-idr-bgp4-17"
thread, where specific text is proposed:
</t>
<t>
Old:
</t>
<t>
"ORIGIN is a well-known mandatory attribute that defines the
origin of the path information. The data octet can assume
the following values:
</t>
<t>
Value Meaning
</t>
<t>
0 IGP - Network Layer Reachability Information
is interior to the originating AS
</t>
<t>
1 EGP - Network Layer Reachability Information
learned via the EGP protocol
</t>
<t>
2 INCOMPLETE - Network Layer Reachability
Information learned by some other means"
New:
</t>
<t>
"ORIGIN is a well-known mandatory attribute that defines the
origin of the path information. The data octet can assume
the following values:
</t>
<t>
Value Meaning
</t>
<t>
0 IGP - NLRI was explicitly introduced into bgp
</t>
<t>
1 EGP - this value was administratively
configured to affect policy decisions or
NLRI was learned via the EGP protocol [1]
</t>
<t>
2 INCOMPLETE - NLRI was implicitly introduced
into bgp"
</t>
<t>
since:
1) The network command sets the origin to IGP and I remember seeing
somewhere that only static routes should be set to IGP.
2) The primary use of EGP value is policy
3) EGP seems to still exist, anyway even if it does not it is
not worth re-writing the world.
</t>
<t>
Also, change:
"5.1.1 ORIGIN
</t>
<t>
</t>
<t>
ORIGIN is a well-known mandatory attribute. The ORIGIN attribute
shall be generated by the autonomous system that originates the
associated routing information. It shall be included in the UPDATE
messages of all BGP speakers that choose to propagate this
information to other BGP speakers."
</t>
<t>
to:
"5.1.1 ORIGIN
</t>
<t>
The value of the ORIGIN attribute shall be set by the speaker
that originates the associated NLRI. Its value shall not be
changed by any other speaker unless the other speaker is
administratively configured to do so to affect policy
decisions."
</t>
<t>
since:
1) It is already defined as well-known mandatory attribute.
2) It may be set differently within the same AS (not saying this is good).
3) It is commonly used for policy, but by default does not get changed.
4) Speakers have no choice, it is mandatory.
</t>
<t>
After much continued discussion on this in the "issue 32.1" thread, we seem
to have come to a consensus that section 5.1.1 should read:
</t>
<t>
ORIGIN is a well-known mandatory attribute. The ORIGIN attribute
shall be generated by the speaker that originates the
associated routing information. Its value should not be
changed by any other speaker unless the other speaker is
administratively configured to do so to affect policy
decisions."
</t>
<t>
This text met with a number of agreements, and one disagreement stating
that we shouldn't have the "unless administratively configured" portion.
</t>
<t>
After some further discussion, we have this text on the table:
</t>
<t>
ORIGIN is a well-known mandatory attribute. The ORIGIN attribute
is generated by the BGP speaker that originates the associated BGP
routing information. The attribute shall be included in the UPDATE
messages of all BGP speakers that choose to propagate this information
to other BGP speakers.
</t>
<t>
Jonathan suggested that we change "propagate this information" to
"forward this route". He also mentioned that he would prefer something
more explicit instead of/in addition to "The attribute shall be included
in the UPDATE messages of all BGP speakers that choose to propagate this
information to other BGP speakers." such as "other speakers do not
change the ORIGIN value."
</t>
<t>
On the issue of making the EGP ORIGIN type more clear Andrew proposed:
</t>
<t>
To me, there seems to be sufficient confusion around the "EGP"
reference to merit some sort of clarification. The simplest modification
would be to change:
</t>
<t>
1 EGP - Network Layer Reachability Information
learned via the EGP protocol
</t>
<t>
to:
</t>
<t>
1 EGP - Network Layer Reachability Information
learned via the EGP protocol [RFC904]
</t>
<t>
That would clarify that we're talking about the protocol, and not the
class-of-protocols, or EBGP. It would leave unstated that this could
theoretically be used to muck with route selection. I think that is
ok. If operators want to override ORIGIN to affect some hoho magic,
they are welcome to do so, but I don't think it needs to be documented
in the base spec.
</t>
<t>
This met with a number of agreements.
</t>
<t>
On the second text section we are working on, Jonathan objected to the
current working text below and suggested an alternate:
</t>
<t>
CHANGE:
</t>
<t>
"ORIGIN is a well-known mandatory attribute. The ORIGIN attribute
is generated by the BGP speaker that originates the associated BGP
routing information. The attribute shall be included in the UPDATE
messages of all BGP speakers that choose to propagate this information
to other BGP speakers."
</t>
<t>
TO:
</t>
<t>
"ORIGIN is a well-known mandatory attribute. The ORIGIN attribute
shall be generated by the speaker that originates the
associated routing information. Its value should not be
changed by any other speaker unless the other speaker is
administratively configured to do so to affect policy
decisions."
</t>
<t>
-or-
</t>
<t>
"ORIGIN is a well-known mandatory attribute. The ORIGIN attribute
shall be generated by the speaker that originates the
associated routing information. Its value should not be
changed by any other speaker."
</t>
<t>
Jonathan cited a recent example of someone who was still confused by this
section of the text in -17 (not specifically the working text).
</t>
<t>
Yakov proposed this as final text:
</t>
<t>
In 4.3:
</t>
<t>
a) ORIGIN (Type Code 1):
</t>
<t>
ORIGIN is a well-known mandatory attribute that defines the
origin of the path information. The data octet can assume
the following values:
</t>
<t>
Value Meaning
</t>
<t>
0 IGP - Network Layer Reachability Information
is interior to the originating AS
</t>
<t>
1 EGP - Network Layer Reachability Information
learned via the EGP protocol [RFC904]
</t>
<t>
2 INCOMPLETE - Network Layer Reachability
Information learned by some other means
</t>
<t>
Usage of this attribute is defined in 5.1.1.
</t>
<t>
In 5.1.1:
</t>
<t>
ORIGIN is a well-known mandatory attribute. The ORIGIN attribute
shall be generated by the speaker that originates the
associated routing information. Its value SHOULD NOT be
changed by any other speaker."
</t>
<t>
This met with agreement. This issue is at consensus.
</t>
</section>
<section anchor="BGP Destination-based Forwarding Paradigm" title="BGP Destination-based Forwarding Paradigm">
<t>
Status: Consensus
<vspace />
Change: Yes
<vspace />
Summary: After much discussion, this is the consensus:
This text in the current draft:
</t>
<t>
To characterize the set of policy decisions that can be enforced
using BGP, one must focus on the rule that a BGP speaker advertises
to its peers (other BGP speakers which it communicates with) in
neighboring ASs only those routes that it itself uses. This rule
reflects the "hop-by-hop" routing paradigm generally used
throughout the current Internet. Note that some policies cannot
be supported by the "hop-by-hop" routing paradigm and thus
require techniques such as source routing (aka explicit routing)
to enforce. For example, BGP does not enable one AS to send
traffic to a neighboring AS intending that the traffic take a
different route from that taken by traffic originating in the
neighboring AS. On the other hand, BGP can support any policy
conforming to the "hop-by-hop" routing paradigm. Since the
current Internet uses only the "hop-by-hop" inter-AS routing
paradigm and since BGP can support any policy that conforms to
that paradigm, BGP is highly applicable as an inter-AS routing
protocol for the current Internet.
</t>
<t>
will be replaced in -18 with the following text:
</t>
<t>
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. Note that some policies cannot be supported by the
destination-based forwarding paradigm, and thus require techniques
such as source routing (aka explicit routing) to be enforced*.
Such policies can not be enforced using BGP either. For example,
BGP does not enable one AS to send traffic to a neighboring AS
for forwarding to some destination (reachable through but) beyond
that neighboring AS intending that the traffic take a different
route to that taken by the traffic originating in the neighboring
AS (for that same destination). On the other hand, BGP can
support any policy conforming to the destination-based forwarding
paradigm.
</t>
<t>
Discussion:
</t>
<t>
In response to these proposals, Yakov proposed that the real problem is that
it is not clear that BGP is build to support the destination-based
forwarding paradigm. To fix this, it was proposed that:
</t>
<t>
<OLD>
</t>
<t>
To characterize the set of policy decisions that can be enforced
using BGP, one must focus on the rule that a BGP speaker advertises
to its peers (other BGP speakers which it communicates with) in
neighboring ASs only those routes that it itself uses. This rule
reflects the "hop-by-hop" routing paradigm generally used
throughout the current Internet. Note that some policies cannot
be supported by the "hop-by-hop" routing paradigm and thus
require techniques such as source routing (aka explicit routing)
to enforce. For example, BGP does not enable one AS to send
traffic to a neighboring AS intending that the traffic take a
different route from that taken by traffic originating in the
neighboring AS. On the other hand, BGP can support any policy
conforming to the "hop-by-hop" routing paradigm. Since the
current Internet uses only the "hop-by-hop" inter-AS routing
paradigm and since BGP can support any policy that conforms to
that paradigm, BGP is highly applicable as an inter-AS routing
protocol for the current Internet.
</t>
<t>
<NEW>
</t>
<t>
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. Note that some policies cannot be supported by the
destination-based forwarding paradigm and thus require techniques
such as source routing (aka explicit routing) to enforce. Such
policies can not be enforced using BGP either. For example, BGP
does not enable one AS to send traffic to a neighboring AS
intending that the traffic take a different route from that
taken by traffic originating in the neighboring AS. On the
other hand, BGP can support any policy conforming to the
destination-based forwarding paradigm.
</t>
<t>
Curtis thinks the newer text here is more clear.
</t>
<t>
In response to the new text, Christian Martin proposed a slightly different
new text:
</t>
<t>
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 enforces
using BGP. Note that some policies cannot be supported by the
destination-based forwarding paradigm and thus require techniques
such as source routing (aka explicit routing) to enforce. Such
policies can not be enforced using BGP either. For example, BGP
does not enable one AS to send traffic to a neighboring AS
based on prefixes originating from the local AS. On the
other hand, BGP can support any policy conforming to the
destination-based forwarding paradigm.
</t>
<t>
To which Yakov replied:
</t>
<t>
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 enforces
using BGP. Note that some policies cannot be supported by the
destination-based forwarding paradigm, and thus require techniques
such as source routing (aka explicit routing) to enforce. Such
policies can not be enforced using BGP either. For example,
BGP does not enable one AS to send traffic through a neighboring
AS to some destination (which is outside of the neighboring
AS, but is reachable through the neighboring AS) intending that
the traffic take a different route from that taken by the traffic
to the same destination that originating in the neighboring AS.
On the other hand, BGP can support any policy conforming to
the destination-based forwarding paradigm.
</t>
<t>
And Chris responded:
</t>
<t>
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 enforces
using BGP. Note that some policies cannot be supported by the
destination-based forwarding paradigm, and thus require techniques
such as source routing (aka explicit routing) to enforce. Such
policies can not be enforced using BGP either. For example,
BGP does not enable one AS to send traffic through a neighboring
AS to some destination beyond the neighboring AS intending that
the traffic take a different route from that taken by traffic
to the same destination which originates in the neighboring AS.
In other words, the BGP policy of a local AS cannot affect the
downstream (aka, away from the local AS) forwarding policy of a
remote AS. On the other hand, BGP can support any policy conforming
to the destination-based forwarding paradigm.
</t>
<t>
Tom Petch preferred Yakov's second formulation, with these changes:
</t>
<t>
policies can not be enforced using BGP either. For example,
BGP does not enable one AS to send traffic
! to a neighboring AS for forwarding to some destination (reachable
through but) beyond
! that neighboring AS intending that
! the traffic take a different route to that taken by the traffic
! originating in the neighboring AS (for that same destination).
</t>
<t>
On the other hand, BGP can support any policy conforming to
the destination-based forwarding paradigm.
</t>
<t>
Yakov agreed to Tom's suggested changes.
</t>
</section>
</section>
<section anchor='Add "Optional Non-Transitive" to the MED Section' title='Add "Optional Non-Transitive" to the MED Section'>
<t>
Status: Consensus
<vspace />
Change: Yes
<vspace />
Summary: Add "Optional Non-Transitive" to MED Section
Add "well-known mandatory" to the NEXT_HOP Section
</t>
<t>
Discussion:
</t>
<t>
4. P.23, change the following:
</t>
<t>
"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 ..."
</t>
<t>
To the following:
</t>
<t>
"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 ..."
</t>
<t>
A responder disagreed, and stated reasons "covered elsewhere"
Original commenter asked for reasons, since the modification seemed obvious
to him.
</t>
<t>
Yakov agreed to make this change in -18.
</t>
<t>
Jonathan replied that:
</t>
<t>
5.1.3 NEXT_HOP also, it is missing " well-known mandatory".
</t>
<t>
Yakov also agreed to make this change.
</t>
</section>
<section anchor="Timer & Counter Definition" title="Timer & Counter Definition">
<t>
Status: Consensus
<vspace />
Change: No
<vspace />
Summary: No discussion, no text proposed, defaults to consensus for
no change.
</t>
<t>
Discussion:
</t>
<t>
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.
</t>
<t>
There has been no further discussion on this issue. Unless it is
brought up again, this issue is in consensus, with no change.
</t>
</section>
<section anchor="Fix Typo" title="Fix Typo">
<t>
Status: Consensus
<vspace />
Change: Yes
<vspace />
Summary: Fix a Typo. No discussion, but this seem clear.
</t>
<t>
Discussion:
</t>
<t>
1. P. 41. Typing error, "Each time time the local system...".
</t>
</section>
<section anchor="Add Adj-RIB-In, Adj-RIB-Out and Loc-RIB to the Glossary" title="Add Adj-RIB-In, Adj-RIB-Out and Loc-RIB to the Glossary">
<t>
Status: Consensus
<vspace />
Change: Yes
<vspace />
Summary: This change requires a glossary. Yakov has committed to having
a section where commonly used terms are defined in draft 18, so this
issue is at consensus.
</t>
<t>
Discussion:
</t>
<t>
2. Section 9.1, Need to have Adj-RIB-In, Adj-RIB-Out, and Loc-RIB in the
glossary, so when they are used in section 9.1, it is well understood what
they are.
</t>
<t>
Yakov replied:
</t>
<t>
will be added to the section "Definition of commonly used terms" in -18
version.
</t>
</section>
<section anchor='Combine "Unfeasible Routes" and "Withdrawn Routes"' title='Combine "Unfeasible Routes" and "Withdrawn Routes"'>
<t>
Status: Consensus
<vspace />
Change: Yes
<vspace />
Summary: Add the following terms to the "commonly used terms section":
</t>
<t>
Feasible route
A route that is available for use.
</t>
<t>
Unfeasible route
A previously advertised feasible route that is no longer available
for use.
</t>
<t>
Discussion:
</t>
<t>
3. P. 45, Phase I, There is no definition of what are unfeasible routes? Are
they the same as withdrawn routes? If so, the two should be combined to one
name.
</t>
<t>
Ishi replied to this that he thought that we could combine the two terms,
since there is limited difference from an implementation standpoint.
</t>
<t>
Yakov replied:
</t>
<t>
The routes are withdrawn from service because they are unfeasible,
not because they are "withdrawn". So, we need to keep the term
"unfeasible" to indicate the *reason* why a route could be withdrawn.
On the other hand, "withdrawn" is used as a verb, and to the best
of my knowledge "unfeasible" can't be used as a verb. With this
in mind, I don't think that we can combine the two into a single
term.
</t>
<t>
Ishi replied that he was convinced, and that the terms should stay
separate.
</t>
<t>
Andrew asked the list if we should define these terms in the "commonly
used terms" section in draft -18.
</t>
<t>
Ben replied that if we use them a lot, we should define them, and if not
local definitions will suffice.
</t>
<t>
There was some back and forth about the necessity of defining terms which
should be obvious.
</t>
<t>
mrr actually checked the doc to see if we were consistently using the
terms, and found:
</t>
<t>
It turns out there there is an inconsistency in the usage of the word
withdrawn.
</t>
<t>
Section 3.1:
</t>
<t>
There are three methods by which a given BGP speaker can indicate
that a route has been withdrawn from service:
</t>
<t>
...
</t>
<t>
b) a replacement route with the same NLRI can be advertised, or
</t>
<t>
...
</t>
<t>
Later, in the definition of Withdrawn Routes Length, we have:
</t>
<t>
A value of 0 indicates that no routes are being withdrawn from
service,
</t>
<t>
Taken together, this could be construed as meaning that a Withdrawn
Routes Length of 0 indicates that all routes included in the UPDATE
represent newly feasible routes... not replacement routes.
</t>
<t>
Now, it's possible that this problem has been removed by changes
to the text that have not yet been incorporated in to a new draft;
however, it arose because the text, for the most part, does _not_
use "withdrawn" in the standard way. Instead, it refers to
routes included in the WITHDRAWN ROUTES field of an UPDATE
message. Consequently, I propose defining a "withdrawn route"
as follows:
</t>
<t>
Withdrawn route: a route included in the WITHDRAW ROUTES field of
an UPDATE message.
</t>
<t>
Regardless of whether or not this definition is included, Section 3.1
should be changed from:
</t>
<t>
There are three methods by which a given BGP speaker can indicate
that a route has been withdrawn from service:
</t>
<t>
to:
</t>
<t>
There are three methods by which a given BGP speaker can indicate
that a route has been removed from service:
</t>
<t>
or:
</t>
<t>
There are three methods by which a given BGP speaker can indicate
that a route is now unfeasible:
</t>
<t>
After some further off-list discussion, mrr agreed that this inconsistency
is extremely minor, and withdrew his comment. feasible and unfeasible
route will be defined in the "commonly used terms" section to clear
up any confusion.
</t>
</section>
<section anchor="Clarify Outbound Route Text" title="Clarify Outbound Route Text">
<t>
Status: Consensus
<vspace />
Change: No
<vspace />
Summary: Consensus that the issue was sufficiently minor to leave things
alone.
</t>
<t>
Discussion:
</t>
<t>
4. P. 50, line, "If a route in Loc-RIB is excluded from a particular
Adj-RIB-Out the previously advertised route in that Adj-RIB-Out must be
withdrawn from service by means of an UPDATE message (see 9.2)."
</t>
<t>
Would like to rephrase the sentence for clarity,
"If a route in Loc-RIB is excluded from a particular Adj-RIB-Out and was
previously advertised via Adj-RIB-Out, it must be withdrawn from service by
means of an UPDATE message (see 9.2)."
</t>
<t>
One comment suggested either leave it alone, or remove "via Adj-RIB-Out".
</t>
<t>
The original commenter withdrew the comment.
</t>
</section>
<section anchor="Redundant Sentence Fragments" title="Redundant Sentence Fragments">
<t>
Status: Consensus
<vspace />
Change: Yes
<vspace />
Summary: Fix typo & parentheses.
</t>
<t>
Discussion:
</t>
<t>
5. P. 50, section 9.1.4, The two fragments of this sentence are redundant
and don't say anything new or simplify the content. Just keep one fragment.
</t>
<t>
"A route describing a smaller set of destinations (a longer prefix) is said
to be more specific than a route describing a larger set of destinations (a
shorted prefix); similarly, a route describing a larger set of destinations
(a shorter prefix) is said to be less specific than a route describing a
smaller set of destinations (a longer prefix)."
</t>
<t>
There was a comment that disagreed, thinking that both "more specific"
and "less specific" need to be defined. And suggested that only the
third and forth parentheses need to be dropped.
</t>
<t>
The original commenter agreed with the parentheses changes.
</t>
<t>
Yakov agreed to drop the third and fourth parentheses in the -18 version.
</t>
<t>
Jonathan replied to this:
</t>
<t>
Disagree, the text if fine the way it is, except you need to change
"shorted" to "shorter".
</t>
<t>
After minimal further discussion, it was decided we are at a consensus
on this issue to fix the typo and drop the third and fourth parentheses.
</t>
</section>
<section anchor="Section 9.2.1.1 - Per Peer vs. Per Router MinRouteAdvertisementInterval" title="Section 9.2.1.1 - Per Peer vs. Per Router MinRouteAdvertisementInterval">
<t>
Status: Consensus
<vspace />
Change: No
<vspace />
Summary: The consensus is that current practice allows for the
MinRouteAdvertisementInterval to be set per peer, so the text should
be kept the same.
</t>
<t>
Discussion:
</t>
<t>
6. P. 52, section 9.2.1.1 Change this sentence for clarity,
"This rate limiting procedure applies on a per-destination basis, although
the value of MinRouteAdvertisementInterval is set on a per BGP peer basis."
</t>
<t>
To This:
"This rate limiting procedure applies on a per-destination basis, although
the value of MinRouteAdvertisementInterval is set on a BGP router (same
value for all peers) basis."
</t>
<t>
There was a comment disagreeing with this proposal.
It was later elaborated on to include that the reason for disagreement was
that the proposed changes changed the protocol and not just a practice
clarification.
Ben responded asking for how this is a protocol change, he saw it as
a clarification. Perhaps there is something deeper that needs to be
clarified?
Again, response to this is that current implementations allow the
MinRouteAdvertisementInterval to be set per-peer, not per-router.
</t>
<t>
Original reviewer conceded the point.
</t>
<t>
There was some additional discussion on this point. Most of it was along
the lines of extracting what was really implemented and supported among
various vendors. The conclusion was the same.
</t>
</section>
<section anchor="Mention FSM Internal Timers" title="Mention FSM Internal Timers">
<t>
Status: Consensus
<vspace />
Change: No
<vspace />
Summary: No discussion on this issue. No text proposed. Perhaps this is
in the FSM section of the draft? Either way, it defaults to consensus
with no change.
</t>
<t>
Discussion:
</t>
<t>
7. P. 61, item 6.4. Although all the BGP protocol interfacing timers are
mentioned, there are a few FSM internal timers mentioned in the spec that
need to be covered here as well.
</t>
<t>
There has been no discussion on this, it now defaults to consensus with
no change.
</t>
</section>
<section anchor="Delete the FSM Section" title="Delete the FSM Section">
<t>
Status: Consensus
<vspace />
Change: No
<vspace />
Summary: There was some confusion on the question: Is the FSM draft going
to be a separate document, or incorporated into the base draft. The
consensus is that it is going to become part of the base draft, so the
FSM section will be kept, and elaborated on.
</t>
<t>
Discussion:
</t>
<t>
8. Since there is going to be an FSM spec, do we need to have FSM
descriptions in this spec. Maybe the FSM section should be delete.
</t>
<t>
There was one response agreeing with this.
One response asking for clarification: Was this a move to remove
section 8. Finite State Machine from the base draft??
The original reviewer said, yes, when Sue's FSM draft becomes a WG
document, we should remove section 8 from the base draft.
Yakov asked that the AD's provide input on this suggestion.
</t>
<t>
Alex responded saying that the FSM draft is going to be part of the base
spec, and not another document once the FSM words are approved.
</t>
</section>
<section anchor="Clarify the NOTIFICATION Section" title="Clarify the NOTIFICATION Section">
<t>
Status: Consensus
<vspace />
Change: Yes
<vspace />
Summary:
Replace:
</t>
<t>
"If a peer sends a NOTIFICATION message, and there is an error in that
message, there is unfortunately no means of reporting this error via
a subsequent NOTIFICATION message."
</t>
<t>
With:
</t>
<t>
If a peer sends a NOTIFICATION message, and the receiver of the
message detects an error in that message, the receiver can not
use a NOTIFICATION message to report this error back to the peer.
</t>
<t>
Discussion:
</t>
<t>
The "NOTIFICATION message error handling" thread proposed:
</t>
<t>
Please change"
"If a peer sends a NOTIFICATION message, and there is an error in that
message, there is unfortunately no means of reporting this error via
a subsequent NOTIFICATION message."
</t>
<t>
To:
"If a peer receives a NOTIFICATION message, and there is an error in that
message, there is unfortunately no means of reporting this error via
a subsequent NOTIFICATION message."
</t>
<t>
This reversal of meaning met with disagreement, and this text was proposed
instead:
</t>
<t>
All errors detected while processing the NOTIFICATION message cannot be
indicated by sending subsequent NOTIFICATION message back to
originating peer, therefore there is no means of reporting NOTIFICATION
message processing errors. Any error, such as an unrecognized
Error Code or Error Subcode, should be noticed, logged locally, and
brought to the attention of the administration of the peer that has
sent the message. The means to do this, however, lies outside the scope
of this document.
</t>
<t>
The original posted agreed with the intent of the respondent's text, thought
it was too wordy, but did not propose alternate text.
</t>
<t>
Yakov replied with this proposed text:
</t>
<t>
If a peer sends a NOTIFICATION message, and the receiver of the
message detects an error in that message, the receiver can not
use a NOTIFICATION message to report this error back to the peer.
</t>
<t>
Two responses liked this new text. Unless there are objections, we'll
consider that a consensus.
</t>
</section>
<section anchor="Section 6.2: OPEN message error handling" title="Section 6.2: OPEN message error handling">
<t>
Status: Consensus
<vspace />
Change: No
<vspace />
Summary: One commenter observed that the spec seems to specify behavior
that doesn't seem to be observed by extant implementations, and suggested
modifications to the spec. They were later reminded that the base
behavior is acceptable, and agreed.
</t>
<t>
Discussion:
</t>
<t>
The "BGP4 draft ; section 6.2" thread began with a discussion of
section 6.2: OPEN message error handling. Specifically:
</t>
<t>
"If one of the optional parameters in the Open message is not recognized,
then the error subcode is set to 'unsupported optional parameters"
</t>
<t>
We have hit on this line when we were testing a BGP connection between
a speaker that supported capability negotiation and a speaker that did
not.
</t>
<t>
The speaker that did not support the negotiation closed down the peering
session using the error clause mentioned above. Sometimes this lead
to the other router to repeat the OPEN message with the Capability optional
parameter; a game that went on for minutes.
</t>
<t>
This router manufacturer stated in a reply to this that :
"One should not close down the connection if an optional parameter
is unrecognized. That would make this parameter basically mandatory.
This is an well known error in the BGP spec. Neither Cisco or Juniper
do this"
</t>
<t>
If this is true it might be good to adapt the text.
</t>
<t>
The response to this quoted RFC2842, Capabilities Advertisement with BGP-4:
</t>
<t>
A BGP speaker determines that its peer doesn't support capabilities
advertisement, if in response to an OPEN message that carries the
Capabilities Optional Parameter, the speaker receives a NOTIFICATION
message with the Error Subcode set to Unsupported Optional Parameter.
In this case the speaker should attempt to re-establish a BGP
connection with the peer without sending to the peer the Capabilities
Optional Parameter.
</t>
<t>
The original poster responded:
</t>
<t>
This section from the Capabilities Advertisement RFC, is indeed
inline with the section 6.2 of the BGP4 specification. For me however
the question remains if most implementations do no simply ignore optional
parameters that are unknown. And if so, if the text stated above reflects
what is implemented by routers that do not have capability advertisement
at all.
</t>
<t>
Yakov replied to this with:
</t>
<t>
RFC2842 assumes that a router (that doesn't implement RFC2842)
would close the BGP session when the router receives an OPEN message
with an unrecognized Optional Parameter. Therefore the text in the
spec should be left unmodified.
</t>
<t>
The original poster, Jonathan, agreed with this. This issue moves to
consensus.
</t>
</section>
<section anchor="Consistent References to BGP Peers/Connections/Sessions" title="Consistent References to BGP Peers/Connections/Sessions">
<t>
Status: Consensus
<vspace />
Change: Yes
<vspace />
Summary: Stick with "BGP Connection" as the consistent term.
</t>
<t>
Discussion:
</t>
<t>
Ben proposed and Yakov responded:
</t>
<t>
> 1. Throughout the document we have various ways of naming the BGP
> peering communication. 1) BGP Session, 2) BGP Peering Session,
</t>
<t>
I'll replace "session" with "connection".
</t>
<t>
> 3) TCP Connection,
</t>
<t>
The spec doesn't name BGP peering communication as "TCP connection";
TCP connection is used to establish BGP connection. So, TCP connection
and BGP connection are two different things.
</t>
<t>
> 4) BGP Connection,
</t>
<t>
The spec is going to use this term (see above).
</t>
<t>
> 5) BGP Peering Connection,
</t>
<t>
I'll replace "BGP peering connection" with "BGP connection".
</t>
<t>
> 6) Connection,
</t>
<t>
The text uses "connection" whenever it is clear from the context
that it refers to "BGP connection" (or "TCP connection").
</t>
<t>
> 7) BGP Speaker Connection.
</t>
<t>
I'll replace "BGP Speaker Connection" with "BGP connection".
</t>
<t>
>
> BGP router: 1) BGP Speaker, 2) speaker, 3)local speaker
</t>
<t>
The term "speaker" is used when it is clear from the context that
we are talking about "BGP speaker".
</t>
<t>
> 2. Change Internal peer to IBGP Peer.
</t>
<t>
IBGP stands for "BGP connection between internal peers". Therefore
the term "IBGP Peer" would mean "BGP connection between internal
peers peer". That doesn't seem appropriate.
</t>
<t>
This issue has had some discussion, and section 3 was referenced, specifically:
</t>
<t>
Refer to Section 3 - Summary of operations which clearly states that " .. a
peer in a different AS is referred to as an external peer, while a peer in
the same AS may be described as an internal peer. Internal BGP and external
BGP are commonly abbreviated IBGP and EBGP"
</t>
<t>
After more discussion it was decided that we should modify a paragraph on
page 4 to read:
</t>
<t>
If a particular AS has multiple BGP speakers and is providing
transit service for other ASs, then care must be taken to ensure
a consistent view of routing within the AS. A consistent view
of the interior routes of the AS is provided by the IGP used
within the AS. For the purpose of this document, it is assumed
that a consistent view of the routes exterior to the AS is
provided by having all BGP speakers within the AS maintain
IBGP with each other. Care must be taken to ensure that the
interior routers have all been updated with transit information
before the BGP speakers announce to other ASs that transit
service is being provided.
</t>
<t>
This change has consensus.
</t>
<t>
> 3. Change External peer to EBGP Peer.
</t>
<t>
Ditto.
</t>
<t>
Alex responded that having explicit definitions would be nice. This
ties into the general glossary suggestion (see issues 16, 34 & 36).
</t>
<t>
He also suggested that:
</t>
<t>
"BGP session" which works over a "TCP connection" would be closer to the
terminology we're actually using now and would avoid possible confusions
when people read terms like "Connection collision")
</t>
<t>
This was discussed in the "Generial Editorial Comment" thread.
</t>
<t>
After some further discussion, it was decided that, due to existing
implementations, we should go with "BGP connection" as the consistent
term. We are at consensus.
</t>
</section>
<section anchor="FSM Connection Collision Detection" title="FSM Connection Collision Detection">
<t>
Status: Consensus
<vspace />
Change: Yes
<vspace />
Summary: Add this to section 8:
</t>
<t>
There is one FSM per connection. Prior to determining what peer a
connection is associated with there may be two connections for a
given peer. There should be no more than one connection per peer.
The collision detection identifies the case where there is more
than one connection per peer and provides guidance for which
connection to get rid of. When this occurs, the corresponding FSM
for the connection that is closed should be disposed of.
</t>
<t>
Discussion:
</t>
<t>
The original reviewer (Tom) commented that the base draft, FSM section, could
use some clarification around the area of connection collision detection.
Specifically, he argued that it seems like there are actually 2 FSM's
depending on which one backs off in the case of a collision. He
proposed this text to clear things up:
</t>
<t>
"8 BGP Finite State Machine
</t>
<t>
This section specifies BGP operation - between a BGP speaker and its
peer over a single TCP connection - in terms of a Finite State Machine
(FSM). Following is a brief summary ... "(as before)
</t>
<t>
Instead of just
</t>
<t>
"This section specifies BGP operation in terms of a Finite State
Machine (FSM). Following is a brief summary ... "(as before).
</t>
<t>
Curtis responded:
</t>
<t>
There is one FSM per connection. Prior to determining what peer a
connection is associated with there may be two connections for a
given peer. There should be no more than one connection per peer.
The collision detection identifies the case where there is more
than one connection per peer and provides guidance for which
connection to get rid of. When this occurs, the corresponding FSM
for the connection that is closed should be disposed of.
</t>
<t>
I'm not sure which document containing an FSM we should be reading at
this point, but we could add the above paragraph if we need to
explicitly state that the extra connection and its FSM is disposed of
when a collision is detected.
</t>
<t>
When a TCP accept occurs, a connection is created and an FSM is
created. Prior to the point where the peer associated with the
connection is known the FSM cannot be associated with a peer. The
collision is a transient condition in which the rule of "one BGP
session per peer" is temporarily violated and then corrected.
</t>
<t>
This is discussed in the "FSM but FSM of what?" thread.
</t>
<t>
Sue responded that she would be happy to add Curtis' text to section 8
and solicited any additional comments. There was only one on
capitalization, so this issue is at consensus.
</t>
</section>
<section anchor="FSM - Add Explicit State Change Wording" title="FSM - Add Explicit State Change Wording">
<t>
Status: Consensus
<vspace />
Change: No
<vspace />
Summary: A desire for explicit state change wording was expressed. No
text was proposed. The assumption is that this issue has reached a
happy conclusion.
</t>
<t>
Discussion:
</t>
<t>
The initial reviewer:
</t>
<t>
In most places, the actions taken on the receipt of an event include
what the new state will be or that it remains unchanged. But there
are a significant number of places where this is not done (eg Connect
state events 14, 15, 16). I would like to see consistency, always
specify the new/unchanged state. Else I may be misreading it.
</t>
<t>
There was a response asking for specific text, and offering to take the
discussion private.
</t>
<t>
This is discussed in the "FSM words - state changes" thread.
</t>
<t>
There has been no further discussion on this. The assumption is that
is has reached a happy conclusion privately.
</t>
</section>
<section anchor="Explicitly Define Processing of Incoming Connections" title="Explicitly Define Processing of Incoming Connections">
<t>
Status: Consensus
<vspace />
Change: Yes
<vspace />
Summary: Add text that is at the end of the discussion to section 8.
</t>
<t>
Discussion:
</t>
<t>
Alex suggested we explicitly define:
</t>
<t>
- processing of incoming TCP connections (peer lookup, acceptance,
FSM creation, collision control,)
</t>
<t>
Curtis later proposed this text:
</t>
<t>
BGP must maintain separate FSM for each configured peer. Each BGP
peer paired in a potential connection will attempt to connect to the
other. For the purpose of this discussions, the active or connect
side of a TCP connection (the side sending the first TCP SYN packet)
is called outgoing. The passive or listening side (the sender of
the first SYN ACK) is called the an incoming connection.
</t>
<t>
A BGP implementation must connect to and listen on TCP port 179 for
incoming connections in addition to trying to connect to peers. For
each incoming connection, a state machine must be instantiated.
There exists a period in which the identity of the peer on the other
end of an incoming connection is not known with certainty. During
this time, both an incoming and outgoing connection for the same
peer may exist. This is referred to as a connection collision (see
Section x.x, was 6.8).
</t>
<t>
A BGP implementation will have at most one FSM for each peer plus
one FSM for each incoming TCP connection for which the peer has not
yet been identified. Each FSM corresponds to exactly one TCP
connection.
</t>
<t>
Jonathan pointed out that there was an inaccuracy in the proposed text.
Curtis replied with this:
</t>
<t>
You're correct in that you must have a collision of IP addresses on
the TCP connections and that the BGP Identifier is used only to
resolve which gets dropped.
</t>
<t>
The FSM stays around as long as "BGP Identifier" is not known.
Replace "not known with certainty" with "known but the BGP identifier
is not known" and replace "for the same peer" with "for the same
configured peering".
</t>
<t>
The first paragraph is unchanged:
</t>
<t>
BGP must maintain separate FSM for each configured peer. Each BGP
peer paired in a potential connection will attempt to connect to the
other. For the purpose of this discussions, the active or connect
side of a TCP connection (the side sending the first TCP SYN packet)
is called outgoing. The passive or listening side (the sender of
the first SYN ACK) is called the an incoming connection.
</t>
<t>
The second paragraph becomes:
</t>
<t>
A BGP implementation must connect to and listen on TCP port 179 for
incoming connections in addition to trying to connect to peers.
For each incoming connection, a state machine must be instantiated.
There exists a period in which the identity of the peer on the
other end of an incoming connection is known but the BGP identifier
is not known. During this time, both an incoming and outgoing
connection for the same configured peering may exist. This is
referred to as a connection collision (see Section x.x, was 6.8).
</t>
<t>
The next paragraph then needs to get fixed. Changed "for each peer"
to "for each configured peering".
</t>
<t>
A BGP implementation will have at most one FSM for each configured
peering plus one FSM for each incoming TCP connection for which the
peer has not yet been identified. Each FSM corresponds to exactly
one TCP connection.
</t>
<t>
Add a paragraph to further clarify the point you made.
</t>
<t>
There may be more than one connection between a pair of peers if
the connections are configured to use a different pair of IP
addresses. This is referred to as multiple "configured peerings"
to the same peer.
</t>
<t>
> So multiple simultaneous BGP connection are allowed between the same two
> peers, and this behavior is implemented, for example to do load balancing.
</t>
<t>
Good point.
</t>
<t>
I hope the corrections above cover your (entirely valid) objections.
If you see any more errors please let me know.
</t>
<t>
Tom replied that:
</t>
<t>
I take issue with the 'will attempt to connect' which goes too far.
</t>
<t>
The FSM defines events 4 and 5, 'with passive Transport
establishment', so the system may wait and not attempt to connect.
The exit from this state is either the receipt of an incoming TCP
connection (SYN) or timer expiry.
</t>
<t>
So we may have a FSM attempting to transport connect for a given
source/destination IP pair or we may have an FSM not attempting to
connect. (In the latter case, I do not think we can get a collision).
In the latter case, an incoming connection should not generate an
additional FSM.
</t>
<t>
I do not believe the concept of active and passive is helpful since a
given system can flip from one to the other and it does not help us to
clarify the number of FSM involved..
</t>
<t>
And Curtis suggested that:
</t>
<t>
Could this be corrected by replacing "will attempt to connect" with
"unless configured to remain in the idle state, or configured to
remain passive, will attempt to connect". We could also shorten that
to "will attempt to connect unless configured otherwise".
</t>
<t>
Clarification (perhaps an item for a glossary entry):
The terms active and passive have been in our vocabulary for almost
a decade and have proven useful. The words active and passive have
slightly different meanings applied to a TCP connection or applied
to a peer. There is only one active side and one passive side to
any one TCP connection as per the definition below. When a BGP
speaker is configured passive it will never attempt to connect. If
a BGP speaker is configured active it may end up on either the
active or passive side of the connection that eventually gets
established. Once the TCP connection is completed, it doesn't
matter which end was active and which end was passive and the only
difference is which side of the TCP connection has port number 179.
</t>
<t>
Tom agreed with Curtis, that he liked the "will attempt to connect unless
configured otherwise" verbiage.
</t>
<t>
This was discussed in the "Generial Editorial Comment" thread.
</t>
<t>
Sue proposed we add the text above in section 8.2. It is summarized here
for clarity:
</t>
<t>
8.2) Description of FSM
</t>
<t>
8.2.1) FSM connections
</t>
<t>
(text below)
</t>
<t>
8.2.2) FSM Definition
</t>
<t>
(text now in 8.2)
</t>
<t>
"BGP must maintain a separate FSM for each configured peer plus
Each BGP peer paired in a potential connection unless configured
to remain in the idle state, or configured to remain passive,
will attempt to to connect to the other. For the purpose of
this discussion, the active or connect side of the TCP
connection (the side of a TCP connection (the side sending
the first TCP SYN packet) is called outgoing. The passive or
listening side (the sender of the first SYN ACK) is called
an incoming connection. [See section on the terms active and
passive below.]
</t>
<t>
A BGP implementation must connect to and listen on TCP port 179
for incoming connections in addition to trying to connect to peers.
Fro each incoming connection, a state machine must be instantiated.
There exists a period in which the identity of the peer on the
other end of an incoming connection is known but the BGP identifier
is not known. During this time, both an incoming and an outgoing
connection for the same configured peering may exist. This
is referred to as a connection collision (see Section x.x, was 6.8).
</t>
<t>
A BGP implementation will have at most one FSM for each configured
peering plus one FSM for each incoming TCP connection for which the
peer has not yet been identified. Each FSM corresponds to exactly
one TCP connection.
</t>
<t>
There may be more than one connections between a pair of peers if
the connections are configured to use a different pair of IP
addresses. This is referred to as multiple "configured peerings"
to the same peer.
</t>
<t>
8.2.1.1) Terms "active" and "passive"
</t>
<t>
The terms active and passive have been in our vocabulary for
almost a decade and have proven useful. The words active and
passive have slightly different meanings applied to a TCP
connection or applied to a peer. There is only one active
side and one passive side to any one TCP connection per the
definition above [and the state machine below.] When a
BGP speaker is configured active it may end up on either the
active or passive side of the connection that eventually gets
established. Once the TCP connection is completed, it doesn't
matter which end was active and which end was passive and
the only difference is which side of the TCP connection has
port number 179.
</t>
<t>
For additional text, see issue 46.
</t>
<t>
Sue solicited additional comments, the only one was on capitalization, so it
would appear we are at consensus with this issue.
</t>
</section>
<section anchor="Explicitly Define Event Generation" title="Explicitly Define Event Generation">
<t>
Status: Consensus
<vspace />
Change: No
<vspace />
Summary: Suggested that we explicitly define BGP message processing. No text
proposed. There has been no further discussion on this issue, it
is assumed that the consensus is that things are ok the way they are.
</t>
<t>
Discussion:
</t>
<t>
Alex suggested we explicitly define:
</t>
<t>
- generation of events while processing BGP messages, i.e.,
the text describing message processing should say where
needed that a specific event for the BGP session should
be generated.
</t>
<t>
No text was proposed.
</t>
<t>
This discussion has received no further comment. Unless someone wants
to reopen it, it is assumed it has reached a happy ending.
</t>
<t>
This was discussed in the "Generial Editorial Comment" thread.
</t>
</section>
<section anchor="FSM Timers" title="FSM Timers">
<t>
Status: Consensus
<vspace />
Change: No
<vspace />
Summary: Discussion tabled, because new document version rendered the
discussion moot.
</t>
<t>
Discussion:
</t>
<t>
This discussion began with a suggestion that the timers currently in the
FSM:
</t>
<t>
In the 26 Aug text, I find the timer terminology still confusing.
Timers can, I find,
stop
start
restart
clear
set
reset
expire
</t>
<t>
Can be cleaned up and simplified to:
</t>
<t>
start with initial value (spell it out just to be sure)
stop
expire
</t>
<t>
A response to this proposal was, that the existing set is clear, and that
the proposed set is insufficiently rich to describe a concept like "reset"
which encompasses: "Stop the timer, and reset it to its initial value."
</t>
<t>
This discussion reached an impasse, when Sue pointed out that the text
had been updated, and to please review the new text.
</t>
<t>
This was discussed in the "FSM more words" thread.
</t>
</section>
<section anchor="FSM ConnectRetryCnt" title="FSM ConnectRetryCnt">
<t>
Status: Consensus
<vspace />
Change: No
<vspace />
Summary: Discussion tabled, because new document version rendered the
discussion moot.
</t>
<t>
Discussion:
</t>
<t>
This started with the observation that the ConnectRetryCnt "seems to
have lost its purpose." It was suggested that this be made a
Session Attribute, along with: OpenDelayTimer and DelayOpenFlag.
</t>
<t>
Curtis explained that the current purpose of the ConnectRetryCnt is
something to be read by the MIB. He also advocated against adding
the additional Session Attributes.
</t>
</section>
<section anchor="Section 3: Keeping routes in Adj-RIB-In" title="Section 3: Keeping routes in Adj-RIB-In">
<t>
Status: Consensus
<vspace />
Change: Yes
<vspace />
Summary:
Add:
To allow local policy changes to have the correct effect without
resetting any BGP connections, a BGP speaker SHOULD either
(a) retain the current version of the routes advertised to it
by all of its peers for the duration of the connection, or (b)
make use of the Route Refresh extension [12].
</t>
<t>
Discussion:
</t>
<t>
This thread started with a question about why we should retain routes in
the Adj-RIB-In, and how it relates to the Route Refresh extension.
</t>
<t>
mrr proposed this text:
</t>
<t>
... Therefore, a BGP speaker must either retain the current version of
the routes advertised by all of its peers for the duration of the
connection, or make use of the Route Refresh extension [12]. This
is necessary to allow local policy changes to have the correct effect
without requiring the reset of any peering sessions.
</t>
<t>
If the implementation decides not to retain the current version of
the routes that have been received from a peer, then Route Refresh
messages should be sent whenever there is a change to local policy.
</t>
<t>
Yakov later suggested this text, with a slight rewording:
</t>
<t>
To allow local policy changes to have the correct effect without
resetting any BGP connections, a BGP speaker SHOULD either
(a) retain the current version of the routes advertised to it
by all of its peers for the duration of the connection, or (b)
make use of the Route Refresh extension [12].
</t>
<t>
mrr responded that he was fine with Yakov's suggestions.
</t>
<t>
This was discussed in the "Proxy: comments on section 3" thread.
</t>
</section>
<section anchor="Section 4.3 - Routes v. Destinations - Advertise" title="Section 4.3 - Routes v. Destinations - Advertise">
<t>
Status: Consensus
<vspace />
Change: No
<vspace />
Summary: The text that has reached consensus in issue 54 also addresses
this issue.
</t>
<t>
Discussion:
</t>
<t>
This issue arose out of this question to the list:
</t>
<t>
Since:
</t>
<t>
"For the purpose of this protocol, a route is defined as a unit of
information that pairs a set of destinations with the attributes of a
path to those destinations. The set of destinations are the systems
whose IP addresses are reported in the Network Layer Reachability
Information (NLRI) field and the path is the information reported in the
path attributes field of the same UPDATE message."
</t>
<t>
When I read section 4.3:
</t>
<t>
"An UPDATE message is used to advertise feasible routes sharing common
path attribute to a peer, or to withdraw multiple unfeasible routes
from service (see 3.1)."
</t>
<t>
Shouldn't the text read "... advertise feasible [prefixes |
destinations] sharing common path attribute(S)to a peer ...", because:
</t>
<t>
1) A route is defined as quoted above from section 3.1?
</t>
<t>
or since ...
</t>
<t>
"An UPDATE message can advertise at most one set of path attributes, but
multiple destinations ..."
</t>
<t>
2) make "routes" in the original singular.
</t>
<t>
This was discussed in the "Review Comments: Section 4.3: "routes" vs.
destinations - advertise" thread.
</t>
<t>
The text that has reached consensus in issue 54 also addresses this issue.
</t>
</section>
<section anchor="Section 4.3 - Routes v. Destinations - Withdraw" title="Section 4.3 - Routes v. Destinations - Withdraw">
<t>
Status: Consensus
<vspace />
Change: Yes
<vspace />
Summary: Change the definition of "route" as it currently stands to:
</t>
<t>
For the purpose of this protocol, a route is defined as a unit
of information that pairs a set of destinations with the attributes
of a path to those destinations. The set of destinations are
systems whose IP addresses are contained in one IP address prefix
carried in the Network Layer Reachability Information (NLRI)
field of an UPDATE message and the path is the information
reported in the path attributes field of the same UPDATE message.
</t>
<t>
Multiple routes that have the same path attributes can be
advertised in a single UPDATE message by including multiple
prefixes in the NLRI field of the UPDATE message.
</t>
<t>
Discussion:
</t>
<t>
This issue was brought up with this question:
</t>
<t>
When I read these two paragraphs at the end of section 4.3:
</t>
<t>
"An UPDATE message can list multiple routes to be withdrawn from
service. Each such route is identified by its destination (expressed as
an IP prefix), which unambiguously identifies the route in the context
of the BGP speaker - BGP speaker connection to which it has been
previously advertised.
</t>
<t>
An UPDATE message might advertise only routes to be withdrawn from
service, in which case it will not include path attributes or Network
Layer Reachability Information. Conversely, it may advertise only a
feasible route, in which case the WITHDRAWN ROUTES field need not be
present."
</t>
<t>
It reads as if one must withdraw the _set of destinations_ advertised
with the route instead of just one or more destinations since route is
defined in section 3.1 as:
</t>
<t>
"For the purpose of this protocol, a route is defined as a unit of
information that pairs a set of destinations with the attributes of a
path to those destinations. The set of destinations are the systems
whose IP addresses are reported in the Network Layer Reachability
Information (NLRI) field and the path is the information reported in the
path attributes field of the same UPDATE message."
</t>
<t>
Shouldn't the text change "routes" to destinations, or to prefixes?
</t>
<t>
The original commenter added this clarification later:
</t>
<t>
I meant to say, the *same* set of destinations as those advertised
initially. For example, NLRI with dest-a, dest-b and dest-c with the
same attributes is a "route". The withdrawal of the "route" can be read
as one must withdraw all destinations originally advertised for that
route (dest-a, dest-b, dest-c) as a unit.
</t>
<t>
A first time reader could be left wondering if the above must be the
case, or it is valid for an implementation to withdraw just one of these
destinations (e.g. dest-b), leaving the others (dest-a, dest-c)
reachable with their attributes intact.
</t>
<t>
If there is no relationship between destinations when advertised as a
set of destinations in a route and those destinations that can be
withdrawn should be explicitly stated. Otherwise, the draft should call
out that it is not legal to withdraw one prefix only in the set of
prefixes advertised as previously as route.
</t>
<t>
Matt suggested that since the definition seems to cause some confusion,
that we update the definition to:
</t>
<t>
"For the purpose of this protocol, a route is defined as a unit of
information that pairs a set of destinations with the attributes of a
path to those destinations. The set of destinations are systems whose
IP addresses are reported in one prefix present in the Network Layer
Reachability Information (NLRI) field of an UPDATE and the path is the
information reported in the path attributes field of the same UPDATE
message.
</t>
<t>
This definition allows multiple routes to be advertised in a single
UPDATE message by including multiple prefixes in the NLRI field of
the UPDATE. All such prefixes must be associated with the same set
of path attributes."
</t>
<t>
Yakov suggested some minor rewording:
</t>
<t>
For the purpose of this protocol, a route is defined as a unit
of information that pairs a set of destinations with the attributes
of a path to those destinations. The set of destinations are
systems whose IP addresses are contained in one IP address prefix
carried in the Network Layer Reachability Information (NLRI)
field of an UPDATE message and the path is the information
reported in the path attributes field of the same UPDATE message.
</t>
<t>
Multiple routes that have the same path attributes can be
advertised in a single UPDATE message by including multiple
prefixes in the NLRI field of the UPDATE message.
</t>
<t>
Both Jeff and Matt responded that they liked this text.
</t>
</section>
<section anchor="Section 4.3 - Description of AS_PATH length" title="Section 4.3 - Description of AS_PATH length">
<t>
Status: Consensus
<vspace />
Change: Yes
<vspace />
Summary:
Replace:
</t>
<t>
Path segment length is a 1-octet long field containing
the number of ASs in the path segment value field.
</t>
<t>
With:
</t>
<t>
Path segment length is a 1-octet long field containing
the number of ASs (not the number of octets) in the path
segment value field.
</t>
<t>
Discussion:
</t>
<t>
This question was raised:
</t>
<t>
Length fields elsewhere in the draft specify the number of bytes that a
variable length field uses. For AS_PATH, length is used as the number
of 2 byte AS numbers. In the interest of not having to check other
sources to be sure, should the description of path segment value:
</t>
<t>
"The path segment value field contains one or more AS numbers, each
encoded as a 2-octets long field."
</t>
<t>
explicitly mention the number of bytes used by the variable length field?
</t>
<t>
Or, make the description of length explicitly mention that it is not the
length of the variable length field as is the case with other length fields?
</t>
<t>
One response to this agreed that some more clarification would be good,
specifically an ASCII art diagram. No diagram was proposed.
</t>
<t>
Yakov proposed this change:
</t>
<t>
How about replacing
</t>
<t>
Path segment length is a 1-octet long field containing
the number of ASs in the path segment value field.
</t>
<t>
with the following
</t>
<t>
Path segment length is a 1-octet long field containing
the number of ASs (but not the number of octets) in the path
segment value field.
</t>
<t>
Jonathan offered this text:
</t>
<t>
How about:
"Path segment length is a 1-octet long field containing
the number of ASs (which is half the number of octets
since each AS is 2 octets) in the path segment value
field (also note that the path may contain more than 1
segment).
</t>
<t>
Jeff replied that he preferred Yakov's text, but without the "but". Yakov
agreed to that. Andrew also agreed, and asked if there were any objections
to moving this issue into consensus. There were no objections.
</t>
</section>
<section anchor="Section 6 - BGP Error Handling" title="Section 6 - BGP Error Handling">
<t>
Status: Consensus
<vspace />
Change: Yes
<vspace />
Summary: There are a variety of updates to the text that are best described
in the discussion section.
</t>
<t>
Discussion:
</t>
<t>
This discussion began with some suggestions on ways to clarify the text
in section 6 dealing with error handling. The original comments, and
Yakov's response are below:
</t>
<t>
> At the beginning of Section 6. BGP Error Handling:
<vspace />
>
<vspace />
>
<vspace />
> "When any of the conditions described here are detected, a
<vspace />
> NOTIFICATION message with the indicated Error Code, Error Subcode,
<vspace />
> and Data fields is sent, and the BGP connection is closed."
<vspace />
>
<vspace />
> There are several cases where the conditions described in this section
<vspace />
> do not result in the BGP connection being closed. These conditions
<vspace />
> should either state that the connection stays up. Another possibility
<vspace />
> is to remove "and the BGP connection is closed." above, and for each
<vspace />
> listed connection, state what happens to the BGP connection. This
<vspace />
> already takes place for certain conditions, but isn't done consistently.
</t>
<t>
How about replacing the above with the following:
</t>
<t>
When any of the conditions described here are detected, a NOTIFICATION
message with the indicated Error Code, Error Subcode, and Data
fields is sent, and the BGP connection is closed, unless it is
explicitly stated that no NOTIFICATION message is to be sent and
the BGP connection is not to be close.
</t>
<t>
> I tried to list what I found (which may be wrong or incomplete) below:
<vspace />
>
<vspace />
>
<vspace />
> "If the NEXT_HOP attribute is semantically incorrect, the error should
<vspace />
> be logged, and the route should be ignored. In this case, no
<vspace />
> NOTIFICATION message should be sent."
<vspace />
>
<vspace />
> * Append the connection is not closed.
</t>
<t>
Done.
</t>
<t>
>
<vspace />
> "(a) discard new address prefixes from the neighbor, or (b) terminate
<vspace />
> the BGP peering with the neighbor."
<vspace />
>
<vspace />
> * Append "the connection is not closed" to case (a)
</t>
<t>
added "(while maintaining BGP peering with the neighbor)" to case (a).
</t>
<t>
>
<vspace />
> "If the autonomous system number appears in the AS path the
<vspace />
> route may be stored in the Adj-RIB-In,"
<vspace />
>
<vspace />
> * append and the BGP connection stays up.
<vspace />
>
<vspace />
> "but unless the router is configured to accept routes with its
<vspace />
> own autonomous system in the AS path, the route shall not be
<vspace />
> passed to the BGP Decision Process."
</t>
<t>
I would suggest to move this text to Section 9 (UPDATE message handling),
as receiving a route with your own AS in the AS path isn't really
an error. It is just that usually (but not always) you can't put
this route in your Adj-RIB-In.
</t>
<t>
> * Q1) does the BGP connection stay up?
</t>
<t>
yes.
</t>
<t>
> * Q2) what if the router isn't configured to accept routes with its
<vspace />
> own AS in the AS path? One _may_ store the route in Adj-RIB-In, but
<vspace />
> if one doesn't want to?
</t>
<t>
So, don't store them.
</t>
<t>
> Is the BGP connection closed? If so, what subcode?
</t>
<t>
The connection is *not* closed.
</t>
<t>
> "If an optional attribute is recognized, then the value of this
<vspace />
> attribute is checked. If an error is detected, the attribute is
<vspace />
> discarded, and the Error Subcode is set to Optional Attribute Error.
<vspace />
> The Data field contains the attribute (type, length and value)."
<vspace />
>
<vspace />
> * Append and the BGP connection stays up after "the attribute is discarded".
</t>
<t>
Since you have to close the connection, you have to discard all the
routes received via this connection, including the route with the
incorrect attribute. So, there is no need to say that "the attribute
is discarded".
</t>
<t>
There have been no objections to the updates listed above. This issue
seems to have reached a happy ending, so it has been moved into
consensus.
</t>
<t>
This was discussed in the "-17 review Section 6 - BGP Error Handling."
thread.
</t>
</section>
<section anchor="Section 6.2 - Hold timer as Zero" title="Section 6.2 - Hold timer as Zero">
<t>
Status: Consensus
<vspace />
Change: No
<vspace />
Summary: It was suggested that we update the text to say that we MUST
reject hold time values of zero. It was pointed out that this is not
the case and the text should say the way it is.
</t>
<t>
Discussion:
</t>
<t>
In Section 6.2 on OPEN message error handling:
</t>
<t>
If the Hold Time field of the OPEN message is unacceptable, then the
Error Subcode MUST be set to Unacceptable Hold Time. An
implementation MUST reject Hold Time values of one or two seconds.
</t>
<t>
I feel that text similar to:
</t>
<t>
"An implementation MUST also reject Hold Time values of zero received
from a peer in a different AS" should be considered for completeness.
</t>
<t>
A number of respondents pointed out that zero hold time is legitimate
under certain circumstances.
</t>
<t>
This was discussed in the "-17 review, Section 6.2 - must reject hold time"
thread.
</t>
</section>
<section anchor="Deprecation of ATOMIC_AGGREGATE" title="Deprecation of ATOMIC_AGGREGATE">
<t>
Status: Consensus
<vspace />
Change: Yes
<vspace />
Summary: For new text, please see the end of the discussion.
</t>
<t>
Discussion:
</t>
<t>
Jeff opened this discussion with:
</t>
<t>
Deprecation of ATOMIC_AGGREGATE:
</t>
<t>
[This is a summary of some discussions from those who have "been there,
done that" during the CIDR deployment period and also comments
from network operators on the NANOG list.]
</t>
<t>
When BGP-4 was originally drafted, the topic of aggregation was new
enough that people didn't exactly know how it would be used.
Additionally, there were some transition issues when aggregated
networks would need to be de-aggregated and re-advertised into
a classful routing mesh such as BGP-3.
</t>
<t>
The ATOMIC_AGGREGATE flag was intended to prevent a route from being
de-aggregated when de-aggregation would introduce routing loops.
Note that de-aggregation in this context specifically means making
a less specific route into one or more more-specific routes.
</t>
<t>
The current BGP draft has two situations where ATOMIC_AGGREGATE
should be appended to a route:
1. When a route's AS_PATH is intentionally truncated, such as what
happens by default on Cisco's, or using the "brief" option on
GateD. Juniper has a similar feature - I'm unsure of the default.
2. When two routes are implicitly aggregated in the LocRib such
that a more specific route is not selected when a less specific
route is from a given peer.
</t>
<t>
Note that this particular feature is not implemented anywhere that
I am aware of.
</t>
<t>
3. There is a third case not covered by the specification: Implicit
aggregation on export - a more specific route is not exported
and only a less specific one is.
</t>
<t>
When network operators were asked about de-aggregation practices,
I received about 40 responses. The majority of these responses confused
de-aggregation with leaking existing more-specific routes that are
used internally rather than explicitly de-aggregating a less-specific route.
</t>
<t>
There were a very few cases of explicit de-aggregation. One form
was done for purposes of dealing with another ISP creating a routing
DoS by advertising IP space that didn't belong to them - leaked more
specifics alleviated the problem in many cases. (Note that this is
a security issue in the routing system.)
</t>
<t>
The second case was de-aggregating routes internally (and sending the
routes via IBGP marked with NO-ADVERTISE) for purposes of traffic
engineering routing internally where a given upstream failed to
provide enough routing information to allow traffic flows to be
optimized based on supplied prefixes.
</t>
<t>
My conclusions to this are:
1. De-aggregation is not a common practice.
2. It is no longer a major concern since classful inter-domain routing
is pretty much gone.
3. The spec doesn't match reality and should be corrected.
</t>
<t>
My suggestions are thus this:
Section 5.1.6 should be updated as follows:
ATOMIC_AGGREGATE is a well-known discretionary attribute. Its
use is deprecated.
</t>
<t>
When a router explicitly aggregates several routes for the purpose of
advertisement to a particular peer, and the AS_PATH of the aggregated
route excludes at least some of the AS numbers present in the AS_PATH
of the routes that are aggregated (usually due to truncation), the
aggregated route, when advertised to the peer, MUST include the
ATOMIC_AGGREGATE attribute.
</t>
<t>
Section 9.1.4 should be updated as follows:
<vspace />
Original text:
If a BGP speaker receives overlapping routes, the Decision Process
MUST consider both routes based on the configured acceptance policy.
If both a less and a more specific route are accepted, then the
Decision Process MUST either install both the less and the more
specific routes or it MUST aggregate the two routes and install the
aggregated route, provided that both routes have the same value of
the NEXT_HOP attribute.
</t>
<t>
If a BGP speaker chooses to aggregate, then it MUST add
ATOMIC_AGGREGATE attribute to the route. A route that carries
ATOMIC_AGGREGATE attribute can not be de-aggregated. That is, the
NLRI of this route can not be made more specific. Forwarding along
such a route does not guarantee that IP packets will actually
traverse only ASs listed in the AS_PATH attribute of the route.
</t>
<t>
Replace with:
</t>
<t>
It is common practice that more specific routes are often
implicitly aggregated by selecting or advertising only a less-specific
route when overlapping routes are present. As such, all routes
SHOULD be treated as if ATOMIC_AGGREGATE is present and not be made
more specific (de-aggregated). De-aggregation may lead to routing
loops.
</t>
<t>
Section 9.2.2 should remain as it is.
</t>
<t>
Implications of not making the above updates:
<vspace />
ATOMIC_AGGREGATE is not implemented as documented. Current operational
practices do not seem to often trigger situations that it was
intended to re-mediate. After all, by the way it is currently documented,
many of the routes in the Internet would likely have ATOMIC_AGGREGATE.
</t>
<t>
The original motivation for this investigation (aside from a few years
of wondering what this portion of the spec *really* meant) was
making sure the MIB is correctly documented. I can do this now,
even if the spec is not corrected by simply noting that the values:
<vspace />
lessSpecificRouteNotSelected(1),
<vspace />
lessSpecificRouteSelected(2)
</t>
<t>
mean:
<vspace />
ATOMIC_AGGREGATE not present
<vspace />
ATOMIC_AGGREGATE present
</t>
<t>
rather than documenting anything about less and more specific routes.
</t>
<t>
The v2MIB can be fixed to just call it what it is since it hasn't
been RFC'ed yet.
</t>
<t>
Lastly, the spec would just be incorrect.
But all said, nothing bad would really come of this.
</t>
<t>
Yakov responded to this, saying that he thought these changes were
reasonable, and unless there were objections, they would be adopted.
</t>
<t>
Ishi strongly agreed with the changes.
</t>
<t>
Curtis stated that:
</t>
<t>
We used to add ATOMIC_AGGREGATE whenever the AS_PATH was truncated
rather than replaced with an AS_SET. It was always purely
informational since no one intentionally deaggregated and reannounced.
</t>
<t>
And suggested that we remove the MUSTs and indicated that this is only
informational.
</t>
<t>
Jeff replied that:
</t>
<t>
The point is that by definition of the attribute, anywhere that policy
is used (and some places where it may not be), ATOMIC_AGGREGATE
*should* be there. Since its not, and it would generally be
everywhere, you just shouldn't de-aggregate.
</t>
<t>
At best, leaving it as a method of informationally signalling truncation
of a AS_PATH is the best we'll get out of it - and it matches
current implementations.
</t>
<t>
Jonathan agreed with Curtis' idea that we should just move ATOMIC_AGGREGATE
to informational.
</t>
<t>
Curtis proposed this text:
</t>
<t>
This existing text is fine:
</t>
<t>
f) ATOMIC_AGGREGATE (Type Code 6)
</t>
<t>
ATOMIC_AGGREGATE is a well-known discretionary attribute of
length 0. Usage of this attribute is described in 5.1.6.
</t>
<t>
This is the existing text that we are considering changing:
</t>
<t>
5.1.6 ATOMIC_AGGREGATE
</t>
<t>
ATOMIC_AGGREGATE is a well-known discretionary attribute.
</t>
<t>
When a router aggregates several routes for the purpose of
advertisement to a particular peer, and the AS_PATH of the aggregated
route excludes at least some of the AS numbers present in the AS_PATH
of the routes that are aggregated, the aggregated route, when
advertised to the peer, MUST include the ATOMIC_AGGREGATE attribute.
</t>
<t>
A BGP speaker that receives a route with the ATOMIC_AGGREGATE
attribute MUST NOT remove the attribute from the route when
propagating it to other speakers.
</t>
<t>
A BGP speaker that receives a route with the ATOMIC_AGGREGATE
attribute MUST NOT make any NLRI of that route more specific (as
defined in 9.1.4) when advertising this route to other BGP speakers.
</t>
<t>
A BGP speaker that receives a route with the ATOMIC_AGGREGATE
attribute needs to be cognizant of the fact that the actual path to
destinations, as specified in the NLRI of the route, while having the
loop-free property, may not be the path specified in the AS_PATH
attribute of the route.
</t>
<t>
Suggested new text:
</t>
<t>
5.1.6 ATOMIC_AGGREGATE
</t>
<t>
ATOMIC_AGGREGATE is a well-known discretionary attribute.
</t>
<t>
When a router aggregates several routes for the purpose of
advertisement to a particular peer, the AS_PATH of the
aggregated route normally includes an AS_SET formed from the set of
AS from which the aggregate was formed. In many cases the network
administrator can determine that the aggregate can safely be
advertised without the AS_SET and not form route loops.
</t>
<t>
If an aggregate excludes at least some of the AS numbers present in
the AS_PATH of the routes that are aggregated as a result of
dropping the AS_SET, the aggregated route, when advertised to the
peer, SHOULD include the ATOMIC_AGGREGATE attribute.
</t>
<t>
A BGP speaker that receives a route with the ATOMIC_AGGREGATE
attribute SHOULD NOT remove the attribute from the route when
propagating it to other speakers.
</t>
<t>
A BGP speaker that receives a route with the ATOMIC_AGGREGATE
attribute MUST NOT make any NLRI of that route more specific (as
defined in 9.1.4) when advertising this route to other BGP speakers.
</t>
<t>
A BGP speaker that receives a route with the ATOMIC_AGGREGATE
attribute needs to be cognizant of the fact that the actual path to
destinations, as specified in the NLRI of the route, while having the
loop-free property, may not be the path specified in the AS_PATH
attribute of the route.
</t>
<t>
Diffs (for reader convenience):
</t>
<t>
@@ -4,13 +4,19 @@
ATOMIC_AGGREGATE is a well-known discretionary attribute.
</t>
<t>
When a router aggregates several routes for the purpose of
<vspace />
- advertisement to a particular peer, and the AS_PATH of the
<vspace />
- aggregated route excludes at least some of the AS numbers
<vspace />
- present in the AS_PATH of the routes that are aggregated,
<vspace />
- the aggregated route, when advertised to the peer, MUST
<vspace />
- include the ATOMIC_AGGREGATE attribute.
<vspace />
+ advertisement to a particular peer, the AS_PATH of the
<vspace />
+ aggregated route normally includes an AS_SET formed from the
<vspace />
+ set of AS from which the aggregate was formed. In many cases
<vspace />
+ the network administrator can determine that the aggregate can
<vspace />
+ safely be advertised without the AS_SET and not form route loops.
<vspace />
+
<vspace />
+ If an aggregate excludes at least some of the AS numbers present
<vspace />
+ in the AS_PATH of the routes that are aggregated as a result of
<vspace />
+ dropping the AS_SET, the aggregated route, when advertised to the
<vspace />
+ peer, SHOULD include the ATOMIC_AGGREGATE attribute.
</t>
<t>
A BGP speaker that receives a route with the ATOMIC_AGGREGATE
<vspace />
- attribute MUST NOT remove the attribute from the route when
<vspace />
+ attribute SHOULD NOT remove the attribute from the route when
<vspace />
+ propagating it to other speakers.
</t>
<t>
A BGP speaker that receives a route with the ATOMIC_AGGREGATE
</t>
<t>
Current text in 9.1.4:
</t>
<t>
If a BGP speaker chooses to aggregate, then it MUST add
ATOMIC_AGGREGATE attribute to the route. A route that carries
ATOMIC_AGGREGATE attribute can not be de-aggregated. That is, the
NLRI of this route can not be made more specific. Forwarding along
such a route does not guarantee that IP packets will actually
traverse only ASs listed in the AS_PATH attribute of the route.
</t>
<t>
Change to:
</t>
<t>
If a BGP speaker chooses to aggregate, then it SHOULD either
include all AS used to form the aggregate in an AS_SET or add the
ATOMIC_AGGREGATE attribute to the route. This attribute is now
primarily informational. With the elimination of IP routing
protocols that do not support classless routing and the elimination
of router and host implementations that do not support classless
routing, there is no longer a need to deaggregate. Routes SHOULD
NOT be de-aggregated. A route that carries ATOMIC_AGGREGATE
attribute in particular MUST NOT be de-aggregated. That is, the NLRI
of this route can not be made more specific. Forwarding along such
a route does not guarantee that IP packets will actually traverse
only ASs listed in the AS_PATH attribute of the route.
</t>
<t>
This text in 9.2.2.2 need not change.
</t>
<t>
ATOMIC_AGGREGATE: If at least one of the routes to be aggregated
has ATOMIC_AGGREGATE path attribute, then the aggregated route
shall have this attribute as well.
</t>
<t>
The appendix need not change:
</t>
<t>
Appendix 1. Comparison with RFC1771
</t>
<t>
[...]
</t>
<t>
Clarifications to the use of the ATOMIC_AGGREGATE attribute.
</t>
<t>
This might be a bit more wordy that is necessary. It does address the
objections to keeping ATOMIC_AGGREGATE by making the MUST into SHOULD,
and explaining that ATOMIC_AGGREGATE is now primarily informational.
</t>
<t>
Yakov was fine with this text.
</t>
<t>
Yakov posted the text that represents the WG consensus:
</t>
<t>
Replace:
</t>
<t>
5.1.6 ATOMIC_AGGREGATE
</t>
<t>
ATOMIC_AGGREGATE is a well-known discretionary attribute.
</t>
<t>
When a router aggregates several routes for the purpose of
advertisement to a particular peer, and the AS_PATH of the aggregated
route excludes at least some of the AS numbers present in the AS_PATH
of the routes that are aggregated, the aggregated route, when
advertised to the peer, MUST include the ATOMIC_AGGREGATE attribute.
</t>
<t>
A BGP speaker that receives a route with the ATOMIC_AGGREGATE
attribute MUST NOT remove the attribute from the route when
propagating it to other speakers.
</t>
<t>
A BGP speaker that receives a route with the ATOMIC_AGGREGATE
attribute MUST NOT make any NLRI of that route more specific (as
defined in 9.1.4) when advertising this route to other BGP speakers.
</t>
<t>
A BGP speaker that receives a route with the ATOMIC_AGGREGATE
attribute needs to be cognizant of the fact that the actual path to
destinations, as specified in the NLRI of the route, while having the
loop-free property, may not be the path specified in the AS_PATH
attribute of the route.
</t>
<t>
with:
</t>
<t>
5.1.6 ATOMIC_AGGREGATE
</t>
<t>
ATOMIC_AGGREGATE is a well-known discretionary attribute.
</t>
<t>
When a router aggregates several routes for the purpose of
advertisement to a particular peer, the AS_PATH of the
aggregated route normally includes an AS_SET formed from the set of
AS from which the aggregate was formed. In many cases the network
administrator can determine that the aggregate can safely be
advertised without the AS_SET and not form route loops.
</t>
<t>
If an aggregate excludes at least some of the AS numbers present in
the AS_PATH of the routes that are aggregated as a result of
dropping the AS_SET, the aggregated route, when advertised to the
peer, SHOULD include the ATOMIC_AGGREGATE attribute.
</t>
<t>
A BGP speaker that receives a route with the ATOMIC_AGGREGATE
attribute SHOULD NOT remove the attribute from the route when
propagating it to other speakers.
</t>
<t>
A BGP speaker that receives a route with the ATOMIC_AGGREGATE
attribute MUST NOT make any NLRI of that route more specific (as
defined in 9.1.4) when advertising this route to other BGP speakers.
</t>
<t>
A BGP speaker that receives a route with the ATOMIC_AGGREGATE
attribute needs to be cognizant of the fact that the actual path to
destinations, as specified in the NLRI of the route, while having the
loop-free property, may not be the path specified in the AS_PATH
attribute of the route.
</t>
<t>
In 9.1.4 replace:
</t>
<t>
If a BGP speaker chooses to aggregate, then it MUST add
ATOMIC_AGGREGATE attribute to the route. A route that carries
ATOMIC_AGGREGATE attribute can not be de-aggregated. That is, the
NLRI of this route can not be made more specific. Forwarding along
such a route does not guarantee that IP packets will actually
traverse only ASs listed in the AS_PATH attribute of the route.
</t>
<t>
with:
</t>
<t>
If a BGP speaker chooses to aggregate, then it SHOULD either
include all AS used to form the aggregate in an AS_SET or add the
ATOMIC_AGGREGATE attribute to the route. This attribute is now
primarily informational. With the elimination of IP routing
protocols that do not support classless routing and the elimination
of router and host implementations that do not support classless
routing, there is no longer a need to deaggregate. Routes SHOULD
NOT be de-aggregated. A route that carries ATOMIC_AGGREGATE
attribute in particular MUST NOT be de-aggregated. That is, the NLRI
of this route can not be made more specific. Forwarding along such
a route does not guarantee that IP packets will actually traverse
only ASs listed in the AS_PATH attribute of the route.
</t>
<t>
This met with agreement. This issue is at consensus.
</t>
</section>
<section anchor="Section 4.3 - Move text" title="Section 4.3 - Move text">
<t>
Status: Consensus
<vspace />
Change: Yes (minimal)
<vspace />
Summary: Update indentation to allow a new "subsection" heading. Otherwise
no change.
</t>
<t>
Discussion:
</t>
<t>
This began with this suggestion:
</t>
<t>
The text about the minimum length, at first look, gives the impression
that it is still part of the NLRI field description and/or the Path
Attributes section. A new "subsection" or heading of some sort would be
helpful in switching context back to the UPDATE message as a whole and
not the path attributes field anymore.
</t>
<t>
Yakov agreed to update the indentation.
</t>
<t>
Jonathan agreed, and suggested this text:
</t>
<t>
" The minimum length of the UPDATE message is 23 octets -- 19 octets
for the fixed header + 2 octets for the Withdrawn Routes Length + 2
octets for the Total Path Attribute Length (the value of Withdrawn
Routes Length is 0 and the value of Total Path Attribute Length is
0)."
</t>
<t>
Should be moved up to just after
</t>
<t>
"... the Total Path Attribute Length field and the
Withdrawn Routes Length field."
</t>
<t>
Yakov responded to this with:
</t>
<t>
Disagree, as "... the Total Path Attribute Length field and the
Withdrawn Routes Length field." explains how to calculate the length
of NLRI field (and therefore is part of the NLRI field description),
while "The minimum length of the UPDATE message is 23 octets...."
has to do with the length of the UPDATE message.
</t>
<t>
Jonathan also suggested:
</t>
<t>
" the value of Withdrawn
Routes Length is 0 and the value of Total Path Attribute Length is
0)."
</t>
<t>
Should be changed to
</t>
<t>
" the min. value of Withdrawn
Routes Length is 0 and the min. value of Total Path Attribute Length is
0)."
</t>
<t>
And Yakov responded with:
</t>
<t>
Disagree, as the text doesn't talk about what is the minimum value
of the Withdrawn Routes Length and Total Path Attribute Length
fields, but talks about the value of these fields in the case of
a min length UPDATE message.
</t>
<t>
After Yakov's response and a posting to the list asking that this be moved
to consensus, there were no objections, so this is moved to consensus.
</t>
<t>
This is discussed in the "Review: Comments: Section 4.3: UPDATE min length"
thread.
</t>
</section>
<section anchor="Section 4.3 - Path Attributes" title="Section 4.3 - Path Attributes">
<t>
Status: Consensus
<vspace />
Change: Yes
<vspace />
Summary: Make this change to clarify path attributes in an UPDATE:
</t>
<t>
To correct the confusion I propose to replace:
</t>
<t>
A variable length sequence of path attributes is present in every UPDATE.
</t>
<t>
with:
</t>
<t>
A variable length sequence of path attributes is present in
every UPDATE message, except for an UPDATE message that carries
only the withdrawn routes.
</t>
<t>
Discussion:
</t>
<t>
This thread began with MikeC pointing out:
</t>
<t>
The top of page 13 says:
</t>
<t>
"A variable length sequence of path attributes is present in every UPDATE."
</t>
<t>
Is this really true, given that later, in the second to last paragraph
of this section (4.3):
</t>
<t>
"An UPDATE message might advertise only routes to be withdrawn from
service, in which case it will not include path attributes or Network
Layer Reachability Information."
</t>
<t>
This could be confusing to a first time reader.
</t>
<t>
The path attribute length is present in every UPDATE, the path attribute
field itself can be left out, both according to the description of the
minimum length of the UPDATE message and (implied?) in the picture of
the UPDATE message at the beginning of section 4.3.
</t>
<t>
This met with one agreement.
</t>
<t>
Yakov then proposed that:
</t>
<t>
To correct the confusion I propose to replace:
</t>
<t>
A variable length sequence of path attributes is present in every UPDATE.
</t>
<t>
with:
</t>
<t>
A variable length sequence of path attributes is present in
every UPDATE message, except for an UPDATE message that carries
only the withdrawn routes.
</t>
<t>
There was one agreement with this proposal.
</t>
<t>
This is discussed in the thread: "Review: Section 4.3 - Path Attributes"
</t>
</section>
<section anchor="Next Hop for Redistributed Routes" title="Next Hop for Redistributed Routes">
<t>
Status: Consensus
<vspace />
Change: Yes
<vspace />
Summary: More clearly specify the behavior of NEXT_HOP modification, for
the text see the end of the discussion.
</t>
<t>
Discussion:
</t>
<t>
Jonathan began this thread with:
</t>
<t>
I propose adding:
</t>
<t>
"When announcing a locally originated route to an internal peer, the BGP
speaker should use as the NEXT_HOP the interface address of the router
through which the announced network is reachable for the speaker; if the
route is directly connected to the speaker, or the interface address of the
router through which the announced network is reachable for the speaker is
the internal peer's address, then the BGP speaker should use for the
NEXT_HOP attribute its own IP address (the address of the interface that is
used to reach the peer)."
</t>
<t>
AFTER
</t>
<t>
"When sending a message to an internal peer, the BGP speaker
should not modify the NEXT_HOP attribute, unless it has been
explicitly configured to announce its own IP address as the
NEXT_HOP."
</t>
<t>
There has been no discussion on this.
</t>
<t>
This is discussed in the "Next hop for redistributed routes" thread.
</t>
<t>
Issue 14 closed in favor of this issue.
</t>
<t>
In response to Yakov's call for input, Michael responded that:
</t>
<t>
Section 5.1.3 explicitly states what to do when originating to an
external peer. #2 covers one hop away, #3 covers more than on hop away.
#1 talks about sending to an iBGP peer, but only when propagating a
route received from an eBGP peer.
</t>
<t>
1) When sending a message to an internal peer, the BGP speaker
should not modify the NEXT_HOP attribute, unless it has been
explicitly configured to announce its own IP address as the
NEXT_HOP.
</t>
<t>
</t>
<t>
Text similar to #2 should be added, in their own bullet items to #1 such
as what was suggested by Jonathan Natale (text is above.)
</t>
<t>
Yakov replied with this:
</t>
<t>
Replace:
</t>
<t>
1) When sending a message to an internal peer, the BGP speaker
should not modify the NEXT_HOP attribute, unless it has been
explicitly configured to announce its own IP address as the
NEXT_HOP.
</t>
<t>
with:
</t>
<t>
1) When sending a message to an internal peer, if the route is
not locally originated the BGP speaker should not modify the
NEXT_HOP attribute, unless it has been explicitly configured to
announce its own IP address as the NEXT_HOP. When announcing a
locally originated route to an internal peer, the BGP speaker
should use as the NEXT_HOP the interface address of the router
through which the announced network is reachable for the speaker;
if the route is directly connected to the speaker, or the interface
address of the router through which the announced network is
reachable for the speaker is the internal peer's address, then
the BGP speaker should use for the NEXT_HOP attribute its own IP
address (the address of the interface that is used to reach the
peer).
</t>
<t>
And stated the change would be made if there were no objections. There
have been no objections, so this is at consensus.
</t>
</section>
<section anchor="Deprecate BGP Authentication Optional Parameter from RFC1771" title="Deprecate BGP Authentication Optional Parameter from RFC1771">
<t>
Status: Consensus
<vspace />
Change: Yes
<vspace />
Summary: We are at consensus, in that we agree that we should deprecate
the BGP Authentication Optional Parameter as described in RFC1771 in
favor of the mechanism described in RFC2385. The textual changes are
listed at the end of the discussion section of this issue.
</t>
<t>
Discussion:
</t>
<t>
This discussion started in issue 21: Authentication Text Update.
</t>
<t>
This topic has come up before (July time frame), but was recently refreshed
in the context of issue 21. It began with some questions to the list
as to who used what sort of authentication mechanisms. From the
responses it was clear that MD5 (RFC2385) was the preferred method.
</t>
<t>
Eric Gray's message helps to flesh this out:
</t>
<t>
The question is not whether MD5 authentication is used,
it is how is it implemented in real BGP implementations or -
more importantly - where is the authentication information
located in the packets sent between two BGP peers? This is
not strictly an implementation issue because authentication
information is located in different places depending on which
version of MD5 authentication is in use.
</t>
<t>
As is generally known, options are not necessarily good.
Currently, between RFC 1771 and RFC 2385, there are two very
distinct ways to accomplish a semantically identical function.
If the mechanism defined in RFC 1771 is not supported by a
number of interoperable implementations, it must be deprecated
per RFC 2026 prior to advancing the specification to Draft
Standard. If it is not implemented and actually in use, it
should be deprecated if for no other reason than to make the
</t>
<t>
To this Yakov responded:
</t>
<t>
To be more precise,
</t>
<t>
In cases in which one or more options or features have not been
demonstrated in at least two interoperable implementations, the
specification may advance to the Draft Standard level only if
those options or features are removed.
</t>
<t>
So, the relevant question is whether we have at least two implementations
that support authentication as described in rfc1771.
</t>
<t>
Folks who implemented authentication, as described in rfc1771,
please speak up.
</t>
<t>
There have been no responses to Yakov's question.
</t>
<t>
There seems to be a consensus that, since it is little used, and since
there are better mechanisms, namely MD5 authentication, we should
deprecate the BGP Authentication Optional Parameter from RFC1771.
</t>
<t>
Ok, after some discussion, this is a list of the text that we are
adding, changing or removing:
</t>
<t>
1) Remove the reference to the authentication optional parameter:
</t>
<t>
I would suggest to remove the following text from the draft:
</t>
<t>
This document defines the following Optional Parameters:
</t>
<t>
a) Authentication Information (Parameter Type 1):
</t>
<t>
</t>
<t>
This optional parameter may be used to authenticate a BGP
peer. The Parameter Value field contains a 1-octet
Authentication Code followed by a variable length
Authentication Data.
</t>
<t>
0 1 2 3 4 5 6 7 8
+-+-+-+-+-+-+-+-+
| Auth. Code |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Authentication Data |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</t>
<t>
</t>
<t>
Authentication Code:
</t>
<t>
This 1-octet unsigned integer indicates the
authentication mechanism being used. Whenever an
authentication mechanism is specified for use within
BGP, three things must be included in the
specification:
</t>
<t>
- the value of the Authentication Code which indicates
use of the mechanism,
- the form and meaning of the Authentication Data, and
- the algorithm for computing values of Marker fields.
</t>
<t>
Note that a separate authentication mechanism may be
used in establishing the transport level connection.
</t>
<t>
Authentication Data:
</t>
<t>
Authentication Data is a variable length field that is
interpreted according to the value of the
Authentication Code field.
</t>
<t>
2) Update the introduction:
</t>
<t>
In section 2 (Introduction), sixth paragraph
</t>
<t>
From:
</t>
<t>
BGP runs over a reliable transport protocol. This eliminates the
need to implement explicit update fragmentation, retransmission,
acknowledgment, and sequencing. Any authentication scheme used by the
transport protocol (e.g., RFC2385 [10]) may be used in addition to
BGP's own authentication mechanisms. The error notification mechanism
used in BGP assumes that the transport protocol supports a "graceful"
close, i.e., that all outstanding data will be delivered before the
connection is closed.
</t>
<t>
To:
</t>
<t>
BGP uses TCP [RFC793] as its transport protocol. This eliminates
the need to implement explicit update fragmentation, retransmission,
acknowledgment, and sequencing. BGP listens on TCP port 179. Any
authentication scheme used by TCP (e.g., RFC2385 [RFC2385]) may be
used. The error notification mechanism used in BGP assumes that TCP
supports a "graceful" close, i.e., that all outstanding data will
be delivered before the connection is closed.
</t>
<t>
3) Update the message header format section:
</t>
<t>
From:
</t>
<t>
Marker:
</t>
<t>
This 16-octet field contains a value that the receiver of the
message can predict. If the Type of the message is OPEN, or if
the OPEN message carries no Authentication Information (as an
Optional Parameter), then the Marker must be all ones.
Otherwise, the value of the marker can be predicted by some a
computation specified as part of the authentication mechanism
(which is specified as part of the Authentication Information)
used. The Marker can be used to detect loss of synchronization
between a pair of BGP peers, and to authenticate incoming BGP
messages.
</t>
<t>
To:
</t>
<t>
Marker:
</t>
<t>
This 16-octet field is included for compatibility; it must be
set to all ones.
</t>
<t>
4) Update the Message Header error handling section:
</t>
<t>
In section 6.1 (Message Header error handling), second paragraph
</t>
<t>
From:
</t>
<t>
The expected value of the Marker field of the message header is all
ones if the message type is OPEN. The expected value of the Marker
field for all other types of BGP messages determined based on the
presence of the Authentication Information Optional Parameter in the
BGP OPEN message and the actual authentication mechanism (if the
Authentication Information in the BGP OPEN message is present). If
the Marker field of the message header is not the expected one, then
a synchronization error has occurred and the Error Subcode is set to
Connection Not Synchronized.
</t>
<t>
To:
</t>
<t>
The expected value of the Marker field of the message header is all
ones. If the Marker field of the message header is not as expected,
then a synchronization error has occurred and the Error Subcode is
set to Connection Not Synchronized.
</t>
<t>
5) Remove a paragraph from the OPEN message error handling section
(section 6.2):
</t>
<t>
If the OPEN message carries Authentication Information (as an
Optional Parameter), then the corresponding authentication procedure
is invoked. If the authentication procedure (based on Authentication
Code and Authentication Data) fails, then the Error Subcode is set to
Authentication Failure.
</t>
<t>
6) Update the "Differences from RFC1771 Appendix"
</t>
<t>
Text not listed here
</t>
<t>
7) Fix the hole in the numbering by updating:
</t>
<t>
From:
</t>
<t>
This document defines the following Optional Parameters:
</t>
<t>
a) Authentication Information (Parameter Type 1):
</t>
<t>
To:
</t>
<t>
This document defines the following Optional Parameters:
</t>
<t>
a) Optional parameter type 1, Authentication Information,
has been deprecated.
</t>
<t>
We are at consensus with these changes.
</t>
</section>
<section anchor="Clarify MED Removal Text" title="Clarify MED Removal Text">
<t>
Status: Consensus
<vspace />
Change: Yes
<vspace />
Summary: Modify text to clear up MED removal behavior. Text is at the
end of the discussion.
</t>
<t>
Discussion:
</t>
<t>
This discussion began when Jonathan posted a question to the list:
</t>
<t>
In reference to:
</t>
<t>
"A BGP speaker MUST IMPLEMENT a mechanism based on local configuration
which allows the MULTI_EXIT_DISC attribute to be removed from a
route"
</t>
<t>
Does anybody know how this can be done in IOS??? Looks like it cannot.
</t>
<t>
Juniper???
</t>
<t>
Other code???
</t>
<t>
Change to "SHOULD"???
</t>
<t>
Enke responded that:
</t>
<t>
As the MED value is treated as zero when the MED attribute is missing,
removing the MED attribute is really equivalent to setting the value to
zero. Based on this logic, one can argue that "MED removal" is supported
by multiple vendors.
</t>
<t>
However, I do see that the current text can be consolidated and cleaned up:
</t>
<t>
------------------------
<vspace />
5.1.4 MULTI_EXIT_DISC
</t>
<t>
...
</t>
<t>
A BGP speaker MUST IMPLEMENT a mechanism based on local configuration
which allows the MULTI_EXIT_DISC attribute to be removed from a
route. This MAY be done prior to determining the degree of preference
of the route and performing route selection (decision process phases
1 and 2).
</t>
<t>
An implementation MAY also (based on local configuration) alter the
value of the MULTI_EXIT_DISC attribute received over an external
link. If it does so, it shall do so prior to determining the degree
of preference of the route and performing route selection (decision
process phases 1 and 2).
</t>
<t>
-------------------------
</t>
<t>
How about this:
</t>
<t>
A BGP speaker MUST implement a mechanism based on local configuration
which allows the value of MULTI_EXIT_DISC attribute of a received route
to be altered. This shall be done prior to determining the degree of
preference of the route and performing route selection (decision process
phases 1 and 2).
</t>
<t>
--------------------------
</t>
<t>
In responding to a question, Enke also added:
</t>
<t>
> Humm. I thought with a missing MED it was preferable to be treated
> as worst not as 0.
</t>
<t>
It was changed a long time ago. Please see the following text in
Sect. 9.1.2.2 of the draft:
</t>
<t>
In the pseudo-code above, MED(n) is a function which returns the
value of route n's MULTI_EXIT_DISC attribute. If route n has no
MULTI_EXIT_DISC attribute, the function returns the lowest
possible MULTI_EXIT_DISC value, i.e. 0.
</t>
<t>
Curtis replied to Enke:
</t>
<t>
If Juniper treats missing MULTI_EXIT_DISC as worst and Cisco has a
knob to treat missing MULTI_EXIT_DISC as worst, then IMHO we should
change the spec to say that MED(n) returns the largest value possible
is MULTI_EXIT_DISC is missing since this has better loop suppression
behavior if the placement of MULTI_EXIT_DISC removal is moved in its
position in the flow from Adj-In-RIB to Loc-RIB to Adj-Rib-Out. In
other words, no matter where the removal takes place, we are loop free
without special rules about comparing EBGP before MED removal and then
IBGP after MED removal. The only argument for MED(n) going to zero
for missing MULTI_EXIT_DISC was that Cisco routers did that (and
change would pose an operational issue if there wasn't a knob to
facilitate the change).
</t>
<t>
Note that when explicitly jamming a MULTI_EXIT_DISC value, such as
zero, the issue of where in the decision process the MULTI_EXIT_DISC
learned from the EBGP peers could still be used becomes a concern
again. Unfortunately these implementation hints are necessary to
remain loop free and so its hard to declare them out of scope, unless
we forbid changing MULTI_EXIT_DISC and just allow it to be removed
(which does not reflect current practice).
</t>
<t>
Curtis also added:
</t>
<t>
The other issue was MED handling. In "5.1.4 MULTI_EXIT_DISC":
</t>
<t>
A BGP speaker MUST IMPLEMENT a mechanism based on local configuration
which allows the MULTI_EXIT_DISC attribute to be removed from a
route. This MAY be done prior to determining the degree of preference
of the route and performing route selection (decision process phases
1 and 2).
</t>
<t>
An implementation MAY also (based on local configuration) alter the
value of the MULTI_EXIT_DISC attribute received over an external
link. If it does so, it shall do so prior to determining the degree
of preference of the route and performing route selection (decision
process phases 1 and 2).
</t>
<t>
This doesn't sufficiently address the issue.
</t>
<t>
The MED step in the decision process is (in 9.1.2.2):
</t>
<t>
c) Remove from consideration routes with less-preferred
MULTI_EXIT_DISC attributes. MULTI_EXIT_DISC is only comparable
between routes learned from the same neighboring AS. Routes which
do not have the MULTI_EXIT_DISC attribute are considered to have
the lowest possible MULTI_EXIT_DISC value.
</t>
<t>
This is also described in the following procedure:
</t>
<t>
for m = all routes still under consideration
<vspace />
for n = all routes still under consideration
<vspace />
if (neighborAS(m) == neighborAS(n)) and (MED(n) < MED(m))
<vspace />
remove route m from consideration
<vspace />
</t>
<t>
In the pseudo-code above, MED(n) is a function which returns the
value of route n's MULTI_EXIT_DISC attribute. If route n has no
MULTI_EXIT_DISC attribute, the function returns the lowest
possible MULTI_EXIT_DISC value, i.e. 0.
</t>
<t>
Similarly, neighborAS(n) is a function which returns the neighbor
AS from which the route was received.
</t>
<t>
The problem is that a route loop can be formed.
</t>
<t>
To avoid the route loop, two suggestions were made (2-3 years ago and
nothing was done). One was to make MED(n) return infinity if there
was no MULTI_EXIT_DISC. The other was to consider MULTI_EXIT_DISC in
the decision process only for the purpose of selecting among the EBGP
peers, then remove MULTI_EXIT_DISC, then use that best route in
comparisons to IBGP learned routes.
</t>
<t>
The statement in 5.1.4 "This MAY be done prior to determining the
degree of preference of the route and performing route selection
(decision process phases 1 and 2)" does not sufficiently address this.
This implies that you MAY also remove after route selection, in which
case field experience indicates you WILL get burned (unless you know
about the caveat above). Initially this came up as an
interoperability issue but later it was proven (in the field) that a
Cisco and another Cisco could form a route loop until Cisco made this
change.
</t>
<t>
Additional wording is needed either in 5.1.4 or in 9.1.2.2. I suggest
we put a forward reference in 5.1.4:
</t>
<t>
[...]. This MAY be done prior to determining the degree of preference
of the route and performing route selection (decision process phases
1 and 2). See section 9.1.2.2 for necessary restricts on this.
</t>
<t>
Then in 9.1.2.2 add a clarification to the neighborAS(n) function and
add to the existing text.
</t>
<t>
Similarly, neighborAS(n) is a function which returns the
neighbor AS from which the route was received. If the route is
learned via IBGP, it is the neighbor AS from which the other
IBGP speaker learned the route, not the internal AS.
</t>
<t>
If a MULTI_EXIT_DISC attribute is removed before redistributing
a route into IBGP, the MULTI_EXIT_DISC attribute may only be
considered in the comparison of EBGP learned routes, them
removed, then the remaining EBGP learned route may be compared
to the remaining IBGP learned routes, without considering the
MULTI_EXIT_DISC attribute for those EBGP learned routes whose
MULTI_EXIT_DISC will be dropped before advertising to IBGP.
Including the MULTI_EXIT_DISC of an EBGP learned route in the
comparison with an IBGP learned route, then dropping the
MULTI_EXIT_DISC and advertising the route has been proven to
cause route loops.
</t>
<t>
The loop is the classic I prefer your and you prefer mine problem. It
occurs when the router is configured to remove MULTI_EXIT_DISC and
advertise out a route so other routers can use IGP cost to select the
best route. If two routers do this, as soon as they hear the route
with no MULTI_EXIT_DISC from the other peer they start forwarding
toward that peer but they continue to advertise to it since others
IBGP peers are expected to select among the MULTI_EXIT_DISC free IBGP
learned routes using the next step in the decision process, IGP cost.
</t>
<t>
In this case, what you want is each router to prefer its own EBGP
route, even though it has a MULTI_EXIT_DISC and the IBGP learned route
from the same neighbor AS has had its MULTI_EXIT_DISC stripped off (or
didn't have one, you can't tell which it is). You then want all of
the IBGP peers with a MULTI_EXIT_DISC free route from that AS, or that
have stripped the MULTI_EXIT_DISC to form one, to advertise them.
Others in the AS will then use IGP cost to further resolve which exit
point to use. It make a difference when the route is the aggregate
route of another major provider. IGP cost yields what ISPs call "hot
potatoe routing" and MED selects among multiple heavily loaded
provider interconnects.
</t>
<t>
[Aside: Having a missing MULTI_EXIT_DISC default to infinity would do
exactly what the ISPs want it to do in the first place and be a lot
easier to explain but we didn't fix that 2-3 years ago when the issue
came up even though we had WG consensus that it was the right thing to
do. The authors didn't act on it at the time (because Cisco didn't do
it that way and the authors preferred to sit on the draft). At this
point we might as well adequately document what we ended up with....
End of soap box. I don't take myself all that seriously so others
shouldn't either. :-)]
</t>
<t>
After some more discussion on this, we have this text:
</t>
<t>
In 5.1.4 replace:
</t>
<t>
An implementation MAY also (based on local configuration) alter the
value of the MULTI_EXIT_DISC attribute received over EBGP.
If it does so, it shall do so prior to determining the degree of
preference of the route and performing route selection (decision
process phases 1 and 2).
</t>
<t>
with:
</t>
<t>
An implementation MAY also (based on local configuration) alter the
value of the MULTI_EXIT_DISC attribute received over EBGP.
This MAY be done prior to determining the degree of preference
of the route and performing route selection (decision process phases
1 and 2). See section 9.1.2.2 for necessary restricts on this.
</t>
<t>
In 9.1.2.2 replace:
</t>
<t>
Similarly, neighborAS(n) is a function which returns the neighbor
AS from which the route was received.
</t>
<t>
with:
</t>
<t>
Similarly, neighborAS(n) is a function which returns the neighbor
AS from which the route was received. If the route is learned
via IBGP, and the other IBGP speaker didn't originate the route,
it is the neighbor AS from which the other IBGP speaker learned
the route. If the route is learned via IBGP, and the other IBGP
speaker originated the route, it is the local AS.
</t>
<t>
If a MULTI_EXIT_DISC attribute is removed before re-advertising
a route into IBGP, the MULTI_EXIT_DISC attribute may only be
considered in the comparison of EBGP learned routes, then
removed, then the remaining EBGP learned route may be compared
to the remaining IBGP learned routes, without considering the
MULTI_EXIT_DISC attribute for those EBGP learned routes whose
MULTI_EXIT_DISC will be dropped before advertising to IBGP.
Including the MULTI_EXIT_DISC of an EBGP learned route in the
comparison with an IBGP learned route, then dropping the
MULTI_EXIT_DISC and advertising the route has been proven to
cause route loops.
</t>
<t>
There have been no objections to this, so we are at consensus.
</t>
</section>
<section anchor="MED for Originated Routes" title="MED for Originated Routes">
<t>
Status: Consensus
<vspace />
Change: No
<vspace />
Summary: The consensus is that there is not need to specify default
values for MED in the base draft.
</t>
<t>
Discussion:
</t>
<t>
This issue began when it was pointed out that we do not specify the
default values for MED in the base draft.
</t>
<t>
There were a variety of responses, but the consensus is that since
this is not relevant for interoperability, this does not need to be
in the base spec.
</t>
</section>
<section anchor="Rules for Aggregating with MED and NEXT_HOP" title="Rules for Aggregating with MED and NEXT_HOP">
<t>
Status: Consensus
<vspace />
Change: Yes
<vspace />
Summary: Clear up the text on aggregating with a MED. See the discussion
for the text.
</t>
<t>
Discussion:
</t>
<t>
There is a proposal to relax this statement:
</t>
<t>
"Routes that have the following attributes shall not be aggregated
unless the corresponding attributes of each route are identical:
MULTI_EXIT_DISC, NEXT_HOP."
</t>
<t>
In his reply to the original mail, Curtis asserted that we should leave
the MED rules alone, but perhaps we could relax the NEXT_HOP statement.
</t>
<t>
This was revisited in the "aggregating with MED and NEXT_HOP" thread.
</t>
<t>
Yakov suggested we replace:
</t>
<t>
Routes that have the following attributes shall not be aggregated
unless the corresponding attributes of each route are identical:
MULTI_EXIT_DISC, NEXT_HOP.
</t>
<t>
If the aggregation occurs as part of the update process, routes with
different NEXT_HOP values can be aggregated when announced through an
external BGP session.
</t>
<t>
Path attributes that have different type codes can not be aggregated
together. Path attributes of the same type code may be aggregated,
according to the following rules:
</t>
<t>
with:
</t>
<t>
Routes that have different MULTI_EXIT_DISC attribute SHALL NOT
be aggregated.
</t>
<t>
Path attributes that have different type codes can not be aggregated
together. Path attributes of the same type code may be aggregated,
according to the following rules:
</t>
<t>
NEXT_HOP: When aggregating routes that have different NEXT_HOP
attribute, the NEXT_HOP attribute of the aggregated route SHALL
identify an interface on the router that performs the aggregation.
</t>
<t>
This met with agreement.
</t>
<t>
Dimitry asked if the "Routes that have different MULTI_EXIT_DESC attribute
SHALL NOT be aggregated." sentence was unnecessary since it should be a
matter of local policy. Jeff replied that it has been mentioned that
removing this stipulation can cause routing loops.
</t>
<t>
We are at consensus with this issue.
</t>
</section>
<section anchor="Complex AS Path Aggregating" title="Complex AS Path Aggregating">
<t>
Status: Consensus
<vspace />
Change: No
<vspace />
Summary: Since we have two implementations of this method, section 6.8 stays
in the specification.
</t>
<t>
Discussion:
</t>
<t>
Jonathan opened this discussion with:
</t>
<t>
The part in the draft about complex AS path aggregation could/should be
deleted. The current draft implies that when aggregating, for example
(1st):
</t>
<t>
1 2 4 3
</t>
<t>
w/
</t>
<t>
3 4 6 5
</t>
<t>
and
</t>
<t>
5 6 7 8
</t>
<t>
then
</t>
<t>
1 2 {3 4 5 6} 7 8
</t>
<t>
...would be OK
</t>
<t>
AFAIK, all implementations aggregate by either: (2nd)putting ONLY the local
AS in the path (and setting the atomic) OR (3rd)by creating 1 giant set and
adding the local AS as a seq.
</t>
<t>
So he proposed we remove this to reflect current code.
</t>
<t>
Jeff replied that there is absolutely nothing wrong with doing complex
aggregation, and there is no reason to remove this from the specification.
</t>
<t>
Yakov responded that:
</t>
<t>
Jonathan is certainly correct that the spec has to reflect current
code. Therefore, unless there are at least two (interoperable)
implementations that implement the algorithm described in "6.8
Complex AS_PATH aggregation", this section has to be removed (this
is irrespective of whether there is something wrong, or nothing
wrong with complex aggregation). With this in mind, if you implement
this algorithm please speak up within a week. If within a week we
wouldn't know that there are at least two implementations the
section will be removed. And likewise, if we hear that there are
at least two implementations, the section will stay.
</t>
<t>
Jeff replied:
</t>
<t>
I am also fine with removing it. I just don't think its necessary,
especially if One Of These Days someone decides that running policy
based on as-adjacencies would be a Nice Thing and fixes their
implementation to support "complex" aggregation of paths.
</t>
<t>
That said, I am aware of no one who implements this.
</t>
<t>
As an aside, in the thread "last thought on complex aggregation" Jeff
supplied:
</t>
<t>
I finally remembered what was bothering me about removing complex
aggregation from the spec.
</t>
<t>
If it is removed, people who do conformance tests and some implementations
may take this to mean "it shall be illegal to have an AS_PATH that
contains a SEQUENCE of a particular type after a SET".
</t>
<t>
This would make a perfectly ok AS_PATH into one that isn't legal, even
if no implementation currently generates it.
</t>
<t>
Jonathan replied that he thought the issue was moot since no one has
implemented this.
</t>
<t>
John replied that, although he is a bit uncomfortable in removing this
from the spec, he doesn't see any harm in doing so.
</t>
<t>
With this in mind, Yakov suggested we consider the issue closed.
</t>
<t>
So we will wait a week from 10/17 to see if anyone chimes in.
</t>
<t>
Siva responded that they have implemented this functionality. So we
need one more...Ben responded that they support this at Marconi as well.
</t>
<t>
So we have two implementations, the section stays in the spec. We are
at consensus with this issue.
</t>
</section>
<section anchor="Counting AS_SET/AS_CONFED_*" title="Counting AS_SET/AS_CONFED_*">
<t>
Status: Consensus
<vspace />
Change: Yes
<vspace />
Summary: Move how AS_CONFED_SET & SEQUENCE affect route selection to the
BGP Confederations document. Update the base draft to reflect this
by changing section 9.1.2.2. Specific text is at the end of the
discussion.
</t>
<t>
Discussion:
</t>
<t>
Jonathan brought up some questions on how current implementations count
AS_SET and AS_CONFED_*
</t>
<t>
There were a variety of responses to this, answering his questions.
Curtis pointed out that this behavior is covered in:
</t>
<t>
That's in 9.1.2.2:
</t>
<t>
a) Remove from consideration all routes which are not tied for
having the smallest number of AS numbers present in their AS_PATH
attributes. Note, that when counting this number, an AS_SET counts
as 1, no matter how many ASs are in the set, and that, if the
implementation supports [13], then AS numbers present in segments
of type AS_CONFED_SEQUENCE or AS_CONFED_SET are not included in
the count of AS numbers present in the AS_PATH.
</t>
<t>
Jonathan replied that this might be at odds with what Juniper does,
although he was unsure, and asked for clarification.
</t>
<t>
This was discussed in the "New Issue AS path" thread.
</t>
<t>
Yakov proposed that:
</t>
<t>
The issue of route selection in the present of confederations
belongs *not* to the base spec, but to the spec that describes
BGP Confeds. With this in mind I would suggest to change in 9.1.2.2 from
</t>
<t>
a) Remove from consideration all routes which are not tied for
having the smallest number of AS numbers present in their AS_PATH
attributes. Note, that when counting this number, an AS_SET counts
as 1, no matter how many ASs are in the set, and that, if the
implementation supports [13], then AS numbers present in segments
of type AS_CONFED_SEQUENCE or AS_CONFED_SET are not included in
the count of AS numbers present in the AS_PATH.
</t>
<t>
to
</t>
<t>
a) Remove from consideration all routes which are not tied for
having the smallest number of AS numbers present in their AS_PATH
attributes. Note, that when counting this number, an AS_SET counts
as 1, no matter how many ASs are in the set.
</t>
<t>
and ask the authors of BGP Confeds to update their document to
cover how the presence of confeds impact route selection.
</t>
<t>
This met with agreement, this issue is at consensus.
</t>
</section>
<section anchor="Outbound Loop Detection" title="Outbound Loop Detection">
<t>
Status: Consensus
<vspace />
Change: No
<vspace />
Summary: The consensus is, that while this may be a useful technique, it
would break existing methods, and is otherwise out-of-scope for the
base draft. It was suggested that this could be addressed in the
update to RFC1772.
</t>
<t>
Discussion:
</t>
<t>
Jonathan brought up that:
</t>
<t>
This paper (thanks Jeff)
http://www.research.microsoft.com/scripts/pubs/view.asp?TR_ID=MSR-TR-2000-08
indicates that it
is better to do the loop detection outbound as well inbound. The current
draft indicates that
it only needs to be done inbound. IOS does it inbound as well as outbound.
GateD/Juniper
does it (did it ???) only inbound.
</t>
<t>
So I propose we add:
"An implementation MAY choose to not advertise routes to EBGP peers if these
routes contain
the AS of that peer in the AS path."
after:
"If the autonomous system number appears in the AS path the route may be
stored in the
Adj-RIB In, but unless the router is configured to accept routes with its
own AS in the
AS path, the route shall not be passed to the BGP Decision Process."
</t>
<t>
*If there is at least one other implementation that does outbound
pruning/loop-detection.*
</t>
<t>
Yakov pointed out that this is ONLY applicable to the base draft if there
are multiple implementations doing this. This issue will only be
considered if these implementors come forward by 10/25/02. Otherwise
the issue will be considered closed.
</t>
<t>
Jeff replied that there was more at stake with this than if people had
implemented it:
</t>
<t>
My suggestion is that this can stay out of the base draft. While it
is true that this speeds up convergence (per the paper), it doesn't
affect interoperability.
</t>
<t>
.in 4
Also, adding this specifically removes the ability from several
implementations to be able to bridge a partitioned AS by permitting
loops. (I'm not going to argue whether this is a Good way to do
this, just that its done.)
</t>
<t>
Its also worth noting that one could produce the same resultant speed-up
by detecting the loop on an outbound basis and *not* applying the
min*timers to the UPDATE. Thus, this would be a case of an advertisement
of NLRI being treated the same, timer-wise, as the advertisement of
WD_NLRI.
</t>
<t>
I would suggest moving this suggestion for outbound loop detection
in one form or another to the 1772 replacement.
</t>
<t>
Yakov agreed with this.
</t>
</section>
<section anchor="Appendix A - Other Documents" title="Appendix A - Other Documents">
<t>
Over the course of this discussion, a number of issues have been raised
that the group though would be better dealt with in other documents.
These additional documents, and their concomitant issues will be more
fully addressed when the WG turns its focus to them. These projects are:
</t>
<t>
1) Update RFC 1772: Application of the Border Gateway Protocol in the Internet.
This will probably entail a complete rewrite.
</t>
<t>
2) Update Route Reflector (2796) and Confederation (3065) RFC's regarding their
impact on route selection.
</t>
<t>
3) Write a new document covering BGP Multipath.
.ne 4
</t>
</section>
</section>
<section anchor="The Issues from -18 to -19" title="The Issues from -18 to -19">
<t>
This section lists the issues discussed on the list from November 2002
to late February 2003.
</t>
<section anchor="Reference to RFC 1772" title="Reference to RFC 1772">
<t>
Status: Consensus
<vspace />
Change: No
<vspace />
Summary: Proposed changing RFC 1772 reference, since that document should
be updated.
</t>
<t>
Discussion:
</t>
<t>
Jeff proposed that we reconsider referencing RFC 1772, since that document
should be updated.
</t>
<t>
Yakov pointed out that this is a non-normative reference and can just be
left as is.
</t>
<t>
Jeff agreed that this wasn't a big deal. We are at consensus to leave
things as they are.
</t>
<t>
This was discussed in the "-18 last call comments" thread.
</t>
</section>
<section anchor="MUST/SHOULD Capitalization" title="MUST/SHOULD Capitalization">
<t>
Status: Consensus
<vspace />
Change: Yes
<vspace />
Summary: Capitalize MUST/SHOULD where appropriate.
</t>
<t>
Discussion:
</t>
<t>
Jeff brought this up, and Yakov responded asking that he point out
specific instances where this is needed. Jeff said he would do so,
given some time.
</t>
<t>
Yakov later replied that this would be fixed in the -19 version.
</t>
<t>
Jeff replied with a master diff showing the MUST/SHOULDs, for the entire
document please see the beginning of the thread entitled:
"Issues list, #2: MUST/SHOULD Capitalization"
</t>
<t>
This was discussed in the "18 last call comments" thread.
This was also brought up in the "proxy: comments on draft -18" thread.
</t>
</section>
<section anchor="Fix Update Error Subcode 7 -- accidently removed" title="Fix Update Error Subcode 7 -- accidently removed">
<t>
Status: Consensus
<vspace />
Change: Yes
<vspace />
Summary: Add error subcode 7 back in, it looks like it was inadvertently
removed. Add deprecation text to Open Message Error subcode 5.
</t>
<t>
Discussion:
</t>
<t>
Jeff supplied:
</t>
<t>
Update message error subcode 7 is removed. Especially in -18,
it looks like an editing mistake based on where it would fall
in the editing..
</t>
<t>
Yakov mentioned that this is addressed in Appendix A.
</t>
<t>
Jeff replied:
</t>
<t>
.in 4
What I would like to see is something like this:
</t>
<t>
6 - Invalid ORIGIN Attribute
7 - [Deprecated - See Appendix A]
8 - Invalid NEXT_HOP Attribute
</t>
<t>
As it stands, 7 lies on a page boundary and looks like it got clipped
by the roff.
</t>
<t>
Yakov agreed, and also said he would add similar text for Open Message
Error subcode 5.
</t>
<t>
This was discussed in the "18 last call comments" thread.
</t>
</section>
<section anchor="Section 5.1.4 - Editorial Comment" title="Section 5.1.4 - Editorial Comment">
<t>
Status: Consensus
<vspace />
Change: Yes
<vspace />
Summary: Fix "restricts" to "RESTRICTIONS"
</t>
<t>
Discussion:
</t>
<t>
Jeff proposed an editorial fix. This is agreed to.
</t>
<t>
This was discussed in the "-18 last call comments" thread.
</t>
</section>
<section anchor='Section 9.1 - Change "all peers" to "peers"' title='Section 9.1 - Change "all peers" to "peers"'>
<t>
Status: Consensus
<vspace />
Change: Yes
<vspace />
Summary: Section 9.1 - Change "all peers" to "peers"
</t>
<t>
Discussion:
</t>
<t>
Jeff proposed:
</t>
<t>
.in 4
9.1:
The output of the Decision Process is the set of routes that will be
advertised to (delete all) peers; the selected routes will be stored
in the local speaker's Adj-RIB-Out according to policy.
</t>
<t>
The previous wording implied that routes in the LocRib MUST be placed
in the adj-rib-out.
</t>
<t>
Yakov agreed, this fix will be in the next revision.
</t>
<t>
This was discussed in the "-18 last call comments" thread.
</t>
</section>
<section anchor="AS Loop Detection & Implicit Withdraws" title="AS Loop Detection & Implicit Withdraws">
<t>
Status: Consensus
<vspace />
Change: Yes
<vspace />
Summary: Update the text to reflect the AS Loop detection should be done
in the BGP decision process.
</t>
<t>
Discussion:
</t>
<t>
John brought this up, and suggested:
</t>
<t>
.in 4
I have one further comment just in case it's not perfectly obvious to
everyone, which is that "ignore the UPDATE" is not strictly the
action you take when receiving a looped update. Rather, you treat it
as an implicit withdraw, i.e. you process it as any other update but
treat the contained NLRI as unfeasible.
</t>
<t>
I was going to write that this is sufficiently clear from the spec,
but I regret to say that it isn't. Here is the fourth paragraph of
section 9:
</t>
<t>
.in 8
The information carried by the AS_PATH attribute is checked for AS
loops. AS loop detection is done by scanning the full AS path (as
specified in the AS_PATH attribute), and checking that the autonomous
system number of the local system does not appear in the AS path. If
the autonomous system number appears in the AS path the route may be
stored in the Adj-RIB-In, but unless the router is configured to
accept routes with its own autonomous system in the AS path, the
route shall not be passed to the BGP Decision Process. Operations of
a router that is configured to accept routes with its own autonomous
system number in the AS path are outside the scope of this document.
</t>
<t>
.in 4
I don't think this is quite right -- the decision process needs to be
run if the looped routes had previously been advertised feasibly on
the same session. This could be fixed by hacking the quoted
paragraph, but it seems more straightforward to do it by removing the
quoted paragraph and making the fix in 9.1.2 Phase 2 instead. This
could be done by inserting the following between the third and fourth
paragraphs of 9.1.2 Phase 2:
</t>
<t>
.in 8
If the AS_PATH attribute of a BGP route contains an AS loop, the
BGP route should be excluded from the Phase 2 decision function.
AS loop detection is done by scanning the full AS path (as
specified in the AS_PATH attribute), and checking that the autonomous
system number of the local system does not appear in the AS path.
Operations of a router that is configured to accept routes with its
own autonomous system number in the AS path are outside the scope of
this document.
</t>
<t>
.in 4
Section 9.3, first bullet, also addresses this topic, but I don't
think it's sufficient.
</t>
<t>
Yakov agreed that this was a change for the better and will include this
in the next revision.
</t>
<t>
We are at consensus on this issue.
</t>
<t>
This is discussed in the "-18 last call comments" thread.
</t>
</section>
<section anchor="Standardize FSM Timer Descriptions" title="Standardize FSM Timer Descriptions">
<t>
Status: Consensus
<vspace />
Change: Yes
<vspace />
Summary: Standardize the state descriptions on those listed in the
discussion section of this issue.
</t>
<t>
Discussion:
</t>
<t>
Tom proposed:
</t>
<t>
.in 4
I think a standard description would serve us better instead of using
the following different ways (which I take all to refer to the same
entity):
</t>
<t>
delayBGP open timer
BGP delay open timer
BGP open delay timer
delay open timer
BGP delay timer
</t>
<t>
.in 4
I suggest Open Delay timer (with those capitals)
</t>
<t>
I believe that the corresponding flag is consistently referred to
(apart from the capitalization) as Delay Open flag
</t>
<t>
Yakov agreed with this suggestion, no one else disagreed, we are at
consensus.
</t>
<t>
This was discussed in the "BGP18-FSM-terminology" thread.
</t>
</section>
<section anchor="FSM MIB enumerations" title="FSM MIB enumerations">
<t>
Status: Consensus
<vspace />
Change: Yes
<vspace />
Summary: Move MIB references from the base spec into the MIB document.
</t>
<t>
Discussion:
</t>
<t>
Tom pointed out that:
</t>
<t>
The FSM makes several references to putting values into MIB objects
and while some of the values are defined, eg FSM error or Hold Timer
expired, I can find no definition of the following in any of the BGP
documents, MIB or otherwise.
</t>
<t>
connect retry expired
TCP disconnect
administrative down
collision detect closure
Call Collision cease
collision detected and dump connection
Administrative stop
</t>
<t>
I believe an implementation needs to be told these values somewhere
and that there should be a reference to that place in bgp18.
</t>
<t>
Jeff replied that to make things easier, the MIB references will be
removed from the base spec, and into the MIB document.
</t>
<t>
This was discussed in the "WG Last Call FSM MIB enumeration" thread,
and the "bgp18 WG Last Call fsm MIB objects" thread.
</t>
</section>
<section anchor='Make "delete routes" language consistent' title='Make "delete routes" language consistent'>
<t>
Status: Consensus
<vspace />
Change: Yes
<vspace />
Summary: Replace a variety of wording with "deletes all routes associated
with this connection,".
</t>
<t>
Discussion:
</t>
<t>
Tom pointed out that we use a variety of language to say how we are
going to delete routes in the FSM. He proposed that we instead use:
</t>
<t>
- deletes all routes associated with this connection,
</t>
<t>
This met with agreement, and will be reflected in the next version.
</t>
<t>
This was discussed in the "bgp18 WG Last Call fsm delete action" thread.
</t>
</section>
<section anchor="Correct OpenSent and OpenConfirm delete wording" title="Correct OpenSent and OpenConfirm delete wording">
<t>
Status: Consensus
<vspace />
Change: Yes
<vspace />
Summary: Remove delete wording from OpenSent and OpenConfirm states.
</t>
<t>
Discussion:
</t>
<t>
Venu asked why there was delete wording in the OpenSent and OpenConfirm
states when a BGP speaker cannot receive routes in these states.
</t>
<t>
Jeff acknowledged that this was an error. Yakov agreed to fix the
next version.
</t>
<t>
This was discussed in the "bgp18 WG Last Call fsm delete action" thread.
</t>
</section>
<section anchor="Incorrect next state when the delay open timer expires" title="Incorrect next state when the delay open timer expires">
<t>
Status: Consensus
<vspace />
Change: Yes
<vspace />
Summary: Fix the next state.
</t>
<t>
Discussion:
</t>
<t>
Tom pointed out that:
</t>
<t>
I believe that there is an incorrect next state when the delay open
timer expires [event 12] in the Active state. The next state should
be OpenSent and not OpenConfirm.
</t>
<t>
OpenConfirm is for KeepAlive processing when Open messages have been
sent and received.
</t>
<t>
OpenSent is for Open sent and not yet received.
</t>
<t>
The corresponding section in Connect state I believe is correct.
</t>
<t>
Yakov agreed, and will fix this in the next revision.
</t>
<t>
This was discussed in the "bgp18 WG Last Call fsm incorrect next state"
</t>
</section>
<section anchor='Entering OpenConfirm / Adding "Stop OpenDelay" action' title='Entering OpenConfirm / Adding "Stop OpenDelay" action'>
<t>
Status: Consensus
<vspace />
Change: Yes
<vspace />
Summary: Add this text:
</t>
<t>
Change 2 -
Connect state
event 17 (currently defined as going to Active)
event 9 (stays in Connect state)
</t>
<t>
new Text:
</t>
<t>
In response to the connect retry timer expires event [Event
9], the local system:
- drops the TCP connection,
- restarts the connect retry timer,
- stops the Open Delay timer and resets the timer to zero,
- initiates a TCP connection to the other BGP peer,
- continues to listen for a connection that may be
initiated by the remote BGP peer, and
- stays in Connect state.
</t>
<t>
</t>
<t>
If the TCP connection fails [Event17], the local system:
- restarts the connect retry timer,
- stops the Open Delay timer and resets value to zero,
- continues to listen for a connection that may be
initiated by the remote BGP peer, and
- changes its state to Active.
</t>
<t>
Further discussion on Keepalives has been moved to issue 52.
</t>
<t>
Discussion:
</t>
<t>
This discussion began with Tom outlining these two points:
</t>
<t>
When the OpenConfirm state is entered from OpenSent with the receipt
of a valid open [Event 18], then a KeepAlive message is sent and the
timer is started.
</t>
<t>
When the OpenConfirm state is entered from Active or Connect on
receipt of a valid open [Event 19], no message is sent, no timer is
started.
I believe this inconsistency is an error and should be corrected by
adding these two actions in those two places.
</t>
<t>
Sue replied:
</t>
<t>
Just to clarify this comment:
Event 19 = valid open with delay timer running
</t>
<t>
Active = 1) awaiting TCP connection, or
2) TCP connection completed and awaiting the
TCP connection with delay timer running
</t>
<t>
Case 1: - should not see Event 19
In transition from Active to Open Confirm, the connection
must have a TCP connection completed. Case 1 does not
have this occurring, so the transition must be avoided.
</t>
<t>
Case 2: - should see Event 19
</t>
<t>
- Open, Keepalive should be sent.
</t>
<t>
Previous text: (Action H from FSM document)
</t>
<t>
If an Open is received with the BGP Delay Open timer running,
[Event 19], the local system:
- clears the connect retry timer [cleared to zero),
- completes the BGP initialization,
- stop and clears the BGP Open Delay timer,
- Sends an Open Message,
- sets the hold timer to a large value (4 minutes), and
- changes its state to an Open Confirm.
</t>
<t>
New text: [a New Action - N-2 : N + BGP keepalive sent]
</t>
<t>
If an Open is received with the BGP Delay Open Timer running
[Event 19], the local system:
- clear the connect retry timer [cleared to zero],
- completes the BGP initialization,
- stops and clears the BGP Open Delay timer,
- Send an Open message,
- Sends a Keepalive message,
- If hold timer value is non-zero,
- set keepalive timer
- hold timer reset to negotiated value
else if hold timer is zero,
- reset the keepalive timer, and
- reset the hold timer.
</t>
<t>
- If the value of the autonomous system field is the
same as the local Autonomous system number, set
the connection status to a internal connection;
otherwise it is "external".
</t>
<t>
Tom and Sue discussed the OpenDelay state, and recalled that this was
excluded a number of months ago as not reflecting current practice.
</t>
<t>
By way of clarification, Sue added:
</t>
<t>
1) Agree, this can occur in the Active state as well as the
Connect state. Will you accept the earlier text below
to be inserted both places?
</t>
<t>
Background:
</t>
<t>
The state machine for Event 19 is:
</t>
<t>
Idle Connect Active Open Open Estb
Sent Confirm
================================================
Event 19 | | | | | | |
next state |Idle | Open | Open | Open |Idle | Idle |
| | confirm| confirm| Confirm| | |
================================================
action | V | N-2 | N-2 | N | E-1 | E |
================================================
</t>
<t>
Per the State Machine.
</t>
<t>
Action v - FSM Error
Action E - FSM Error, drop connection - etc, drop routes
Action E-1 - FSM Error, drop connection (lots of
Action N-2 (text below)
Action N (text below, without sending Open)
</t>
<t>
2) Do you think that Event 19 is possible in the Open Sent state?
</t>
<t>
Please answer this separately.
</t>
<t>
Tom replied that:
</t>
<t>
.in 4
1) yes I think the same text in both Active and Connect states is a
good resolution
</t>
<t>
2) complicated. As the fsm text stands, Event 19, along with a host
of others, takes us back from Open Sent to Idle (I assume on the
grounds this is an error condition) which seems very reasonable.
</t>
<t>
But ...in quite a few places, such as Connect state events 2,
7,8,9,10,11, 17, 18, 20 thru 27, we do not stop the OpenDelay timer
when going to Idle or Active so we could then go from eg Idle with
Manual start [event 1] to Connect to Open Sent all before the
OpenDelay timer expires in which case event 19 can occur validly in
Open Sent - obscure but possible. (This is also true with Active state
and events 2, 17 and the default list at the end).
</t>
<t>
But I think this is an error, and that when exiting Connect state or
Active state as listed above, we should have an additional action to
stop the OpenDelay timer in which case event 19 in Open Sent becomes
an error condition (again).
</t>
<t>
But but but as ever, I cannot speak with authority for implementations
and so if implementations do not stop the OpenDelay timer when exiting
as above, then Event 19 is valid in Open Sent state - obscure but
possible (again).
</t>
<t>
My wish is to add the extra action, stop OpenDelay timer, for the
events listed above in Active and Connect states in the expectation
that that is what people have or should have implemented.
</t>
<t>
Tom added a response to Sue after some other threads have been discussed:
.in 4
</t>
<t>
You asked if event 19 (Open with OpenDelay timer running) was possible
in OpenSent state; I gave a lengthy reply (below) to the effect yes it
could because the OpenDelay timer did not always get stopped but the
timer should be stopped in which case the event would not happen.
</t>
<t>
Reading your responses to Siva , I see you include stopping the Open
Delay timer in the action 'release all BGP resources' when going to
Idle (which I missed seeing earlier in the year).
</t>
<t>
That eliminates most but not all of the possibilities I mentioned. I
now believe we would need to add the action 'stop OpenDelay timer' for
Connect state
event 17 (currently defined as going to Active)
event 9 (stays in Connect state)
</t>
<t>
in order to stop event 19 in Open Sent
</t>
<t>
Sue replied that, she thought this was at consensus, and provided the
new text, which is:
</t>
<t>
Change 1: new text
</t>
<t>
Active state - event 19
</t>
<t>
If an Open is received with the Open Delay timer is
running [Event 19], the local system
- clears the connect retry timer (cleared to zero),
- stops and clears the Open Delay timer
- completes the BGP initialization,
- stops and clears the Open Delay timer
- sends an OPEN message,
- send a Keepalive message,
- if the hold timer value is non-zero,
- starts the keepalive timer to initial value,
- resets the hold timer to the negotiated value,
else if the hold timer is zero
- resets the keepalive timer (set to zero),
- resets the hold timer to zero.
</t>
<t>
- changes its state to OpenConfirm.
</t>
<t>
If the value of the autonomous system field is the same as the
local Autonomous System number, set the connection status to
an internal connection; otherwise it is "external".
Change 2 -
Connect state
event 17 (currently defined as going to Active)
event 9 (stays in Connect state)
</t>
<t>
new Text:
</t>
<t>
In response to the connect retry timer expires event [Event
9], the local system:
- drops the TCP connection,
- restarts the connect retry timer,
- stops the Open Delay timer and resets the timer to zero,
- initiates a TCP connection to the other BGP peer,
- continues to listen for a connection that may be
initiated by the remote BGP peer, and
- stays in Connect state.
If the TCP connection fails [Event17], the local system:
- restarts the connect retry timer,
- stops the Open Delay timer and resets value to zero,
- continues to listen for a connection that may be
initiated by the remote BGP peer, and
- changes its state to Active.
</t>
<t>
Tom replied that:
</t>
<t>
.in 4
Change 2, stop Open Delay timer in Connect state events 9 and 17,
fine; that is what I understand to be the real issue 12.
</t>
<t>
Change 1, event 19 in Active state, is IMHO issues 47 and 52. This is
tangled because the initial paragraphs of Issue 12 in the issue list
are nothing to to with stopping Open Delay timer and everything to to
with sending a Keepalive message before entering Open Confirm state
from Active or Connect state on event 19; which I raised and see as
issue 52. Issue 47 was Siva's issue 28 and relates to a different
action for Active state event 19.
</t>
<t>
I agree with change 1 in that it adds in the sending of Keepalive
which I believe essential; I think Siva needs to respond concerning
issue 47. (nb the stop Open Delay action is duplicated) I wonder if
we should use a different character for the bullet points under the if
and else clauses to make it clear where they end ie
- if the hold timer ....
+ do this
+ and this
else if ...
+ do the other
+ and this
</t>
<t>
But I still have an issue for Connect state event 19 where I believe,
as for Active state event 19, we should send a Keepalive and start the
Keepalive timer. I will pursue this as part of issue 52 if that suits
you. I think the text will be the same as whatever we agree for
Active state event 19.
</t>
<t>
This was discussed in the "bgp 18 WG Last Call fsm missing keepalive" thread.
And also in the "Event 19 in Open Sent state was Re: bgp18 WG Last Call
fsm missing keepalive" thread. This also came up in the "issues 12 -
consensus & two changes - 2nd message" thread.
</t>
</section>
<section anchor="FSM Missing Next States" title="FSM Missing Next States">
<t>
Status: Consensus
<vspace />
Change: Yes
<vspace />
Summary: Seven sub-issues spawned to resolve each of the next-state
questions. See each sub-issue for specifics.
</t>
<t>
Discussion:
</t>
<t>
This began with Tom pointing out 7 places where the next state was not
clear. Interlaced with his comments below is the proposed text to fix
the problems and the status of the issue.
</t>
<t>
All sub-issues are at consensus.
</t>
<t>
This conversation was started in the "bgp18 WG Last Call fsm missing next
state" thread.
</t>
<section anchor="FSM Missing Next States - Event 15 or 16 (Connect State)" title="FSM Missing Next States - Event 15 or 16 (Connect State)">
<t>
Status: Consensus
<vspace />
Change: Yes
<vspace />
Summary: Add next state of Connect.
</t>
<t>
Discussion:
</t>
<t>
Tom pointed out that:
</t>
<t>
Connect State:
</t>
<t>
If the TCP connection succeeds [Event 15 or
Event 16], the local system checks the "Delay Open
Flag". If the delay Open flag is set, the local system:
**enters what state
</t>
<t>
Sue proposed these changes:
</t>
<t>
1) Connect State - Event 15 or Event 16 [consensus, editorial]
</t>
<t>
note: The delay retry timer is utilized instead of the
connect retry timer for the next two changes.
Previous text:
</t>
<t>
If the TCP connection succeeds [Event 15 or Event 16],
local system checks the "Delay Open Flag". If the delay
open flag is set, the local system:
- clears the connect retry timer,
- sets the BGP open delay timer to initial value
If the Delay Open flag is not set, the local system:
- clears the connect retry timer,
- clear BGP Open Delay timer (set to zero),
- completes the BGP initialization,
- send an Open message to its peer,
- sets hold timer to a large value, and
- change the state to Open Sent.
</t>
<t>
New text:
</t>
<t>
If the TCP connection succeeds [Event 15 or Event 16],
local system checks the Delay Open flag prior to
processing: If the Delay Open flag is set, the local system:
- clears the connect retry timer,
- sets the BGP open delay timer to initial value, and
- stays in the Connect state.
</t>
<t>
If the Delay Open flag is not set, the local system:
- clears the connect retry timer,
- clears the BGP Delay timer (sets to zero),
- completes the BGP initialization,
- sends an Open message to its peer,
- sets the hold timer to a large value, and
- changes the state to Open Sent.
</t>
<t>
Tom agreed that this was good, with the change to "Open Delay timer"
as discussed in issue 7.
</t>
<t>
This conversation was started in the "bgp18 WG Last Call fsm missing next
state" thread.
</t>
</section>
<section anchor="FSM Missing Next States - Event 14 (Connect State)" title="FSM Missing Next States - Event 14 (Connect State)">
<t>
Status: Consensus
<vspace />
Change: Yes
<vspace />
Summary: We selected option 2 from discussion as the correct text:
</t>
<t>
2) treat it as an invalid response, reject the connection and see
if a valid configured one comes within the connect timer's
window.
</t>
<t>
Discussion:
</t>
<t>
Tom pointed out that:
</t>
<t>
Connect State:
</t>
<t>
If the TCP connection receives an indication
that is invalid or unconfigured. [Event 14]:
**enters what state
</t>
<t>
Sue proposed these alternatives:
</t>
<t>
2)Connect State - Event 14 [no consensus]
</t>
<t>
Current Text:
If the TCP connection receives an indication that
that is invalid or unconfigured [Event 14],
- the TCP connection is rejected.
At the very least this section needs more "word smithing",
so I'd like to change it for more clarity at least.
</t>
<t>
I'm not sure this represents the implementations.
What I'd like to do is query the implementations
to see what they do if they receive a valid TCP
connection with an invalid or unconfigured peer.
Two options:
Alternative 1: Count it as a valid response
New Text: If a TCP connection is received that has
an invalid format, or an unconfigured host [Event 14],
the local system:
- rejects the TCP connection,
- increments the connect retry counter,
- performs bgp peer oscillation checks.
If bgp peer oscillation checks allow for a new
connection, the bgp peer
- restarts the Connect retry timer with configured
value, and
- enters the Active state.
FSM table:
Idle Connect Active Open-Sent Open-Confirm Establish
Event-14 =======================================================
Next state Idle | Active|Active|Open-Sent|Open-Confirm|Establish|
=======================================================
action V | Y2 | L | Ignore | Ignore | Ignore |
=======================================================
Alternative 2: Reject the connection and see if valid or
configured one appears within the
connect timer window.
</t>
<t>
New Text: If a TCP connection is received that has an invalid format,
or an unconfigured host [Event 14], the local system:
- rejects the TCP connection,
- and stays in the Connect state.
</t>
<t>
FSM table:
Idle Connect Active Open-Sent Open-Confirm Establish
Event-14 =======================================================
Nxt state Idle |Connect|Active|Open-Sent|Open-Confirm|Establish|
=======================================================
action V | L | L | Ignore | Ignore | Ignore |
=======================================================
</t>
<t>
Sue then sent out a call to implementors to let the list know what they
did with their FSMs. Tom replied that he agreed that we need to wait
to see what the existing implementations do. He also suggested:
</t>
<t>
**tp need a then clause here 'if bgp peer oscillation damping does
not allow for a new connection, then the local system ???'
</t>
<t>
be added before the FSM table in option 1 of the proposed text.
</t>
<t>
Sue prodded the list saying that:
</t>
<t>
Should the peer:
1) Treat it as a valid response, and enters the active state
to watch for a another TCP connection with a valid peer.
</t>
<t>
2) treat it as an invalid response, reject the connection and see
if a valid configured one comes within the connect timer's
window.
</t>
<t>
Without further input, I will select option 2.
</t>
<t>
Curtis replied that this was fine with him.
</t>
<t>
There has been no further disagreement, we are at consensus on this.
</t>
<t>
This conversation was started in the "bgp18 WG Last Call fsm missing next
state" thread. It was also discussed in the "BGP draft-19 - FSM input
needed from developers" thread.
</t>
</section>
<section anchor="FSM Missing Next States - Event 15 or 16 (Active State)" title="FSM Missing Next States - Event 15 or 16 (Active State)">
<t>
Status: Consensus
<vspace />
Change: Yes
<vspace />
Summary: Add text listed in discussion.
</t>
<t>
Discussion:
</t>
<t>
Tom pointed out:
</t>
<t>
Active State:
</t>
<t>
A TCP connection succeeds [Event 15 or Event 16], the
local system: process the TCP connection flags
- If the BGP delay open flag is set:
** enters what state (I think this is an FSM error in TCP because it
has not initiated a connection!)
</t>
<t>
Sue proposed these changes:
</t>
<t>
Previous text:
A TCP connection succeeds [Event 15 or Event 16],
the local system: process the TCP connection flags
- If the BGP delay open flag is set:
- clears the connect retry timer
[through the following text:
- and changes its state to Open Sent.
</t>
<t>
New text:
If the TCP connection succeeds [Event 15 or Event 16],
local system checks the "Delay Open Flag" prior to
processing: If the delay open flag is set, the local system:
- clears the connect retry timer,
- sets the BGP open delay timer to initial value, and
- stays in the Active state.
</t>
<t>
If the Delay Open flag is not set, the local system:
- clears the connect retry timer,
- clears the BGP Delay timer (sets to zero),
- completes the BGP initialization,
- sends an Open message to its peer,
- sets the hold timer to a large value, and
- changes the state to Open Sent.
</t>
<t>
Tom agreed with this.
</t>
<t>
This conversation was started in the "bgp18 WG Last Call fsm missing next
state" thread.
</t>
</section>
<section anchor="FSM Missing Next States - Event 13-17 (TCP Connection)" title="FSM Missing Next States - Event 13-17 (TCP Connection)">
<t>
Status: Consensus
<vspace />
Change: Yes
<vspace />
Summary: We selected:
</t>
<t>
Choice 2: Event 13 and Event 14 be optional, and Events 15 - 17
be mandatory.
</t>
<t>
Discussion:
</t>
<t>
Tom started this by saying that:
</t>
<t>
If the local system receives a valid TCP Indication
[Event 13], the local system processes the TCP connection
flags.
** enters what state
</t>
<t>
If the local system receives a TCP indication
that is invalid for this connection [Event 14]:
** enters what state
</t>
<t>
Sue proposed we move this to the "fsm missing next state - Events 13-17 and
the TCP connection" thread.
</t>
<t>
The response in this thread was:
</t>
<t>
4) Active State, Event 13 [no consensus]
5) Active State, Event 14 [no consensus]
</t>
<t>
The problem with this state is it is difficult to
exactly specify without discussing the TCP
Messages that FSM document covers.
I'll query if the implementors require all
of events 13-17 as mandatory.
</t>
<t>
Sue polled the implementors on the list with this query:
</t>
<t>
These events are described in section 8.1.3.
</t>
<t>
In our discussion in January through May of 2002, many
implementers mapped their implementation onto the
following TCP events list in 8.1.3.
</t>
<t>
</t>
<t>
Events 13 - 17
</t>
<t>
Event 13 - TCP connection indication & valid
remote peer
</t>
<t>
Event 14 - TCP connection indication with invalid
source or destination
Event 15 - TCP connection request sent (by this
peer) received an Acknowledgement
</t>
<t>
[ local system sent a TCP SYN, Received a
TCP SYN, ACK pair back, and Sent a TCP ACK]
</t>
<t>
Event 16 - TCP connection confirmed
</t>
<t>
[local system received a TCP SYN, sent
a TCP SYN, ACK back, and received a TCP ACK]
</t>
<t>
Event 17 - TCP connections
</t>
<t>
Should we have all of these states? Which implementations
support all of these Events?
</t>
<t>
The full FSM text was snipped here for brevity.
</t>
<t>
Sue prodded the list with:
</t>
<t>
Do the implementors require Events 13 - 17 in the State machine ?
</t>
<t>
Event 13 - TCP connection valid indication
Event 14 - TCP connection invalid indication
Event 15 - TCP connection request acknowledged
Event 16 - TCP connection confirmed
Event 17 - TCP connection fails
</t>
<t>
Choice 1: Events 13 - 17 are mandatory
Choice 2: Event 13 and Event 14 be optional, and Events 15 - 17
be mandatory.
If no one objects, we will use Choice 2.
</t>
<t>
Curtis said this was fine with him.
</t>
<t>
There has been no further disagreement, we are at consensus on this.
This was started in the "bgp18 WG Last Call fsm missing next
state" thread. And continued in the "fsm missing next state - Events 13-17
and the TCP connection" thread. It was also discussed in the "BGP draft-19
- FSM input needed from developers" thread.
</t>
</section>
<section anchor="FSM Missing Next States - Event 17 (Connect State)" title="FSM Missing Next States - Event 17 (Connect State)">
<t>
Status: Consensus
<vspace />
Change: No
<vspace />
Summary: Closed in favor of 13.4
</t>
<t>
Discussion:
</t>
<t>
</t>
<t>
If the local system receives a TCP connection
failed [Event 17] (timeout or receives connection
disconnect), the local system will:
** enters what state
</t>
<t>
Sue replied with this:
</t>
<t>
.in 4
comment:
In the Active state, we may already have a connection and be awaiting
the Open Delay timer. The TCP disconnect or timeout could occur in this
state due to the "Open Delay Timer". If the TCP Disconnect is ignored,
we could have some peer oscillation.
</t>
<t>
If the we wait, then the connection retry timer needs to be kept running.
The text below allows this timer. The real question is what is the status
of the current implementations.
</t>
<t>
I agree, the Active state and the connect state should match.
</t>
<t>
Old Text:
If the TCP connection fails (timeout or disconnection) [Event
17], the local system:
- set TCP disconnect in the MIB reason code,
- restart Connect retry timer (with initial value),
- release all BGP resources,
- Acknowledge the Drop of the TCP connection if TCP
disconnect (FIN ACK),
- Increment ConnectRetryCnt (connect retry count) by 1, and
- performs the BGP peer oscillation damping process.
</t>
<t>
Applicable FSM State table:
FSM table old:
Event 17
current: Idle Connect Active Open-Sent Open-Confirm Establish
=========================================================
Next state Idle |Active |Idle |Active | Idle |Idle |
| | | | | |
=========================================================
action V | Y2 | G | Ignore| Track 2nd | Track 2nd |
| | | | connection | connection|
=========================================================
</t>
<t>
Alternative 1:
</t>
<t>
</t>
<t>
FSM table new:
</t>
<t>
Event 17
current: Idle Connect Active Open-Sent Open-Confirm Establish
=========================================================
Next state Idle |Active |Active |Active | Idle |Idle |
| | | | | |
=========================================================
action V | G | G | Ignore| Track 2nd | Track 2nd |
| | | | connection | connection|
=========================================================
G: The local system:
- restarts the connect retry timer (at initial value),
- continues to listen for a connection that may be initiated
by the remote peer, and
- sets its next state to Active.
</t>
<t>
New Text: (for Connect and Active state)
If the TCP connection fails (timeout or disconnect)
[Event 17], the local system:
- restarts the connect retry timer,
- continues to listen for a connection that may be
initiated by the remote BGP peer, and
- changes it state to Active.
Alternative 2:
FSM table new:
Event 17
current: Idle Connect Active Open-Sent Open-Confirm Establish
=========================================================
Next state Idle |Idle |Idle |Active | Idle |Idle |
| | | | | |
=========================================================
action V | Y2 | Y2 | Ignore| Track 2nd | Track 2nd |
| | | | connection | connection|
=========================================================
Next Text:
If the location system receives a TCP connection failed [Event
17], the local system will:
- increment the ConnectRetryCnt (connect retry count)
by 1,
- release all BGP resources associated with this
connection,
- perform BGP peer oscillation (if configured), and
- go to Idle
</t>
<t>
Y2 - is:
The local system:
1) increments the ConnectRetryCnt (connect retry
count) by 1,
2) releases all BGP resources associated with this
connection, and
3) performs the BGP peer oscillation damping process
</t>
<t>
if the damping process allows for a new connection, the local
system:
- restarts the connect retry timer (with initial
value, and
- goes to Idle
If the damping process does not allow for a new connection,
the local system
- set the flags to damp the creation of a new bgp
connection until a manual start occurs, and
- goes to Idle.
</t>
<t>
Tom agreed with the options, and stated that he preferred option 2. Sue
is also happy with option 2, if no one else chimes in.
</t>
<t>
After the issues list came out Tom responded to this issue, saying:
</t>
<t>
.in 4
I think this issue SHOULD be administratively terminated.
</t>
<t>
It relates to Connect state Event 17 (TCP connection fails) and I am
credited with raising it; in fact, the issue I raised was missing next
state for Active state event 17 and this has now been subsumed into
13.4 (but note that 13.4 does not explicitly say Active state - I know
it should because I raised that issue too). I will ensure it does not
get lost from any resolution of 13.4.
</t>
<t>
And Connect state event 17 does appear as part of issue 45 which Siva
raised so I think that either way, 13.5 can go.
</t>
<t>
This conversation was started in the "bgp18 WG Last Call fsm missing next
state" thread.
</t>
</section>
<section anchor="FSM Missing Next States - Event 18 (Open Confirm)" title="FSM Missing Next States - Event 18 (Open Confirm)">
<t>
Status: Consensus
<vspace />
Change: Yes
<vspace />
Summary: This is the text:
</t>
<t>
.in 4
In the Open Confirm state, a valid Open message [Event 22] is received.
The BGP Peer connection is check to see if there is a collision per
section 6.8. If this connection is to be dropped due to the call
collision, the local system will drop the call by:
</t>
<t>
- sending a NOTIFICATION with a CEASE,
- resets the Connect timer (to zero),
- releases all BGP resources (this includes stopping the Open Delay Timer
and reseting it to zero),
- increments the ConnectRetryCnt by 1 (connect retry +count), and
- optionally performs a BGP peer oscillation damping processing, and
- enters the Idle State.
</t>
<t>
Discussion:
Tom opened this with:
</t>
<t>
Open Confirm State:
</t>
<t>
If the Open messages is valid [Event 18], the collision
detect function is processed per section 6.8. If this
connection is to be dropped due to call collision, the
local system:
** enters what state
</t>
<t>
Sue replied with:
</t>
<t>
Here's my proposed text. Please let me know what you think.
I think this is an editorial change.
Old text: If the open message is valid, the collision detect
function is processed per section 6.8. If this
connection is to be dropped due to call collision, the
local system:
- sends a Notification with a Cease
- resets the Connect timer (to zero),
- releases all BGP resources,
- Drop the TCP connection (sends a TCP FIN),
- increments the ConnectRetryCnt by 1 (connect retry
count), and
- performs an BGP peer oscillation damping process.
</t>
<t>
New text: If the open message is valid, the BGP peer connection
is check to detect a collision per section 6.8. If this
connection is to be dropped due to call collision, the
local system:
- sends a Notification with a Cease
- resets the Connect timer (to zero),
- releases all BGP resources,
- Drop the TCP connection (sends a TCP FIN),
- increments the ConnectRetryCnt by 1 (connect retry
count), and
- performs an BGP peer oscillation damping processing,
and
- enters the Idle State.
notes: Collision detect impacts Open Sent, Open Confirm, and
Established states.
</t>
<t>
Tom replied:
</t>
<t>
.in 4
I am still struggling with; we are in OpenConfirm so we already have
received an Open from the remote peer and Event 18 is a second Open
from the same peer. Perhaps my struggle is that I think in terms of
two (or more) FSM for a given IP address pair so the Open Collision
detection will occur when the/an- other FSM receives a valid Open in
states Active/Connect/Open Sent and will generate Event 22 into this
FSM so Event 18 cannot occur. But yes, if Event 18 can occur in this
FSM and this connection is to be dumped, then Idle state it should be
as you suggest. I have slotted in [optionally] in front of the peer
oscillation damping in your text because I think it should be
optional:-)
</t>
<t>
Sue replied:
</t>
<t>
this mechanism allows a single fsm to
handle both. 2 fsm and 1 fsm BGP FSM
seem to exist. (I queried implementors
a few times on this one. So, I just
put in this change to provide the
flexibility.
</t>
<t>
Collision detect tends to give
scrambled brains for most people..
As Dennis Ferguson said 2 years ago,
that's the hardest part of the FSM.
</t>
<t>
Sue then stated that she would query implementors to see what is being done.
</t>
<t>
Sue prodded the list with:
</t>
<t>
.in 4
In the Open Confirm state, a valid Open message [Event 22] is received.
The BGP Peer connection is check to see if there is a collision per
section 6.8. If this connection is to be dropped due to the call
collision, the local system will drop the call by:
</t>
<t>
- sending a NOTIFICATION with a CEASE,
- resets the Connect timer (to zero),
- releases all BGP resources (this includes stopping the Open Delay Timer
and reseting it to zero),
- increments the ConnectRetryCnt by 1 (connect retry +count), and
- optionally performs a BGP peer oscillation damping processing, and
- enters the Idle State.
</t>
<t>
Implementors need to verify if this text and the text for Event 22
allows all implementors to perform the necessary Call Collision actions.
If no objects, we will use this text.
</t>
<t>
Curtis said he had no problem with this.
</t>
<t>
There has been no disagreement, we are at consensus with this.
</t>
<t>
This conversation was started in the "bgp18 WG Last Call fsm missing next
state" thread. It was also discussed in the "BGP draft-19 - FSM input needed
from developers" thread.
</t>
</section>
</section>
<section anchor="FSM - Peer Oscillation Damping" title="FSM - Peer Oscillation Damping">
<t>
Status: Consensus
<vspace />
Change: Yes
<vspace />
Summary: Change references to peer oscillation damping to consistent phrase:
<vspace />
"[optionally] performs peer oscillation damping". Also remove old
reference to "BGP Peer Restart Backoff Mechanisms".
</t>
<t>
Discussion:
</t>
<t>
Tom suggested we use consistent terminology to refer to peer oscillation
damping. He also pointed out a stale reference.
</t>
<t>
Yakov agreed to fix both of these.
</t>
</section>
<section anchor="FSM - Consistent FSM Event Names" title="FSM - Consistent FSM Event Names">
<t>
Status: Consensus
<vspace />
Change: Yes
<vspace />
Summary: Make FSM names consistent. Specifics are in the discussion section.
</t>
<t>
Discussion:
</t>
<t>
Tom proposed that:
</t>
<t>
.in 4
The event name used in the FSM show much variation to the point
sometimes where I am not clear that it is always the same event (eg
where the event name is qualified by a subset of the possible causes).
Assuming that it is, I propose the following changes to make the
wording consistent, clear and concise for event names.
</t>
<t>
** denotes changed text using the convention /'old text'/'new text'/
</t>
<t>
8. BGP Finite State machine
</t>
<t>
Event1: Manual start
Event2: Manual stop
Event3: Automatic start
**Event4: Manual start with passive TCP /establishment/flag/
**Event5: Automatic start with passive TCP /establishment/flag/
Event6: Automatic start with bgp_stop_flap option set
**Event7: Auto//matic/ stop
Event8: Idle hold timer expires
Event9: Connect retry timer expires
**Event10: Hold time//r/ expires
Event11: Keepalive timer expires
Event12: Open Delay timer expires
**Event13: TCP connection valid indication
**Event14: TCP connection invalid indication
**Event15: TCP connection request /sent received an ACK/acknowledged/
Event16: TCP connection confirmed
Event17: TCP connection fails
Event18: BGPOpen
Event19: BGPOpen with *Open Delay timer running
Event20: BGPHeaderErr
Event21: BGPOpenMsgErr
Event22: Open collision dump
Event23: NotifMsgVerErr
Event24: NotifMsg
Event25: KeepAliveMsg
Event26: UpdateMsg
Event27: UpdateMsgErr
</t>
<t>
8.2.2 Finite State Machine
</t>
<t>
Connect State:
</t>
<t>
If the BGP port receives a ** valid TCP connection indication
[Event 13],
</t>
<t>
If the TCP connection receives **an invalid indication
[Event 14]:
</t>
<t>
If the TCP connection fails **/(timeout or disconnect)//
[Event17]
</t>
<t>
Active State:
</t>
<t>
If the local system receives a **valid TCP //indication/
[Event 13],
If the local system receives a TCP connection failed [Event
17] **/(timeout or receives connection disconnect)//,
</t>
<t>
Open Sent:
If a connection in Open Sent is determined to be the
connection that must be closed, an **/administrative collision
detect/Open collision dump/ [Event 22] is signaled to the
state machine. If such an **/administrative collision detect
dump [Event 22]/event/ is
If a TCP **//connection valid/ indication [Event 13] or
TCP **//connection/ request **//acknowledged/ [Event 15]
Open Confirm State:
...or receives a TCP **/Disconnect// connection fails/ [Event
17] from the
</t>
<t>
In the event of **/TCP establishment//TCP connection valid
indication /[Event 13]
</t>
<t>
...the local system will
**/issue a call/generate an Open/ collision dump [Event 22].
When the local system receives a **/call/open/ collision dump
event [Event 22]/such an event/, the
</t>
<t>
Established State:
**/disconnect from the underlying TCP/TCP connection fails/
[Event17], it:
</t>
<t>
... it will process **/a Call/an Open/ Collision dump
event[Event 22].
</t>
<t>
Notes:
Event 4 title brought in line with text
Event 5 title brought in line with text
Event 7 title brought in line with text
Event 13 title shortened to be closer to text, text brought in line
Event 14 title shortened to be closer to text, text brought in line
Event 15 title brought in line with text
Event 17 text brought in line with title (text often introduces
qualifying conditions that are too restrictive)
Event 22 text brought in line with title
</t>
<t>
Sue replied:
</t>
<t>
I will accept the text you proposed for the Event names.
I will update the FSM text to include your changes.
We'll consider issue 15 in consensus. I've fixed the text.
</t>
<t>
So we are at consensus here.
</t>
<t>
This is discussed in the thread: "bgp18 WG Last Call fsm event names." It
was also discussed in the "Issue 15 - Consistent FSM Event Names" thread.
</t>
</section>
<section anchor="Many Editorial Comments" title="Many Editorial Comments">
<t>
Status: Consensus
<vspace />
Change: Yes
<vspace />
Summary: Many editorial suggestions, and what we are doing with them
are listed below. Some issues have been broken out separately where there
is a longer discussion on them.
</t>
<t>
Discussion:
</t>
<t>
Alex began this by presenting comments from an anonymous reviewer, unless
otherwise noted, responses are from Yakov:
</t>
<t>
> Almost all of these are simple clarifications.
>
> Section 1, page 5: IGP definition - it's not clear from this
> definition whether IBGP would be considered an IGP?
any suggestion on how to improve the definition to clarify
this issue would be appreciated.
</t>
<t>
There was some further discussion on this and it was decided that people
reading this document ought to know what an IGP is.
</t>
<t>
> Section 3, page 7, para 4: Does RFC 1772 still represent the
> *planned* use of BGP? Or the actual use? Or something
> different from actual use?
</t>
<t>
Perhaps we should just take out references to 1772.
</t>
<t>
Further discussion seemed to indicate that this reference should stay.
</t>
<t>
> Section 3, page 8, para 3 - "The hosts executing..." This
> paragraph seems obsolete.
</t>
<t>
I'll take it out.
</t>
<t>
With regard to this, Siva asked if some route optimization vendors rely on
this. Since this wasn't resolved, it is discussed further in issue 17.
</t>
<t>
> Section 4.1, page 11 - Length is in network byte order.
</t>
<t>
all the encodings are in network byte order. This applies not just
to the BGP spec, but to other protocols as well.
</t>
<t>
This comment was made about a number of fields. It was later agreed that
a reference would be made to this at the beginning of the document.
</t>
<t>
> Section 4.2, page 12 - Hold Time - what does a value of zero
> indicate?
</t>
<t>
if you read section 4.4 then you'll find that:
If the negotiated Hold Time interval is zero, then periodic
KEEPALIVE messages MUST NOT be sent.
</t>
<t>
> Section 4.2, page 13 - BGP Identifier - network byte order?
> "IP address" -> "IPv4 address"
</t>
<t>
I'll put at the beginning a sentence saying that in the context of
this document the term "IP address" means an IP Version 4 address.
</t>
<t>
> Section 4.3, Page 14, para1, sentence 2 - "path attribute" ->
> "path attributes"
</t>
<t>
fixed.
</t>
<t>
> Section 4.3,Page 17, NEXT_HOP: "IP address" -> "IPv4 address"
> Specify that this is 4 octets.
> Reference here to multi-protocol extensions for IPv6
> nexthop?
</t>
<t>
no.
</t>
<t>
> RFC 2283 is unclear whether NEXT_HOP should always be
> included when using multiprotocol extensions. Clarify
> this here?
</t>
<t>
It is already clarified in 2283bis.
</t>
<t>
> Section 4.3, Page 17/18 - MED and LocalPref:
> "non-negative" -> "unsigned" for consistency with
> elsewhere. (non-negative might imply values > 2^31
> cannot be used).
fixed.
> Section 4.3, Page 19 - Prefix: "IP address" -> "IPv4 address"
> Prefix: "enough trailing bits to" -> "the minimum number
> of trailing bits needed to"
</t>
<t>
fixed.
</t>
<t>
> Section 4.4, Page 20: - "BGP does not use any TCP-based keep-alive
> mechanism to determine if peers are reachable". Is it worth noting
> that TCP may still timeout the connection even if TCP keepalives are
> turned off?
</t>
<t>
the text is fine as it is.
</t>
<t>
> Section 4.4, Page 20:
> KEEPALIVE message consists" -> "A KEEPALIVE message consists"
fixed.
</t>
<t>
> Section 5, Page 23: "The same attribute can not appear more than
> once with the Path Attributes field...". Does this mean the same
> attribute type, or the same attribute type and value?
</t>
<t>
the former (the same attribute type).
</t>
<t>
> Section 5.1 "The usage of each BGP path attributes .." ->
> attribute
</t>
<t>
fixed.
</t>
<t>
> Section 5.1.3 "IP address" -> "IPv4 address"
>
> "A BGP speaker must never advertise an address of a peer to that
> peer as a NEXT_HOP, for a route that the speaker is originating."
> suggest replace this text with:
> "A route originated by a BGP speaker must never be advertised to a
> peer using an address of that peer as NEXT_HOP"
</t>
<t>
fixed.
</t>
<t>
> Section 5.1.4: "A BGP speaker MUST IMPLEMENT a mechanism ... which
> allows the MULTI_EXIT_DISC to be removed from a route." Might
> want to say that this is dangerous unless you received the route
> from an EBGP peer?
</t>
<t>
think we should keep the text as is.
</t>
<t>
> Section 5.1.5: "If it [LOCAL_PREF] is contained in an UPDATE
> message that is received from an external peer, then this
> attribute MUST be ignored by the receiving speaker, except for the
> case of BGP Confederations [RFC3065]."
> - "ignored" might be taken to mean that you don't process it for
> decision, but that you propagate it to internal peers. I might
> write "silently removed" or something similar.
</t>
<t>
I think the text is ok as is.
</t>
<t>
> Section 5.1.5, para 2. "set of AS" -> "set of ASs"
</t>
<t>
fixed.
</t>
<t>
> Section 6.3: wrt NEXT_HOP semantic correctness: should we check
> that a NEXT_HOP is not a multicast or broadcast address?
</t>
<t>
I'll add to the definition of NEXT_HOP that it is a unicast address.
</t>
<t>
> Section 6.3, page 32, para 7: "peer than sent" -> "peer that
> sent"
</t>
<t>
fixed.
</t>
<t>
> Section 6.3: "if any attribute appears more than once" - does this
> mean the same attribute type, or the same attribute type and
> value?
</t>
<t>
the former.
</t>
<t>
> Section 6.8 "Comparing BGP identifiers is done by treating them as
> (4-octet-long) unsigned integers". Need to convert to host byte
> order before comparing.
</t>
<t>
fixed.
</t>
<t>
> Section 6.8, item 2: "closes BGP connection" -> "closes the BGP
> connection"; "accepts BGP connection" -> "accepts the BGP connection".
</t>
<t>
fixed.
</t>
<t>
> Section 9.1.2.2: item (c): in the explanation of neighborAS(n), it
> is unclear for IBGP connections how to determine "the neighbor AS
> from which the other IBGP speaker learned the route". If this is
> really the leftmost entry in the AS path (or the local AS if the
> path is empty), the spec should explicitly say so.
</t>
<t>
fixed.
</t>
<t>
> Section 9.1.2.2, page 63, paragraph starting "If a MULTI_EXIT_DISC
> attribute is removed before..." The first sentence is pretty
> nearly incomprehensible.
</t>
<t>
This topic has some more discussion surrounding what text we should use
to clarify this issue. This is followed up in issue 18.
</t>
<t>
> Section 9.1.2.2 (d)
> "d) If at least one of the candidate routes was received from
> an external peer in a neighboring autonomous system, remove
> from consideration all routes which were received from
> internal peers."
> For consistency with (c) and clarity, this might be reworded:
> "d) If any of the candidate routes was learned via EBGP,
> remove from consideration all routes which were learned by
> IBGP."
</t>
<t>
fixed.
</t>
<t>
> Section 9.1.2.2 (e)
> "cost (n) is better than cost (m)"
> Given the definition of cost, it might be clearer to say
> "cost (n) is lower than cost (m)"
</t>
<t>
fixed.
</t>
<t>
> Section 9.1.2.2 (g)
> "neighbor address" has not been defined.
</t>
<t>
I'll replace "neighbor address" with "peer address".
</t>
<t>
> Section 9.2.2.2, Page 70 (AGGREGATOR) - "All AGGREGATOR attributes
> of all routes to be aggregated should be ignored."
>
> Perhaps "ignored" is ambiguous here, and it's not clear
> whether should is a SHOULD. Suggest:
>
> "Any AGGREGATOR attributes from the routes to be aggregated
> MUST NOT be included in the aggregated route."
fixed.
</t>
<t>
> Section 9.3 - shouldn't this subsection be moved to the discussion
> of Phase 1 or Phase 2 of the decision process? Or at least move it
> before Section 9.2.
</t>
<t>
I think it is fine where it is now.
</t>
<t>
> Appendix E, para 2: IP precedence has been deprecated. Delete
> this paragraph, or replace with appropriate diffserv codepoint.
</t>
<t>
deleted.
</t>
<t>
> Security Considerations:
> "BGP supports the ability to authenticate BGP messages by using
> BGP authentication."
> This sentence should be removed, and the Authentication
> Information parameter has been deprecated.
</t>
<t>
Please see the recent e-mail exchange on the Security Considerations
</t>
<t>
See issue 19 for more on the Security Considerations section of the draft.
</t>
<t>
These topics were discussed in the "proxy: more comments on the draft -18"
thread.
</t>
</section>
<section anchor="Section 3, Page 8, Paragraph 3 - Obsolete?" title="Section 3, Page 8, Paragraph 3 - Obsolete?">
<t>
Status: Consensus
<vspace />
Change: Yes
<vspace />
Summary: Leave the current definition of BGP Speaker, and normalize the
text to use "BGP Speaker" instead of router.
</t>
<t>
Discussion:
</t>
<t>
This issue was spawned from the discussions in issue 16, specifically:
</t>
<t>
Anonymous reviewer:
</t>
<t>
> Section 3, page 8, para 3 - "The hosts executing..." This
> paragraph seems obsolete.
</t>
<t>
Yakov:
</t>
<t>
I'll take it out.
</t>
<t>
With regard to this, Siva asked if some route optimization vendors rely on
this.
</t>
<t>
Jeff replied:
</t>
<t>
To provide context, this paragraph currently reads:
</t>
<t>
: The hosts executing BGP need not be routers. A non-routing host
: could exchange routing information with routers via EGP [RFC904]
: or even an interior routing protocol. That non-routing host could
: then use BGP to exchange routing information with a border router
: in another Autonomous System. The implications and applications of
: this architecture are for further study.
.in 4
There are several deployed entities that could be considered to "exploit"
this paragraph. Route collectors, route servers, bandwidth shapers
and other optimizers. However, the original text may be showing its
age a little bit.
</t>
<t>
Perhaps the following might be a bit more appropriate:
</t>
<t>
"The hosts executing BGP need not be routers. A non-routing host may
exchange routing information with a BGP speaker for reasons
that are outside the scope of this document."
</t>
<t>
I would also propose adding to the same paragraph (but could be persuaded
to drop it since it is *logically* redundant):
"These non-routing hosts should exercise great care not to insert
themselves into the forwarding path if they re-announce BGP routes."
</t>
<t>
Yakov replied:
</t>
<t>
Since operations of non-routing host are outside the scope of the
document, and since the document doesn't preclude non-routing hosts
to run BGP, I would prefer just to take the following paragraph out,
and not to add any new text.
</t>
<t>
The hosts executing BGP need not be routers. A non-routing host
could exchange routing information with routers via EGP [RFC904]
or even an interior routing protocol. That non-routing host could
then use BGP to exchange routing information with a border router
in another Autonomous System. The implications and applications of
this architecture are for further study.
</t>
<t>
Jeff replied that this was ok, and instead suggested:
</t>
<t>
At the beginning of the document, we define:
BGP speaker
A router that implements BGP.
</t>
<t>
This (potentially) restricts a speaker to being a router.
Additionally, several spots in the text where we probably should
say "BGP speaker", we use router.
</t>
<t>
Yakov agreed to add this definition.
</t>
<t>
Jeff replied that there still was a problem with this definition being
too limiting. The discussion meandered off list for a couple of
exchanges and these additional definitions were proposed:
</t>
<t>
First Jeff proposed this:
</t>
<t>
"A router that implements the BGP protocol.
Non-routing hosts that also implement BGP are out of scope of this
document."
</t>
<t>
Then Andrew replied, that we should make sure the definition does not
opt out entirely from making sure that non-routing hosts are interoperable:
</t>
<t>
BGP Speaker
.in 7
A router that implements the BGP protocol. The internal behavior of
non-routing hosts that also implement BGP are out of scope of this
document. However, in their interactions with routers, non-routing hosts
must behave as if they were routers.
</t>
<t>
And Jeff replied:
</t>
<t>
BGP Speaker
.in 7
A router that implements the BGP protocol. The internal behavior of
non-routing hosts that also implement BGP are out of scope of this
document. However, in their interactions with BGP speaking routers,
non-routing hosts that implement BGP should be indistinguishable from
a router on the wire.
.in 4
</t>
<t>
(or something like that - s/on the wire/ with whatever sounds best.)
</t>
<t>
IOW, look like bgp on the wire - what you do internally is out of scope.
</t>
<t>
Yakov replied, that we should keep the current definition, since it is
clear that non-routing hosts are outside of the scope. Jeff responded
that he is ok with that if we normalize the use of "BGP Speaker" instead
of "BGP router" in the document. Yakov agreed to this, we are at consensus
on this.
</t>
<t>
This was discussed in the "proxy: more comments on draft -18" thread.
And in the "Issues list, #17: Section 3, Page 8, Paragraph 3 - Obsolete?"
thread. And also, the "issue 17 - final resolution" thread.
</t>
</section>
<section anchor="MED Removal Text" title="MED Removal Text">
<t>
Status: Consensus
<vspace />
Change: Yes
<vspace />
Summary: Use text at the end of the discussion.
</t>
<t>
Discussion:
</t>
<t>
This issue is spawned from issue 16.
</t>
<t>
An anonymous reviewer pointed out:
</t>
<t>
> Section 9.1.2.2, page 63, paragraph starting "If a MULTI_EXIT_DISC
> attribute is removed before..." The first sentence is pretty nearly
> incomprehensible.
</t>
<t>
Yakov replied:
</t>
<t>
here is my attempt to clarify this:
</t>
<t>
If a MULTI_EXIT_DISC attribute is removed before re-advertising a
route into IBGP, then (prior to the removal) the MULTI_EXIT_DISC
attribute may only be considered in the comparison of EBGP learned
routes; the attribute is then removed, and then the remaining EBGP
learned routes may be compared to the remaining IBGP learned routes,
without considering the MULTI_EXIT_DISC attribute for those EBGP
learned routes whose MULTI_EXIT_DISC attribute will be removed
before advertising these routes to IBGP.
</t>
<t>
Any further suggestions on how to improve this would be appreciated.
</t>
<t>
Siva replied:
</t>
<t>
How about this:
</t>
<t>
If a MULTI_EXIT_DISC attribute is removed before re-advertising a
route into IBGP, then comparison based on the MULT_EXIT_DISC
attribute may (MUST?) be performed only among the EBGP learned routes.
This comparison MUST be performed before the removal of the
MULTI_EXIT_DISC attribute. The MULT_EXIT_DISC attribute must then
be removed from those EBGP routes where such removal is required and
which are still eligible. This is followed by comparison with IBGP
learned routes.
</t>
<t>
I think this reflects our objectives, which is:
</t>
<t>
a) If MED is to be removed, compare EBGP routes based on the MED
</t>
<t>
b) Then remove the MED
</t>
<t>
c) Then do comparison with IBGP routes
</t>
<t>
Andrew suggested:
</t>
<t>
If a router is configured to remove a MULTI_EXIT_DISC attribute from
a route learned from EBGP, before re-advertising it into IBGP the
router MUST compare the route with other EBGP-learned routes before
removing the MULTI_EXIT_DISC. Once this comparison is complete,
the MED may be removed, and any remaining routes can be compared with
IBGP routes to determine the best route.
</t>
<t>
Yakov replied:
</t>
<t>
Here is the text that will go in the next version of the draft:
</t>
<t>
If a MULTI_EXIT_DISC attribute is removed before re-advertising a
route into IBGP, then comparison based on the MULT_EXIT_DISC
attribute MAY be performed only among the EBGP learned routes.
This comparison MUST be performed before the removal of the
MULTI_EXIT_DISC attribute. The MULT_EXIT_DISC attribute is then
removed from those EBGP routes where such removal is required and
which are still eligible. This is followed by comparison with
IBGP learned routes.
</t>
<t>
Matthew responded to this with:
</t>
<t>
I think this new text is ambiguous.
</t>
<t>
>Here is the text that will go in the next version of the draft:
>
> If a MULTI_EXIT_DISC attribute is removed before re-advertising a
> route into IBGP, then comparison based on the MULT_EXIT_DISC
> attribute MAY be performed only among the EBGP learned routes.
</t>
<t>
.in 4
This could be taken to mean either that the comparison may be performed,
and if it's performed it must be performed only between EBGP learned
routes, or that the comparison must be performed, but it may be performed
only between EBGP learned routes.
</t>
<t>
> This comparison MUST be performed before the removal of the
> MULTI_EXIT_DISC attribute.
</t>
<t>
.in 4
If doing the comparison is optional, then I think that this sentence
should read "If the comparison is performed, then it MUST be perfo..."
</t>
<t>
> The MULT_EXIT_DISC attribute is then
> removed from those EBGP routes where such removal is required and
> which are still eligible. This is followed by comparison with
> IBGP learned routes.
</t>
<t>
<snip>
</t>
<t>
I think that it is desirable for an operator to be able to turn off
MED processing entirely (including turning off all MED based
comparisons), so I would suggest the following text:
</t>
<t>
.in 5
If a MULTI_EXIT_DISC attribute is removed before re-advertising a
route into IBGP, comparison based on the received MULTI_EXIT_DISC
attribute MAY be performed. If an implementation chooses to perform
this comparison, then the comparison MUST be performed only among EBGP
learned routes, and it MUST be performed before the removal of the
MULTI_EXIT_DISC attribute.
</t>
<t>
Curtis replied to Yakov's message:
</t>
<t>
.in 4
Looks good to me.
</t>
<t>
I see no need to change "This comparison MUST be performed before the
removal of the MULTI_EXIT_DISC attribute". There is no implication
that MULTI_EXIT_DISC must be removed and the first sentence clearly
indicates that doing so is not required therefore no ambiguity.
Adding a "If a MULTI_EXIT_DISC attribute is removed" to the second
sentence would be redundant.
</t>
<t>
After some further discussion we have reached full consensus with:
</t>
<t>
.in 4
If a MULTI_EXIT_DISC attribute is removed before re-advertising a
route into IBGP, then comparison based on the received EBGP
MULTI_EXIT_DISC attribute MAY still be performed. If an
implementation chooses to remove MULTI_EXIT_DISC, then the optional
comparison on MULTI_EXIT_DISC if performed at all MUST be performed
only among EBGP learned routes. The best EBGP learned route may
then be compared with IBGP learned routes after the removal of the
MULTI_EXIT_DISC attribute. If MULTI_EXIT_DISC is removed from a
subset of EBGP learned routes and the selected "best" EBGP learned
route will not have MULTI_EXIT_DISC removed, then the
MULTI_EXIT_DISC must be used in the comparison with IBGP learned
routes. For IBGP learned routes the MULTI_EXIT_DISC MUST be used
in route comparisons which reach this step in the decision process.
</t>
<t>
This is discussed in the "proxy: more comments on draft 18" thread. And
in the "issue 18" thread.
</t>
</section>
<section anchor="Security Considerations" title="Security Considerations">
<t>
Status: Consensus
<vspace />
Change: Yes
<vspace />
Summary: Fix Security Considerations section to include mandatory MD5 auth
and advance security considerations draft along with the base draft.
</t>
<t>
Discussion:
</t>
<t>
Yakov started this discussion by proposing text which would require
TCP MD5 authentication for BGP implementations. This is to bring
the spec in line with an IETF requirement that authentication be available.
</t>
<t>
After some discussion the plan is to advance draft-ietf-idr-bgp-vuln-00.txt
as Informational along with the base BGP specification. This draft
will serve as the security analysis section of the base spec.
</t>
<t>
This is discussed in the "revised Security Considerations section" thread.
</t>
</section>
<section anchor="Peer Oscillation Damping" title="Peer Oscillation Damping">
<t>
Status: Consensus
<vspace />
Change: No
<vspace />
Summary: Keep the Peer Oscillation Damping reference in the specification.
</t>
<t>
Discussion:
</t>
<t>
This began when Siva proposed:
</t>
<t>
.in 4
Since this feature is going to be added in a new draft, and its
addition will change the operation of the state machine, can we remove
all mention of it in the state machine ? As part of this removal, can
we also remove the IdleHold Timer from the FSM since it is not useful
in the absence of peer oscillation damping ?
</t>
<t>
The draft that describes this procedure can then describe the change
in the state machine required to do this.
</t>
<t>
Sue replied that:
</t>
<t>
The reason we should not remove the peer oscillation damping
from the state machine:
</t>
<t>
1) Deployed implementations support peer oscillation damping
2) Hooks for the additions in the FSM cannot be added later.
</t>
<t>
These hooks are optional and do not need to be implemented.
</t>
<t>
Siva replied:
</t>
<t>
I understand. I am not trying to object to peer oscillation
damping, I think it is a good idea and we have included it in
our implementation as well. I was suggesting that instead of
a partial description in this draft, it be completely described
in the draft on peer oscillation damping.
</t>
<t>
However, I do see your point, and unless there are any objections
from others, I think we have consensus on this issue.
</t>
<t>
This was discussed in the "Response to FSM input - Comments 1-10" thread:
Comment #1.
</t>
</section>
<section anchor="Session Attributes - IdleHold Timer" title="Session Attributes - IdleHold Timer">
<t>
Status: Consensus
<vspace />
Change: Yes
<vspace />
Summary: Add the text in the discussion section.
</t>
<t>
Discussion:
</t>
<t>
This discussion began with Siva asking:
</t>
<t>
.in 4
Why have a Hold Timer and a Hold Time ? Can we replace this with just
Hold timer ?
</t>
<t>
Can we also add the following session attributes:
</t>
<t>
a) DelayBgpOpenTimer
b) IdleHold Timer (in case we choose not to remove this from the base
FSM)
</t>
<t>
Can we also add the following flag to the session attributes:
a) DelayOpen Flag
</t>
<t>
After some discussion we have this text on the table:
</t>
<t>
Event8: Idle hold timer expires
</t>
<t>
Definition: An Event generated when the Idle Hold Timer
expires. The Idle Hold Timer is only used
when the persistent peer oscillation
damping function is enabled.
</t>
<t>
% Implementations not implemented persistent
% peer oscillations damping functions may not
% have the Idle Hold Timer.
Sue replied:
</t>
<t>
I will accept the new text for the following total text:
Event8: Idle hold timer expires
</t>
<t>
Definition: An event generated when the Idle Hold Timer
.in 24
expires indicating that the session has completed
a back-off period to prevent bgp peer oscillation.
</t>
<t>
The Idle Hold Timer is only used when the persistent
peer oscillation damping function is enabled.
</t>
<t>
Implementations not implementing the persistent peer
oscillation damping functions may not have the Idle Hold
Timer.
</t>
<t>
Status: Optional
</t>
<t>
We are at consensus with this.
</t>
<t>
Tom added a couple of minor edits, correcting the spelling of "persistent"
in the third paragraph, and pointing out that:
</t>
<t>
.in 4
oscillation damping functions may not have the Idle Hold
** function
** (because we only have function not functions in the previous sentence)
Timer.
</t>
<t>
Sue added the edits.
</t>
<t>
Siva also liked the way this issue has turned out.
</t>
<t>
This was discussed in the "Response to FSM input - Comments 1-10" thread:
Comment #2. And in the "Draft 19 - issue #21" thread, alternately
the "Draft 19 - Issue 21" thread.
</t>
</section>
<section anchor="Specify New Attributes (Accept Connections/Peer Oscillation Damping)" title="Specify New Attributes (Accept Connections/Peer Oscillation Damping)">
<t>
Status: Consensus
<vspace />
Change: Yes
<vspace />
Summary: Add the text in the discussion section to section 8.0.
</t>
<t>
Discussion:
</t>
<t>
This began with Siva proposing:
</t>
<t>
Can we call these out as well:
</t>
<t>
* Accept Connections from unconfigured peers (Enabled/Disabled)
* Peer Oscillation Dampening (Enabled/Disabled) (In case we choose
not to remove it from base spec)
</t>
<t>
After some discussion we have this text on the table:
</t>
<t>
The following will be added to 8.0
Optional parameters that may be supported either per
connection or per implementation:
</t>
<t>
1) Delay Open flag
2) Delay Open Timer
3) Perform automatic start flag
4) Passive TCP establishment flag
5) BGP stop_peer_flag flag
6) Idle Hold timer
7) Perform automatic stop flag
8) Perform Collision detect in Establish mode flag
</t>
<t>
Sue accepted these changes.
</t>
<t>
Tom added this correction for item 2 in Sue's text:
</t>
<t>
2) Delay Open Timer
</t>
<t>
** Open Delay timer
** (for which we have consensus in Issue list v2 item 7)
</t>
<t>
Siva asked, and Sue accepted these additional changes:
</t>
<t>
9) accept connections from un-configured peers
5) BGP stop_peer_flap flag
</t>
<t>
We are at consensus on this.
</t>
<t>
This was discussed in the "Response to FSM input - Comments 1-10" thread:
Comment #3. This was also discussed in the "BGP Draft 19 - Close open
items 22" thread.
</t>
</section>
<section anchor="Event1/Event2 Clean Up" title="Event1/Event2 Clean Up">
<t>
Status: Consensus
<vspace />
Change: Yes
<vspace />
Summary: Use "Local system administrator" in both sections.
</t>
<t>
Discussion:
</t>
<t>
Siva proposed that we clean up the text for these Events by selecting
either "Administrator" or "Local system" but not both.
</t>
<t>
Sue proposed text using "Local system administrator" that was agreed on.
</t>
<t>
This was discussed in the "Response to FSM input - Comments 1-10" thread:
Comment #4.
</t>
</section>
<section anchor="Events 3, 5, 6 & 7 Give Examples" title="Events 3, 5, 6 & 7 Give Examples">
<t>
Status: Consensus
<vspace />
Change: No
<vspace />
Summary: Leave the examples out.
</t>
<t>
Discussion:
</t>
<t>
This began with Siva proposing we add examples for these event states.
Sue believes this is largely out-of-scope, but did agree to move
the example of "automatic stop" to the event description section.
She asked for proposed text for additional examples.
</t>
<t>
Sue replied that she has made the following changes, and asked if these
worked for Siva.
</t>
<t>
New text:
Event7: Automatic stop
</t>
<t>
Definition: Local system automatically stops the
BGP connection.
</t>
<t>
An example of an automatic stop event is
exceeding the number of prefixes for a given
peer and the local system automatically
disconnecting the peer.
</t>
<t>
</t>
<t>
Status: Optional depending on local system
</t>
<t>
Siva thought this for Event 7 was fine.
</t>
<t>
Sue replied to the list, saying that, previously examples had caused
dissension, and asked if there was a strong feeling either way.
</t>
<t>
Siva proposed this text for Events 3, 5 & 6:
</t>
<t>
Event 3:
Examples of this event are:
When a connection is terminated during exchange of Open
messages due to version failure
</t>
<t>
Event 5:
Examples of this event are:
Similar to Event 3
</t>
<t>
Event 6:
Examples of this event are:
Similar to Event 3 and
b) When a Idle Hold timer expires (within local limit)
</t>
<t>
Sue replied to this:
</t>
<t>
I'm going to leave the examples out of events 3, 4, 6 since
I've not heard any strong input on the mail list **and**
I had strong comments on prior versions of the draft.
I'd like to declare that issue 24 has consensus.
</t>
<t>
Siva agreed, we are at consensus on this issue.
</t>
<t>
This was discussed in the "Response to FSM input - Comments 1-10" thread:
Comment #5. This was also in the "Issue 25" thread, and the "Issue 25 -
this is really issue 24" threads. This is also in the "Draft 19 - Issue 24"
thread.
</t>
</section>
<section anchor="Event 4 & 5 Session Initiation Text" title="Event 4 & 5 Session Initiation Text">
<t>
Status: Consensus
<vspace />
Change: No
<vspace />
Summary: Leave the text as is.
</t>
<t>
Discussion:
</t>
<t>
This began with Siva wanting to change:
</t>
<t>
Definition: Local system automatically starts the
BGP session with the passive flag
enabled. The passive flag indicates
that the peer will listen prior to
establishing a connection.
</t>
<t>
to:
</t>
<t>
The passive flag indicates that the state machine will wait for
specified peer to initiate a connection with the local system. If
this does not happen within a specific time (hold time), the local
system will then also attempt to initiate connection with the
specified peer.
</t>
<t>
Sue replied:
</t>
<t>
The text in 8.2.1.1 indicates the definition of the passive flag.
6a)
==========
My understanding of your text is that you want to replace in both
sets of text:
</t>
<t>
"The passive flag indicates the peer will listen prior to
establishing a connection".
</t>
<t>
with:
</t>
<t>
"The passive flag indicates that the state machine will wait for the
specified peer to initiate a connection with a local system.
</t>
<t>
The problem with this sentence is that in the "unconfigured" case
the phrase "specified" peer is confusing. I think the original text
is clearer.
</t>
<t>
6b)
==========
If this does not happen within a specific time (hold time), the
local system will then also attempt to initiate (a) connection
with the specified peer.
My comments: Again, the "specified peer" term is confusing. Also,
the 2nd half of the statement mixes the actions of the state machine
with the events. I believe this muddies the text instead of
clarifying it.
</t>
<t>
Siva and Sue later agreed to leave the text the same because of the
Unconfigured + passive TCP connection + Delay Open situation.
</t>
<t>
This was discussed in the "Response to FSM input - Comments 1-10" thread:
Comment #6.
</t>
</section>
<section anchor="Event 4 & 5 - bgp_stop_flap option" title="Event 4 & 5 - bgp_stop_flap option">
<t>
Status: Consensus
<vspace />
Change: Yes
<vspace />
Summary: Add new event below.
</t>
<t>
Discussion:
</t>
<t>
This began with Siva asking:
</t>
<t>
Won't a variant of this with bgp_stop_flap option set be required ?
We can also achieve the same by using the bgp_stop-Flap option as a
flag that is provided as an input to the state machine.
</t>
<t>
Siva later clarified this to include:
</t>
<t>
We already have
Event 3 - Automatic Start
Event 5 - Automatic start with bgp_stop_flap option set
To make things consistent, shouldn't we either
a) Add 3 new events :
.in 24
1) Manual start with bgp_stop flap option set
2) Manual start with passive TCP establishment
and bgp_stop_flap option set
3) Automatic start with passive TCP establishment
and bgp_stop_flap option set
</t>
<t>
or
b) Remove Event 6, and rely on a flag to tell us wither peer flap
damping is to be performed for the session or not.
</t>
<t>
Sue said she preferred option A. And stated that #1 & #2 are infeasible,
but that we need to add #3.
</t>
<t>
Tom replied:
</t>
<t>
.in 4
But if we add an event, then we must add and agree on actions for all
six existing states so I think to say that adding a new event settle
things might be naive.
</t>
<t>
If we do add
3) Automatic start with passive TCP establishment and bgp_stop_flap
option set
</t>
<t>
which I understand is Sue's resolution, then for Idle state the
actions are straightforward but for the other five, is the event
completely ignored? If so, does it mean that the passive flag and the
bgp_stop_flap option are ignored and we carry on as if we were when we
were started which may have been without them. Or is the fact of
starting ignored but the flags remain set and so color the effect of
other events? Needs defining.
</t>
<t>
Jeff replied to this, quoting the existing draft:
</t>
<t>
The start events [Event 1, 3-6] are ignored in connect
state.
</t>
<t>
The start events [Event1, 3-6] are ignored in the Active
state.
</t>
<t>
The Start events [Event1, 3-6] are ignored in the OpenSent
state.
</t>
<t>
Any start event [Event1, 3-6] is ignored in the OpenConfirm
state.
</t>
<t>
Any start event (Event 1, 3-6) is ignored in the
Established state.
</t>
<t>
And elaborated, saying that:
</t>
<t>
.in 4
"ignore" means do nothing. This means don't twiddle with the flags. :-)
</t>
<t>
The text that was finally agreed on is:
</t>
<t>
Event 7: Automatic start with bgp_stop flap option set and
passive TCP establishment option set
Definition: Local system automatically starts the
.in 24
BGP peer connection with peer oscillation
damping enabled and passive TCP establishment
enabled. The exact method of damping
persistent peer oscillations is left up to the
implementation, and is outside the scope of
this document.
</t>
<t>
Status: Optional, used only if the bgp peer has
.in 24
enabled bgp peer oscillation damping with following optional
flags settings below.
</t>
<t>
Optional
attributes: 1) Perform automatic start flag SHOULD be set
2) BGP stop_peer_flap flag SHOULD be set
I've re-ordered the Timer events to keep the text changes
down to a minimum.
</t>
<t>
action 9 - connect retry timer
action 10 - Hold Timer expires
action 11 - Keepalive timer expires
action 13 - Open Delay timer expires
action 14 - Idle Hold timer expires
</t>
<t>
All other events are incremented by 1
</t>
<t>
This was discussed in the "Response to FSM input - Comments 1-10" thread:
Comment #7.
</t>
</section>
<section anchor="Event 5 Clarification" title="Event 5 Clarification">
<t>
Status: Consensus
<vspace />
Change: No
<vspace />
Summary: Leave the text as is.
</t>
<t>
Discussion:
</t>
<t>
This began when Siva asked that in event 5:
</t>
<t>
.in 4
Is it correct that this event will occur only when we want to restart
a connection (after it had been terminated due to some reason beside
administrative action) that we had accepted from an unconfigured peer ?
</t>
<t>
Sue replied:
</t>
<t>
.in 4
The automatic start function is an implementation specific mechanism.
This text does not seek to restrict it in any fashion.
</t>
<t>
Siva said that although he felt his original clarification would be more
useful to new implementors he is ok with the text as is.
</t>
<t>
This was discussed in the "Response to FSM input - Comments 1-10" thread:
Comment #8.
</t>
</section>
<section anchor="Timer Events Definition - Make Consistent" title="Timer Events Definition - Make Consistent">
<t>
Status: Consensus
<vspace />
Change: Yes
<vspace />
Summary: Change text to use "generate" across the board.
</t>
<t>
Discussion:
</t>
<t>
Can we use similar language for Events 8-12 to make them consistent?
</t>
<t>
It was agreed that we will use "generate" i.e.:
</t>
<t>
Event 8: An event generated when the Idle Hold timer expires.
Event 9: An event generated when the ConnectRetry timer expires.
Event 10: An event generated when the Hold timer expires.
Event 11: An event generated when the Keepalive timer expires
Event 12: An event generated when the Delay BGP Open timer expires.
This is at consensus.
</t>
<t>
This was discussed in the "Response to FSM input - Comments 1-10" thread
Comment #9.
</t>
</section>
<section anchor="Event 8 - Clean Up" title="Event 8 - Clean Up">
<t>
Status: Consensus
<vspace />
Change: Yes
<vspace />
Summary: Clean up first sentence. New text below.
</t>
<t>
Discussion:
</t>
<t>
Siva began this by asking if we could clean up the wording of Event 8.
</t>
<t>
After some discussion with Sue we are at this change for the first sentence:
</t>
<t>
An event triggered by the expiry of the Idle Hold timer, indicating
that the session has completed waiting for a back-off period to
prevent bgp peer oscillation.
</t>
<t>
This was discussed in the "Response to FSM input - Comments 1-10" thread:
Comment #10.
</t>
</section>
<section anchor="Hold Timer - Split?" title="Hold Timer - Split?">
<t>
Status: Consensus
<vspace />
Change: No
<vspace />
Summary: Keep the hold timer text as is.
</t>
<t>
Discussion:
</t>
<t>
Siva proposed that since:
</t>
<t>
.in 4
We use the hold timer for two purposes
</t>
<t>
* Waiting for an open message (with a default value of 240 seconds)
* Waiting for Keepalives (with a default value of 90 seconds)
</t>
<t>
Can we use two different timers (or at least call them two different
timer events) ?
</t>
<t>
Sue replied that this is not how it is implemented currently. Siva
replied that we have two conceptually different timers, but that
it would certainly work to only have one, since only one needs to be
running at any given time.
</t>
<t>
Tom agreed that we can keep things as is.
</t>
<t>
This was discussed in the "Comments 11-20" thread: Comment #11.
</t>
</section>
<section anchor="OpenDelay Timer Definition" title="OpenDelay Timer Definition">
<t>
Status: Consensus
<vspace />
Change: Yes - See issue 28
<vspace />
Summary: This is fixed by the fixing of issue 28.
</t>
<t>
Discussion:
</t>
<t>
This began with Siva's request that we add something to Event 12 to
specify what to do when the timer expires. This seems to have been
addressed in issue 28.
</t>
<t>
This was discussed in the "Comments 11-20" thread: Comment #12.
</t>
</section>
<section anchor="Definition of TCP Connection Accept (Event 13)" title="Definition of TCP Connection Accept (Event 13)">
<t>
Status: Consensus
<vspace />
Change: Yes
<vspace />
Summary: Change "Definition" text as indicated below.
</t>
<t>
Discussion:
</t>
<t>
Siva proposed that we change text from referring to "TCP connection request"
to "receiving a TCP connection". This led to this proposed text:
</t>
<t>
Definition: Event indicating the reception of a TCP connection
request with a valid source IP address and TCP
port, and valid destination IP address and
TCP Port. The definition of invalid source
address and port and invalid destination address
is left to the implementation.
</t>
<t>
This met with agreement.
</t>
<t>
This thread also discussed the idea of filtering the incoming address/port.
It was decided that this was implementation dependent.
</t>
<t>
This was discussed in the "Comments 11-20" thread: Comment #13.
</t>
</section>
<section anchor="Event 13 & 14 - Valid Addresses & Ports" title="Event 13 & 14 - Valid Addresses & Ports">
<t>
Status: Consensus
<vspace />
Change: Yes
<vspace />
Summary: See text at the end of the discussion.
</t>
<t>
Discussion:
</t>
<t>
With regard to Event 13 & 14, Siva raised questions about: 1) What does
it mean to validate a port, and 2) Should we state what we consider
an invalid IP address to be?
</t>
<t>
Sue replied that this is local policy and is implementation dependent.
Siva agreed regarding the source port & IP address, but disagreed about the
destination port. He argued that we need to know the destination port
for interoperability.
</t>
<t>
Sue asked Siva to provide some text.
</t>
<t>
After a long lull, Sue replied with:
</t>
<t>
I would like to keep the current text of
"Should" in the following text
"BGP's destination port SHOULD be port 179
as defined by IANA."
</t>
<t>
Should indicates that it normally should
be 179. If an implementation allows for
an alternative TCP port, it is still valid as the
"MUST" is not indicated.
</t>
<t>
There have been no further comments on this, the chairs have decided to close
it.
</t>
<t>
This was discussed in the "Comments 11-20" thread: Comment #14. This
was also in the "BGP-19: Issue 33" thread.
</t>
</section>
<section anchor="Event 17 - TCP Connection Fails to TCP Connection Termination" title="Event 17 - TCP Connection Fails to TCP Connection Termination">
<t>
Status: Consensus
<vspace />
Change: Yes
<vspace />
Summary: Change the text to "fails."
</t>
<t>
Discussion:
</t>
<t>
This began with Siva observing:
</t>
<t>
.in 4
This event can occur even when the transport connection is closed by
the other end. Since this does not reflect a 'failure ', can we change
the event name to
</t>
<t>
% Event17: TCP connection termination
</t>
<t>
Sue replied that:
</t>
<t>
Discussion: It both terminates from the remote site
and can "timeout" - fail.
Suggestions? I can use "disconnect", what do you think.
</t>
<t>
Siva replied that this was a minor issue, and on further reflection, either
"fails" or "disconnect" would be acceptable.
</t>
<t>
Sue replied that she has accepted Siva's comments, and the text will
be changed to "fails".
</t>
<t>
This was discussed in the "Comments 11-20" thread: Comment #15. This
was also discussed in the "BGP-19: Issue 34-35, 40-48" thread.
</t>
</section>
<section anchor="Making Definition Style Consistent" title="Making Definition Style Consistent">
<t>
Status: Consensus
<vspace />
Change: Yes
<vspace />
Summary: Adopt consistent style for the definition of events.
</t>
<t>
Discussion:
</t>
<t>
This started with Siva asking if we could make the definition style
consistent across events. Sue replied to this with text for 13-17,
Siva clarified that he was talking more about 18-21, and proposed
text.
</t>
<t>
We are agreed on the text for 13-17:
</t>
<t>
Event13: TCP connection indication and valid remote peer
</t>
<t>
Definition: Event indicating the local system reception
.in 24
of a TCP connection request with a valid source
IP address and TCP port, and valid destination
IP address and TCP Port. The definition of
invalid source, and invalid destination
IP address is left to the implementation.
</t>
<t>
BGP's destination port SHOULD be port
179 as defined by IANA.
</t>
<t>
TCP connection request is denoted by
the local system receiving a TCP SYN.
</t>
<t>
Status: Mandatory (Optional)
</t>
<t>
</t>
<t>
Event14: RCV TCP connection indication with invalid source or
destination
Definition: Event indicating the local system reception
of a TCP connection request with either
an invalid source address or port
number or an invalid destination
address or port number.
BGP destination port number SHOULD be 179
as defined by IANA.
</t>
<t>
Again, a TCP connection request
denoted by local system receiving a TCP
SYN.
Status: Mandatory (Optional)
Event15: TCP connection request sent received an ACK.
</t>
<t>
Definition: Event indicating the Local system's request
to establish a TCP connection to the remote
peer.
The local system's TCP session sent a TCP
SYN, and received a TCP SYN, ACK pair of
messages, and Sent a TCP ACK.
Status: Mandatory
Event16: TCP connection confirmed
Definition: Event indicates that the local system
receiving a confirmation that the TCP
connection has been established by the
remote site.
</t>
<t>
The remote peer's TCP engine sent a TCP SYN.
The local peer's TCP engine sent a SYN, ACK
pair, and now has received a final ACK.
Status: Mandatory
Event17: TCP connection fails
Definition: Event indicates that the local system has
received a TCP connection failure notice.
</t>
<t>
The remote BGP peer's TCP machine could have
sent a FIN. The local peer would respond
with a FIN-ACK. Another alternative is that
the local peer indicated a timeout in the
TCP session and downed the connection.
Status: Mandatory
</t>
<t>
Siva proposed these changes for 18-21:
</t>
<t>
Event18: BGPOpen
Definition: An event indicating that a valid Open
message has been received.
</t>
<t>
with
Event18: BGPOpen
Definition: An event is generated when a valid Open
message has been received.
</t>
<t>
Event19: BGPOpen with BGP Delay Open Timer running
Definition: An event indicating that a valid Open
message has been successful
established for a peer that is
currently delaying the sending of an
BGP Open message.
</t>
<t>
with
</t>
<t>
Event19: BGPOpen with BGP Open Delay Timer running
Definition: An event is generated when a valid Open
message has been received for a peer that
is currently delaying the sending of a
BGP Open message.
</t>
<t>
Editorial Note: "Delay Open Timer" replaced with "Open Delay Timer"
per issue 7.
Event20: BGPHeaderErr
Definition: BGP message header is not valid.
</t>
<t>
with
</t>
<t>
Event20: BGPHeaderErr
Definition: An event is generated when a received BGP
message header is not valid.
</t>
<t>
Event21: BGPOpenMsgErr
Definition: An BGP Open message has been received
with errors.
</t>
<t>
with
Event21: BGPOpenMsgErr
Definition: An event is generated when BGP Open message
with errors has been received.
</t>
<t>
Sue replied that she accepted Siva's comments, so we are at consensus
here.
</t>
<t>
This was discussed in the "Comments 11-20" thread: Comment #16. This
also came up in the "BGP-19: Issue 34-35, 40-48" thread.
</t>
</section>
<section anchor="Event 19 - Definition Cleanup" title="Event 19 - Definition Cleanup">
<t>
Status: Consensus
<vspace />
Change: Yes
<vspace />
Summary: Replace definition for Event 19 with the text in the discussion.
</t>
<t>
Discussion:
</t>
<t>
Siva proposed we replace:
</t>
<t>
.in 4
Definition: An event indicating that a valid Open
Message has been successful
established for a peer that is
currently delaying the sending of an
BGP Open message.
</t>
<t>
with:
</t>
<t>
.in 4
Definition: An event indicating that a valid OPEN
Message has been received for a peer
that has a successfully established
transport connection and is currently
delaying the sending of a BGP open
message
</t>
<t>
in Event 19. Sue agreed to the changes.
</t>
<t>
This was discussed in the "Comments 11-20" thread: Comment #17.
</t>
</section>
<section anchor="Event 22 - Cleanup" title="Event 22 - Cleanup">
<t>
Status: Consensus
<vspace />
Change: Yes
<vspace />
Summary: Replace Event 22 definition with the text from the discussion.
</t>
<t>
Discussion:
</t>
<t>
Siva began with observing:
</t>
<t>
Event22: Open collision discard
Definition: An event generated administratively
when a connection Collision has been
detected while processing an incoming
Open message. This connection has been
</t>
<t>
Isn't this event 'automatically' generated, since it is a system
generated event ?
</t>
<t>
Sue replied that:
</t>
<t>
response: How this generated is implementation specific. The
"administratively" is to cover policy.
</t>
<t>
</t>
<t>
Siva also proposed an editorial fix with:
</t>
<t>
Event 22 is an administrative could
occur if FSM is implemented as two
</t>
<t>
The word event is missing. How about
</t>
<t>
Event 22 is an automatic event that
could occur if FSM is implemented as two
</t>
<t>
Sue replied with this rewritten text:
</t>
<t>
Event22: Open collision dump
Definition: An event generated administratively
when a connection collision has been
detected while processing an incoming
OPEN message and this connection has been
selected to disconnected. See Section
6.8 for more information on collision
detection.
</t>
<t>
Event22 is an administrative based only
implementation specific policy. This
Event may occur if the FSM is implemented
as two linked state machines.
</t>
<t>
Siva agreed with this new text.
</t>
<t>
This was discussed in the "Comments 11-20" thread: Comment #18.
</t>
</section>
<section anchor="FSM Description - ConnectRetry Count" title="FSM Description - ConnectRetry Count">
<t>
Status: Consensus
<vspace />
Change: No
<vspace />
Summary: Leave the counter text alone, since it is used in peer oscillation
and will be in the MIB.
</t>
<t>
Discussion:
</t>
<t>
Siva opened with this question:
</t>
<t>
The Connect Retry count is updated by the FSM but never used. In the
absence of peer oscillation damping, will this be used to stop
connection establishment attempts after a certain maximum number ?
</t>
<t>
<Sue>
Yes, this is either implementation specific or
is it based on the peer oscillation damping draft.
</Sue>
</t>
<t>
Can we include the use of this counter in some place ?
</t>
<t>
<Sue>
Connect retry counter
1) Will be utilized by the peer oscillation damping
draft.
2) Will be included in bgp-4-mibv2-xx.
I just check and I didn't find it.
</t>
<t>
Do you still want text in the main?
</Sue>
</t>
<t>
To which Siva replied that he believes we can leave the main text alone.
</t>
<t>
This was discussed in the "Comments 11-20" thread: Comment #19.
</t>
</section>
<section anchor="Handling Event 7 (Auto Stop) to Idle State processing" title="Handling Event 7 (Auto Stop) to Idle State processing">
<t>
Status: Consensus
<vspace />
Change: Yes
<vspace />
Summary: Fix the text as indicated in the discussion.
</t>
<t>
Discussion:
</t>
<t>
Siva began with:
</t>
<t>
.in 4
The handling of Event 7 is missing from the Idle State processing. Can
we add this ? How about replacing
</t>
<t>
An manual stop event (Event2) is ignored in the Idle state.
</t>
<t>
with
</t>
<t>
Manual stop (Event 2) and Auto stop (Event 7) events are ignored
in the Idle state
</t>
<t>
Sue replied that she would add the text.
</t>
<t>
This was discussed in the "Comments 11-20" thread: Comment #20.
</t>
</section>
<section anchor="Clearing the Connection Retry Timer" title="Clearing the Connection Retry Timer">
<t>
Status: Consensus
<vspace />
Change: No
<vspace />
Summary: Leave things alone, since it is better to be redundant than to let
something slip through.
</t>
<t>
Discussion:
</t>
<t>
Siva opened with the observation:
</t>
<t>
.in 4
There are a few sections where the FSM draft states that the Connection
Retry timer needs to be reset, whereas the connect retry timer had been
cleared prior to entering that state. We can remove these instructions
to clear the connect retry timer.
</t>
<t>
List of places where the connect retry timer need not be cleared
</t>
<t>
a) Handling of Event 19 in the Connect State
b) Handling of Events 12 in the Active State
c) All cases where it is referred to in the OpenSent,
OpenConfirm and Established states
</t>
<t>
Sue replied:
</t>
<t>
Comment:
1) Does it hurt to have the connect retry timer cleared
at these points, since it has already been cleared.
</t>
<t>
I felt it eased the implementations to allow the action
routines to be shared across as many states as possible.
You can see this a bit more actively.
</t>
<t>
Tom replied to this:
</t>
<t>
.in 4
I propose we leave it in and close this issue.
</t>
<t>
1) To take out an action as redundant you need to be supremely
confident that it really cannot make a difference. I am not
(supremely confident); rather, the more I look at the FSM, the more
places I find where actions are missing, as I have posted to the list,
from obscure yet possible sequences of events and timing. And there
is an outstanding issue of mine which flagged seven places where the
next state was missing and so I think it impossible for any one to be
confident that any particular action is redundant until that is
cleared up and that is proving complex in some cases.
So, play safe, keep them in.
</t>
<t>
2) The argument for removing them is that the number of possible
distinct action lists is increased. True - it will mean that an
implementor will have to code more code when first implementing BGP.
</t>
<t>
For me this is no contest; keeping it safe at the possible cost of
redundancy outweighs the one-off cost of additional implementation.
</t>
<t>
So keep the actions in and close the issue.
</t>
<t>
Jeff replied that he agreed with Tom on this.
</t>
<t>
Siva concurred, that this approach was acceptable.
</t>
<t>
Unless someone objects, this issue is at consensus.
</t>
<t>
This was discussed in the "Comments 21-30" thread: Comment #21. This
is also discussed in the "BGP-draft-19: Issue 40 Clear Connect retry timer"
thread.
</t>
</section>
<section anchor="Handling of Event 14 in the Connect State" title="Handling of Event 14 in the Connect State">
<t>
Status: Consensus
<vspace />
Change: Yes
<vspace />
Summary: Make event 14 optional.
</t>
<t>
Discussion:
</t>
<t>
Siva opened the discussion with:
</t>
<t>
> If the transport connection receives an indication
> that is invalid or unconfigured. [Event 14]:
> - the TCP connection is rejected.
</t>
<t>
I don't understand how we would get this event while in this state.
</t>
<t>
Sue replied:
</t>
<t>
See my earlier comments (1-10) on the connection state.
It happens in implementations which track the TCP state more
closely. I suggest that Event 14 become optional.
</t>
<t>
Sue also suggested we fold this into the discussion about events 13-17,
which is tracked in issue 13.4.
</t>
<t>
Sue proposed:
</t>
<t>
My resolution: Let event 14 be optional.
Not all BGP implementations support it.
</t>
<t>
And asked if this let us reach consensus on this issue.
</t>
<t>
Siva agreed with this, we are at consensus on this.
</t>
<t>
This was discussed in the "Comments 21-30" thread: Comment #22. This was
also brought up in the "BGP-19: Issue 34-35, 40-48" thread.
</t>
</section>
<section anchor="Handling events 20, 21 in the Connect State and Active State" title="Handling events 20, 21 in the Connect State and Active State">
<t>
Status: Consensus
<vspace />
Change: Yes
<vspace />
Summary: Use the text Tom proposed in the discussion section.
</t>
<t>
Discussion:
</t>
<t>
Siva began this with:
</t>
<t>
We need to consider the case where we receive events 20 (message
header error) and 21 (Open message error) when the delay timer is
running.
</t>
<t>
Since the connection has been established at this point, we need to
send a Notification message and then terminate the connection.
</t>
<t>
To which Sue replied:
</t>
<t>
Alternative comments:
</t>
<t>
1) We have not sent an Open statement.
2) Why do we have to send an Notification? I see no justification
for it.
</t>
<t>
Suggestion:
Do you have implementations that send notification? Do
you know of others that don't.
</t>
<t>
Jeff saw this as indicative of an issue with section 4.2 the way it
is currently written:
</t>
<t>
>From section 4.2 of -18:
.in 4
4.2 OPEN Message Format
</t>
<t>
.in 7
After a TCP is established, the first message sent by each side is an
OPEN message. If the OPEN message is acceptable, a KEEPALIVE message
confirming the OPEN is sent back. Once the OPEN is confirmed, UPDATE,
KEEPALIVE, and NOTIFICATION messages may be exchanged.
</t>
<t>
This text implies that NOTIFICATIONs can only be sent once we
have sent an open and then a keepalive, generally meaning we're in the
Established state.
</t>
<t>
Anyone suggestions for modifying the wording?
</t>
<t>
Section 6.1 (Message header error) is one situation that implies
that a NOTIFICATION can be sent without sending even an OPEN message.
Note that since the base FSM implies that we send an OPEN message
immediately when we have a completed transport connection, we SHOULD
be in at least OpenSent. However, the DelayOpen timer means that we
MAY send a NOTIFICATION when we are in the Connect state.
</t>
<t>
GateD, at least, will not send a NOTIFICATION without first sending
an OPEN.
</t>
<t>
We need to pick one: You can send NOTIFICATIONS before OPEN or before
OPEN if the OpenDelay timer is running. However, we MUST fix the text
above.
</t>
<t>
Tom opined:
</t>
<t>
.in 4
A NOTIFICATION without a preceding OPEN is rather hard to interpret;
it is the OPEN that gives the recipient what it needs to know about
its potential peer (Version, AS number, ID, options etc) so it makes
sense to send an OPEN even if it is followed by a NOTIFICATION to say
goodbye :-( as opposed to a KEEPALIVE which says hello:-).
</t>
<t>
But as ever, what is implemented?
</t>
<t>
Yakov suggested these modifications to the text to resolve this:
</t>
<t>
.in 4
1. Delete the last sentence in the above paragraph
</t>
<t>
or
</t>
<t>
2. Delete "and NOTIFICATION" in the last sentence in the above paragraph
</t>
<t>
Jeff replied that he preferred the first option, and that the second could
be interpreted as NOTIFICATIONs not being legal, when, in fact, they may.
</t>
<t>
So the text on the table to resolve this is:
</t>
<t>
4.2 OPEN Message Format
</t>
<t>
.in 7
After a TCP is established, the first message sent by each side is an
OPEN message. If the OPEN message is acceptable, a KEEPALIVE message
confirming the OPEN is sent back.
</t>
<t>
However, this does not entirely clear up the original point about the
FSM. If we receive an error in Connect/Active, do we send a NOTIFY?
Do we preface it with an OPEN, so that OPEN/NOTIFY are sent in
immediate succession?
</t>
<t>
Sue replied:
</t>
<t>
.in 4
I suggest we don't send a "NOTIFICATION" when
Event 20 or Event 21 is received in Connect or Active state.
</t>
<t>
Tom responded to this issue with:
</t>
<t>
.in 4
Issue 42 queries whether or not we can send a NOTIFICATION when we
have not successfully exchanged OPENs. I propose we should, following
the suggestions of Jeff and Yakov.
</t>
<t>
As Yakov suggested, this requires the removal of the second sentence,
first paragraph, of 4.2 which implies a NOTIFICATION can only be sent
after a successful exchange of OPENs. I think this fits best with the
other references to the uses of NOTIFICATION in the draft.
</t>
<t>
In terms of the FSM, it means that in Connect and Active states, on
receipt of events 20 or 21, we should send a NOTIFICATION so that the
last section starting
</t>
<t>
In response to any other event.............
</t>
<t>
is replaced by (and noting we have agreed to drop references to MIB
actions)
</t>
<t>
If the BGP message header checking or OPEN message
checking detect an error (see Section 6.2) [Events 20 or 21],
the local system:
- sends a NOTIFICATION message with the appropriate
error code,
- resets the connect retry timer (sets to zero),
- releases all BGP resources,
- drops the TCP connection
- increments the ConnectRetryCnt (connect retry count)
by 1,
- [optionally] performs peer oscillation damping
- and goes to the Idle state.
In response to any other event (Events 7-8, 10-11,18, 22-27), the
local system:
- resets the connect retry timer (sets to zero),
- releases all BGP resources,
- drops the TCP connection,
- increments the ConnectRetryCnt (connect retry count)
by one,
- [optionally] performs peer oscillation damping,
- and goes to the Idle state
</t>
<t>
.in 4
(Note that this text is not quite watertight. Suppose we are in
Active state, having been started with CRT running, receive an SYN
(event 13), send SYN-ACK and then get a malformed message (events
20/21). We have not yet received an ACK and so should not send
anything over TCP; I would expect TCP to buffer this awaiting the ACK
except we then take down the TCP connection - or try to; I don't know
what happens next but regard it as sufficiently obscure not to be
concerned).
</t>
<t>
(My other concern is greater; why do we now not send NOTIFICATIONs for
other events; in Open Sent, Open Confirm or Established, we send one
for the 'default event list' so what makes events 20 and 21 in Active
and Connect so special? I can justify the absence of a NOTIFICATION
for events 7, 8, 10, 11, 18, 22 since there is no evidence of a TCP
connection to send it on; but events 23-27 in Active or Connect say we
have received an erroneous message, the TCP connection is there so why
not send a NOTIFICATION?
Event7: Automatic stop
Event8: Idle hold timer expires
Event10: Hold timer expires
Event11: Keepalive timer expires
Event18: BGPOpen
Event22: Open collision dump
Event23: NotifMsgVerErr
Event24: NotifMsg
Event25: KeepAliveMsg
Event26: UpdateMsg
Event27: UpdateMsgErr
</t>
<t>
Sue accepted Tom's text, so barring any objections, we are at consensus
on this.
</t>
<t>
This was discussed in the "Comments 21-30" thread: Comment #23. This
was also brought up in the "BGP-19: Issue 34-35, 40-48" thread, and
the "Draft bgp19 - issue #42 NOTIFICATION before OPEN" thread.
</t>
</section>
<section anchor="Handling the default events in the Connect state" title="Handling the default events in the Connect state">
<t>
Status: No Consensus
<vspace />
Change: Potentially
<vspace />
Summary: Add text at the end of the discussion.
</t>
<t>
Discussion:
</t>
<t>
Siva opened this with:
</t>
<t>
.in 4
The Open Delay timer [original: BGP Delay Open Timers) needs to be cleared
if it is running.
</t>
<t>
How about adding this:
</t>
<t>
% - If the ConnectRetry Timer is running
% - Clear the Connect Retry timer
% - Otherwise
% - Clear the Open Delay timer [original: BGP Delay Open Timer]
</t>
<t>
Sue replied that:
</t>
<t>
By the default you mean the text:
</t>
<t>
In response to any other events[Events 7-8, 10-11, 18,
20-27], the local system:
</t>
<t>
"resets" to me implies stops and clears. I think the
text is clear than the text above.
------------
Is this the replacement text you imply above:
- resets the connect retry timer (sets to zero),
- clears the Open Delay timer [original: BGP Delay timer] (sets to zero),
- increments the ConnectRetryCnt (connect retry count) by 1,
- [optionally] performs bgp peer oscillation damping, and
- goes to Idle text:
</t>
<t>
Editor's note: various incarnations of "Open Delay timer" have been replaced
with "Open Delay timer". See issue 7.
</t>
<t>
Sue replied that she accepted Siva's changes with these editorial changes:
</t>
<t>
old text:
- resets the connect retry timer (sets to zero)
- clears the open delay timer
</t>
<t>
new text:
- if the connect retry timer is running,
clear the connect retry timer (set to zero).
- if the open delay timer is running,
clear the open delay timer (set to zero).
</t>
<t>
Since the substantive changes have been accepted, unless someone objects,
this issue is at consensus.
</t>
<t>
This was discussed in the "Comments 21-30" thread: Comment #24. This
was also brought up in the "BGP-19: Issue 34-35, 40-48"
</t>
</section>
<section anchor="Handling Event 23 in Connect and OpenSent" title="Handling Event 23 in Connect and OpenSent">
<t>
Status: Consensus
<vspace />
Change: Yes
<vspace />
Summary: Adopt text at the end of the discussion section.
</t>
<t>
Discussion:
</t>
<t>
This began with Siva saying:
</t>
<t>
.in 4
This is currently being handled in the default event processing section.
However, we do not need to go through the peer oscillation damping
process in this case. Can we change the wordings to reflect this, or
move this out of peer oscillation damping processing ?
</t>
<t>
Sue replied:
</t>
<t>
1) There is no default event handling process in the text, you
will need to specify the text.
</t>
<t>
2) The state table below (hares-statemt-03.txt) states shows
the changes
</t>
<t>
-------------
<vspace />
Event 23
<vspace />
states:
<vspace />
current Idle Connect Active Open-Sent Open-Cnf Establish
-------------------------------------------------
<vspace />
next state Idle Idle Idle Idle Idle Idle
-------------------------------------------------
<vspace />
action V D D Y Y T
=================================================
</t>
<t>
V - Indicate FSM errors and ignore.
D - 1) resets the connect retry timer (sets to zero),
2) drops the TCP connection,
2) releases all BGP resources,
3) increments the ConnectRetryCnt (connect retry count) by 1,
4) [optionally] performs the bgp peer oscillation damping, and
Goes to Idle state.
Y 1) resets the connect retry timer (sets to zero),
2) Drops the TCP connection,
3) releases all BGP resources,
4) [optionally]
</t>
<t>
In an exchange between Siva and Sue, this came up:
</t>
<t>
Siva:
</t>
<t>
"Default event handling" was perhaps a poor choice of words.
</t>
<t>
What I meant is this
</t>
<t>
.in 4
Event 23 (Notify Message Version error) only indicates a version
mismatch. By going through action sequence D, we will be performing peer
oscillation damping. Should we perform damping, since this is not really a
cause for persistent oscillation ?
</t>
<t>
Also, since we have a distinct event to indicate a version error event,
can include text indicating that version negotiation processing should take
place upon receipt of this event ?
</t>
<t>
Sue:
</t>
<t>
Yes, we can change the "D" in state machine to a "y".
</t>
<t>
The issue is what if Connect state occurs and there is not
a TCP connection. Should an OPEN with wrong version
be accepted? If the Open Delay flag is off, the connection
state should not be getting an Open. The "D" action below
works for "open delay flag off".
</t>
<t>
The "y" action you suggest can occur if the open delay
timer is on.
</t>
<t>
If this is the issue, please confirm.
</t>
<t>
We could say: if open delay flag is on -> y action
if open delay flag is off -> D action
</t>
<t>
Please let me know if this is the concern, and suggest
text.
</t>
<t>
Prior to this exchange, this issue was at consensus. The only
thing that is firm in this exchange is changing "D" to "y". There
seems to be some open discussion still, so we'll reopen it.
</t>
<t>
After some discussion, this is the text we have settled on:
</t>
<t>
If a NOTIFICATION message is received with a version
error[Event24], the local system checks the Open Delay timer.
If the Open Delay timer is running, the local system:
- resets the connect retry timer (sets to zero),
- stops and reset the Open Delay timer (sets to zero,
- releases all BGP resources,
- drops the TCP connection,
- changes its state to Idle.
If the Open Delay timer is not running, the local system:
- resets the connect retry timer (sets to zero),
- releases all BGP resources,
- drops the TCP connection,
- increments the ConnectRetryCnt (connect retry count) by 1,
- optionally performs peer oscillation damping, and
- changes its state to Idle.
</t>
<t>
N.B. This is now event 24 (see issue 26).
</t>
<t>
We are at consensus with this.
</t>
<t>
This was discussed in the "Comments 21-30" thread: Comment #25. This was
also brought up in the "BGP-19: Issue 34-35, 40-48" thread.
</t>
</section>
<section anchor="Event 17 in the Connect state" title="Event 17 in the Connect state">
<t>
Status: Consensus
<vspace />
Change: Yes
<vspace />
Summary: Adopt text at the end of the discussion section.
</t>
<t>
Discussion:
</t>
<t>
This began with Siva asking:
</t>
<t>
.in 4
If the transport connection fails (timeout or transport
disconnect) [Event17], the local system:
- changes its state to Active.
</t>
<t>
If the transport connection fails when the Open Delay timer [original:
BGP Open Delay timer] is running, should we still be going into the
Active state ?
</t>
<t>
Sue replied referring to the discussion tracked in issue 13.4.
</t>
<t>
Jeff responded that:
</t>
<t>
.in 4
In this particular case, I think the issue is separate from the issues
for events 13-17 since this isn't particular to how deep the BGP
implementation meddles in the TCP implementation.
</t>
<t>
If we are in the Connect state, because we have an incoming transport
connection that has completed, but we have the OpenDelay timer
running and the transport connection is closed, we can simply
drop into Active after resetting the ConnectRetry timer and clearing
the OpenDelay timer (if set/exists). In the case of an unconfigured
peer, we can discard the FSM instance.
</t>
<t>
Tom replied that he agreed with this.
</t>
<t>
Tom then proposed this text:
</t>
<t>
If the TCP connection fails[Event 17] and the Open Delay
timer is running, the local system:
- restarts the connect retry timer,
- clears the Open Delay timer
- continues to listen for a connection that may be
initiated by the remote BGP peer, and
- changes its state to Active.
</t>
<t>
If the TCP connection fails [Event17] and the Open Delay
timer is not running, the local system:
- drops the TCP connection,
- releases all BGP resources,
- sets ConnectRetryCnt (the connect retry count) to zero
- resets the connect retry timer (sets to zero), and
- goes to Idle state.
</t>
<t>
to replace
If the TCP connection fails (timeout or disconnect)
[Event17], the local system:
- restarts the connect retry timer,
- continues to listen for a connection that may be
initiated by the remote BGP peer, and
- changes its state to Active.
</t>
<t>
Sue agreed to change the text to reflect the comments.
</t>
<t>
Jeff brought out a couple of other concerns, and Tom replied:
</t>
<t>
> If the TCP connection fails [Event17] and the Open Delay
> timer is not running, the local system:
> - drops the TCP connection,
> - releases all BGP resources,
</t>
<t>
.in 4
There are no resources to release while in the connect state.
(Unless we're using this as shorthand for something else - I forget.)
</t>
<t>
Tom:
</t>
<t>
.in 4
I was unsure about this action. It is present for Active state event
17 which is why I put it in, it does include sub-actions such as clear
Open Delay timer (not running), clear Connect Retry timer (could be
running) so I think it right to play safe and include it.
</t>
<t>
Jeff:
</t>
<t>
> - sets ConnectRetryCnt (the connect retry count) to zero
</t>
<t>
I'm forgetting if this action is consistent with everything else.
I don't have a current copy of the FSM and I don't trust -18 to be
current enough. :-)
This said, why do we go to zero? I could see not incrementing it
and letting the normal decay process deal with it. The same would
apply for the above.
</t>
<t>
Tom:
</t>
<t>
.in 4
Again, I was unsure about this so put it in and waited for comment. I
have a chart of 27 events and 6 states in which I have colored in the
connect retry and peer oscillation damping actions and it looks like
measles; I could not divine the underlying logic. Incrementing the
connect retry count would make as much if not more sense to me. (It
is zeroed for Manual Stop).
</t>
<t>
But the action '[optionally] perform peer oscillation damping' is yet
more erratic (eg for event 10 - Hold Timer expired - it is performed
exiting Connect, Active, Established but not Open Confirm or Open Sent)
so I left it out. Again, it might make more sense put it in.
</t>
<t>
Sue replied to this:
</t>
<t>
The connect state could have a few resources
(minimum peer footprint) as the FSM goes
from Idle to Connected state. While this amount
of BGP resources is not as much as the final
amount, it still needs to get released.
</t>
<t>
2nd - I think the ConnectRetry count should be removed;
Thanks for catching that.
</t>
<t>
Please confirm that part #1 is OK with you so we can
put issue 45 into consensus state.
</t>
<t>
Sue accepted Tom's solution, for the following text:
</t>
<t>
If the TCP connection fails [Event18], the local system checks
the Open Delay Timer. If the Open Delay timer is running,
the local system:
- restarts the connect retry timer,
- stops the Open Delay timer and resets value to zero,
- continues to listen for a connection that may be
initiated by the remote BGP peer, and
- changes its state to Active.
If the open Delay timer is not running, the local system:
- resets the connect retry timer (sets to zero), and
- Drops the TCP connection,
- Releases all BGP resources,
- and goes to Idle State.
</t>
<t>
N.B. This is now event 18 (see issue 26).
</t>
<t>
We are at consensus with this.
</t>
<t>
This was discussed in the "Comments 21-30" thread: Comment #26. This
was also brought up in the "BGP-19: Issue 34-35, 40-48" thread.
</t>
</section>
<section anchor="Handling of Event 17 in Active state" title="Handling of Event 17 in Active state">
<t>
Status: Consensus
<vspace />
Change: No
<vspace />
Summary: See issue 13.4, this issue closed in favor of that one.
</t>
<t>
Discussion:
</t>
<t>
This began with Siva saying:
</t>
<t>
We should now move into Idle state. Can we add
</t>
<t>
% - Goes to Idle state
</t>
<t>
Sue replied that she thought this should be bundled in with the issue
tracked in 13.4. Since no one objected, this issue has been closed
in favor of that one.
</t>
<t>
This was discussed in the "Comments 21-30" thread: Comment #27.
</t>
</section>
<section anchor="Handling of Event 19 in Active state" title="Handling of Event 19 in Active state">
<t>
Status: Consensus
<vspace />
Change: Yes
<vspace />
Summary: Add the new text in the discussion section.
</t>
<t>
Discussion:
</t>
<t>
This began with Siva suggesting:
</t>
<t>
> - Set the Hold timer to a large value (4 minutes),
Since OPEN messages have been exchanged, can we change this to
- If the negotiated Hold time is not 0, set the Hold time to
- the negotiated value
</t>
<t>
Sue replied that:
</t>
<t>
The text in Active and Open Sent needs to be the same.
The text in Open Sent is:
- sets the Hold timer according to the negotiated value
(see section 4.2), and
</t>
<t>
Which text do you prefer?
</t>
<t>
Sue replied that this text would be added to the next draft:
</t>
<t>
New text
</t>
<t>
- if the hold timer value is non-zero,
- starts the keepalive timer to initial value,
- resets the hold timer to the negotiated value,
- else if the hold timer is zero
- resets the keepalive timer (set to zero),
- resets the hold timer to zero.
</t>
<t>
This seems to address Siva's concerns, this issue is at consensus, if
there are objections, we can reopen it.
</t>
<t>
This was discussed in the "Comments 21-30" thread: Comment #28. This
was also brought up in the "BGP-19: Issue 34-35, 40-48" thread.
</t>
</section>
<section anchor="Handling of Event 2 in Active state" title="Handling of Event 2 in Active state">
<t>
Status: Consensus
<vspace />
Change: Yes
<vspace />
Summary: Update the draft with the text at the end of the discussion section.
</t>
<t>
Discussion:
</t>
<t>
Siva opened with:
</t>
<t>
> A manual stop event[Event2], the local system:
> - Sends a notification with a Cease,
> - drops the Transport connection
</t>
<t>
These two actions are possible only if a transport connection had
already been established. How about changing the text to
</t>
<t>
% - If a transport connection had been successfully established
% - Send a Notification with a Cease
% - Drop the Transport Connection
</t>
<t>
Sue counter suggested:
</t>
<t>
A manual stop event [Event 2], the local system
- Drop the TCP connection,
- Release all BGP resources,
- resets the connection retry timer [sets to zero],
- goes to Idle.
</t>
<t>
Jeff replied:
</t>
<t>
I'm rather confused. Under exactly what circumstances can we be
in the Active state and have an active TCP connection at all?
Ditto for having any BGP resources?
</t>
<t>
Going to Idle is fine.
</t>
<t>
Tom offered this example:
</t>
<t>
eg start with passive flag, TCP SYN received, SYN-ACK sent, ACK
received, Delay Open flag set and there we are. Most events are now
possible either from a well-implemented remote peer or a badly
implemented remote peer.
</t>
<t>
Sue asked if there were any additional comments, if not, the text will
be:
</t>
<t>
A manual stop event[Event2], the local system:
- Sends a NOTIFICATION with a Cease,
- releases all BGP resources including
- stopping the Open delay timer
- drops the TCP connection,
- sets ConnectRetryCnt (connect retry count) to zero
- resets the connect retry timer (sets to zero),
- changes its state to Idle.
</t>
<t>
There have been no additional comments, we will use the text Sue proposed.
</t>
<t>
This was discussed in the "Comments 21-30" thread: Comment #29. This was
also brought up in the "BGP-19: Issue 34-35, 40-48" thread.
</t>
</section>
<section anchor="Default Event handling in Active state" title="Default Event handling in Active state">
<t>
Status: Consensus
<vspace />
Change: No
<vspace />
Summary: No routes in active.
</t>
<t>
Discussion:
</t>
<t>
Siva began with:
</t>
<t>
To ensure consistency with E2 handling, can we add
</t>
<t>
% - If any BGP Routes exist, delete the routes
</t>
<t>
Sue replied:
</t>
<t>
Comment: Yakov and Jeff noted, there are no routes in Active state.
</t>
<t>
Since there were no responses disagreeing, we'll consider this closed
unless someone wants to open it back up.
</t>
<t>
This was discussed in the "Comments 21-30" thread: Comment #30.
</t>
</section>
<section anchor="Clearing Hold timer in OpenSent, OpenConfirm and Established State" title="Clearing Hold timer in OpenSent, OpenConfirm and Established State">
<t>
Status: Consensus
<vspace />
Change: No
<vspace />
Summary: This issue is addressed in the "Clear BGP resources"
</t>
<t>
Discussion:
</t>
<t>
This began with Siva stating:
</t>
<t>
.in 4
In all event handling where we go to Idle state, we need to clear the
Hold Timer as well.
</t>
<t>
Sue replied that:
</t>
<t>
issue resolve one way last Jan - March
Clearing of keep alive timer included
in Clear BGP resources
</t>
<t>
No response to this yet, but since this seems to be resolved it is
at consensus unless someone objects.
</t>
<t>
This was discussed in the "Comments 30-36" thread: Comment #31.
</t>
</section>
<section anchor="Clearing Keepalive timer in OpenConfirm and Established State" title="Clearing Keepalive timer in OpenConfirm and Established State">
<t>
Status: Consensus
<vspace />
Change: No
<vspace />
Summary: This issue is addressed in the "Clear BGP resources"
</t>
<t>
Discussion:
</t>
<t>
This began with Siva stating:
</t>
<t>
.in 4
In all event handling where we go to Idle state, we need to clear the
Keepalive Timer as well.
</t>
<t>
Sue replied that:
</t>
<t>
issue resolve one way last Jan - March
Clearing of keep alive timer included
in Clear BGP resources
</t>
<t>
No response to this yet, but since this seems to be resolved it is
at consensus unless someone objects.
</t>
<t>
This was discussed in the "Comments 30-36" thread: Comment #32.
</t>
</section>
<section anchor="Handling Event 18 in the OpenSent state (Keepalive Timer)" title="Handling Event 18 in the OpenSent state (Keepalive Timer)">
<t>
Status: Consensus
<vspace />
Change: Yes
<vspace />
Summary: Make the event optional.
</t>
<t>
Discussion:
</t>
<t>
This began with Siva asking:
</t>
<t>
.in 4
Why do we start the Keepalive timer at this stage ? Isn't it sufficient to
do so when we move into Established state ?
</t>
<t>
Sue replied:
</t>
<t>
An earlier comment from Tom (and you) requested the following:
</t>
<t>
<--Open
[Open sent state]
</t>
<t>
Open-->
[Event 18]
</t>
<t>
<---Open
<---Keepalive
[Action from Event 18 in Open Sent]
[Open Confirm]
Keepalive -> [Event 25]
[established]
</t>
<t>
What do implementations do? We'll have to query implementations.
</t>
<t>
Jeff added:
</t>
<t>
I'm assuming the second OPEN going from right to left is a typo.
If it isn't, thats a FSM error to the peer on the left.
</t>
<t>
Theoretically, an implementation that utilizes its keepalive timer
to send the first keepalive to transition to Established is
still interoperable. However:
</t>
<t>
o Keepalives can be disabled by negotiating hold time of zero
o We really shouldn't need to restart the Keepalive timer.
If there is a delay in the keepalive that transitions from
OpenConfirm to Established, its due to the transport connection.
It should be reliable and it *should* get through. If it
doesn't, there's other problems and the hold timer for the
peer on the right should do the Right Thing and drop the
connection.
</t>
<t>
> What do implementations do? We'll have to query implementations.
</t>
<t>
.in 4
GateD at least waits to enter the Established state prior to starting
the KeepAlive timer.
</t>
<t>
Tom also added:
</t>
<t>
.in 4
My comment was that if we do not send a KeepAlive (and start the
KeepAlive timer), on exiting from Active with Event 19 to OpenConfirm
then we never will and the connection will die. Open Confirm state
means valid Open received so we must send a KeepAlive to acknowledge
the Open (as pointed out in Jeff's other posting) and we never do it
in OpenConfirm state itself (unless the KeepAlive timer expires which
it cannot because we have not started it).
</t>
<t>
So for me, OpenSent state Event 18 was and is correct, sending the
KeepAlive without which the connection goes no further and Active
state Event 19 needs to be brought into line.
</t>
<t>
To say that the timer is started when entering Established state is
fine except for a slight problem; we have no way in this FSM of
defining actions that are taken on entering a state, only actions to
be taken on leaving another state so that is why the KeepAlive actions
need to be where they are (or are not in the case of Active state
Event 19).
</t>
<t>
Sue replied, asking more implementors to chime in on what they do for
this part of the FSM.
</t>
<t>
Curtis replied that we should:
</t>
<t>
.in 4
Make it optional. Timing out in open or open-sent has never been much
of an issue, so whether one or three keepalive get sent shouldn't be a
hot topic.
</t>
<t>
Sue said that this was fine, and she would work on text specifying optional.
</t>
<t>
Jeff replied regarding GateD's behavior:
</t>
<t>
.in 4
GateD will start its keepalive timer while in this state, so multiple
keepalives will be sent.
</t>
<t>
As someone previously said, this is a "yawn" issue. But to choose one
way or the other, we may potentially make someone in non-compliance.
</t>
<t>
From the closure of issue 12, we have this text, which discusses Keepalives
to consider in relation to the other keepalive issue here:
</t>
<t>
Change 1: new text
</t>
<t>
Active state - event 19
</t>
<t>
If an Open is received with the Open Delay timer is
running [Event 19], the local system
- clears the connect retry timer (cleared to zero),
- stops and clears the Open Delay timer
- completes the BGP initialization,
- stops and clears the Open Delay timer
- sends an OPEN message,
- send a Keepalive message,
- if the hold timer value is non-zero,
- starts the keepalive timer to initial value,
- resets the hold timer to the negotiated value,
else if the hold timer is zero
- resets the keepalive timer (set to zero),
- resets the hold timer to zero.
</t>
<t>
- changes its state to OpenConfirm.
</t>
<t>
.in 7
If the value of the autonomous system field is the same as the local
Autonomous System number, set the connection status to an internal
connection; otherwise it is "external".
</t>
<t>
Since there were no more comments, this is at consensus.
</t>
<t>
This was discussed in the "Comments 30-36" thread: Comment #33. And
in the "BGP-draft-19: Issue 52 - Event 18 in OpenSent State (Keepalive
timer set)" thread.
</t>
</section>
<section anchor="Established State MIB" title="Established State MIB">
<t>
Status: Consensus
<vspace />
Change: No
<vspace />
Summary: MIB references pulled in favor of having them in the MIB document.
See issue 8.
</t>
<t>
Discussion:
</t>
<t>
This began with Siva asking:
</t>
<t>
.in 4
Some event handling in the Established state do not set the MIB Reason
when handling an event that causes an error. Can we add this ?
</t>
<t>
Sue replied that we have pulled the MIB wording from the FSM. See issue 8.
</t>
<t>
This was discussed in the "Comments 30-36" thread: Comment #34.
</t>
</section>
<section anchor="State impact of not supporting Optional Events" title="State impact of not supporting Optional Events">
<t>
Status: Consensus
<vspace />
Change: Yes
<vspace />
Summary: Add the text at the end of the discussion section.
</t>
<t>
Discussion:
</t>
<t>
Siva stated that:
</t>
<t>
.in 4
For the events whose status is optional, can we state the impact of not
supporting them (in terms of any interoperability issues). I understand
that most of the optional events will not have such an impact; but a
clarification statement for the optional events would benefit new
implementors.
</t>
<t>
Sue responded:
</t>
<t>
Much of the support of optional parameters depends on policy.
I could put a short note about the optional events and
parameters as part of 8.1.5 or 8.2.1.3
</t>
<t>
I think it fits better in 8.1.5.
Optional: Events: 3-8, 12, 13-14[my suggestion]
19, 22
Timers: Idle Hold Timer
Open Delay Timer
</t>
<t>
Required flags for optional parameters:
Open Delay Flag
BGP Stop Flap
</t>
<t>
Sue said she would try to work up more if it is agreed that this is on
the right track.
</t>
<t>
Sue provided this text to clarify the behavior associated with Optional
Attributes:
</t>
<t>
8.2.1.3 FSM and Optional Attributes
</t>
<t>
Optional Attributes specify either flags that augment the normal
processing of the BGP FSM, or optional timers. If a Optional
attribute can be set on a system, the Events and the BGP FSM actions
must be support. For example, if the following options can
be set in a BGP implementation: AutoStart and Passive TCP connection
Establishment flag, then the events 3, 4 and 5 must be supported.
</t>
<t>
If an Optional attribute cannot be set (that is declared always off
logically), the events supporting that set of options do not
have to be supported.
</t>
<t>
This was discussed in the "Comments 30-36" thread: Comment #35.
</t>
</section>
<section anchor="New DelayOpen State" title="New DelayOpen State">
<t>
Status: Consensus
<vspace />
Change: No
<vspace />
Summary: We've chosen not to reopen the debate about adding a DelayOpen
State to the FSM.
</t>
<t>
Discussion:
</t>
<t>
Siva began with asking:
</t>
<t>
.in 4
Is delaying the sending of an OPEN message a standard industry practice ?
</t>
<t>
Also, in the FSM, this has been handled by practically implementing a
sub-state each, within the CONNECT and ACTIVE states. Won't the FSM
look more simple if we just had a new DelayOpen state that we could
move into ?
</t>
<t>
Sue responded that this was something we have tried to do before, but that
it spawned some degree of rabid response on both sides. Given our current
mandate to stick with what is implemented, it is probably best not to
reopen this debate.
</t>
<t>
Unless someone badly wants to reopen this debate, the issue is at Consensus.
</t>
<t>
This was discussed in the "Comments 21-30" thread: Comment #22.
<vspace />
This was discussed in the "Comments 21-30" thread: Comment #26.
<vspace />
This was discussed in the "Comments 30-36" thread: Comment #36.
</t>
</section>
<section anchor="Clarify what is covered in the base document" title="Clarify what is covered in the base document">
<t>
Status: Consensus
<vspace />
Change: Yes
<vspace />
Summary: Add the text at the end of the discussion to clarify what is
documented where with regard to BGP and its extensions.
</t>
<t>
Discussion:
</t>
<t>
This grew out of a discussion on how to use BGP Identifiers in an IPv6-only
environment. In that discussion it became clear that the way the documents
are currently structured it is not clear to new readers that extension
specifications can and do specify behavior that supersedes the behavior
specified in the base spec. To that end it was agreed that this text should
be added:
</t>
<t>
.in 5
This document specifies the base behavior of the BGP protocol. This
behavior can and is modified by extension specifications. When the
protocol is extended the new behavior is fully documented in the
extension specifications.
</t>
<t>
This was discussed in the "Next-Hop in IPv6 only environments" thread.
</t>
</section>
</section>
<section title='Security Considerations' anchor='sec-con'>
<t>
This document is an informational document that discusses the changes made in revising the BGP-4 specification. There are no security considerations applicable to this document.
</t>
</section>
</middle>
<back>
<references title='Normative References'>
<?rfc include="reference.RFC.1771"?>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 16:27:28 |