Subject: Comments on BGP Draft 20.....

From: Russ White <[email-masked]>
Date: Fri, 9 May 2003 10:13:14 -0400 (Eastern Daylight Time)

Some of these are going to echo Alex's comments, but that's okay, I think.
Mostly just nits....

:-)

Russ

__________________________________
[email-masked] CCIE <>< Grace Alone

-----

Abstract:

This information is sufficeint to construct a graph of the AS connectivity
from which routing loops may be pruned and some policy decisions at the AS
level may be enforced.

UPDATE Message Format:

The information in the UPDATE message can be used to construct a graph
describing the relationships of the various Autonomous Systems.

In both cases this is true, I suppose, but in neither case does this really
describe what the AS Path is used for, right? I would think we'd want to
describe it less in terms of a "graph of the connectivity in the
internetwork," and more in terms of "a graph of the path through Autonomous
Systems ued to reach the destination advertised." It could be confusing,
since there isn't anyplace where we discuss building a graph of
inconnectivity between the Autonomous Systems....

-----

Forwarding Paradigm:

This document uses the term "Autonomous System" (AS)  throughout....

This entire paragraph is a repeat--I'd leave it just in the definitions.

-----

Forwarding Paradigms:

The initial data flow....

This paragraph has two different thoughts in it, one about incremental
updates, and the other about keeping data that you've received. It seems
like just putting a return after "as the routing tables change."

-----

Forwarding Paradigms:

The paragraph starting "KEEPALIVE messages" should, I think, be moved up
above the section on route exchange. I don't know why, it just seems less
like it's jumping all over the place that way.

-----

3.1 Routes: Advertisement and Storage

It almost seems like the section about The initial data flow should maybe
be put entirely under this section someplace (?).

The first paragraph in this section is really a definition of a route vs a
prefix, and should probably be in the definitions.

The paragraph "Changing attribute of a route...." needs a "the," or
attribute needs an "s."

-----

3.2 Routing Information Bases

b) Loc-RIB....

I think it might be useful to state the contents of the Loc-RIB are
actually installed in the local routing table, and thus used for forwarding
packets on this router. I don't see anyplace this connection is made
explicit, it seems more like it's implicit throughout the doc.

-----

Page 18, a) LOCAL_PREF

"....to inform other peers...." should be "....to inform its other
peers...."

-----

Network Layer Reachability Information

"This varibale length field contains a list of IP address prefixes."

I think we can kill "address" here.

a) Length

"The Length field inidicates...." The sentence can start with
"Indicates..."

b) Prefix

"The Prefix field indicates...." The sentence can start with
"Indicates...."

-----

Network Layer Reachability Information

"An UPDATE message can list multiple routes to be withdrawn...."

Actually, we don't withdraw routes, we withdraw prefixes, right? The next
paragraph shows this confusion, by talking about routes without attributes,
but routes are prefixes combined with attributes, so.... They aren't
routes, they're prefixes. You remove routes based on withdrawn prefixes, I
think.

------

5. Path Attributes

"Well-known attributes MUST be recognized by all BGP implementations."

This sentence, as strange as it may sound, implies it's the attributes
fault if the BGP implementation doesn't recogonize it, that it's up to the
attribute definers to, in some way, make certain that BGP implementations
will recognize it. I think it should probably be worded the other way
'round:

"BGP implementations MUST recognize all well-known attributes."

-----

5. Path Attributes

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

This just seems a little rough. Maybe this:

"Once a BGP peer has updated any well-known attributes, it MUST pass these
attributes in any updates it transmits to its peers."

-----

5.1.1 ORIGIN

"Its value SHOULD NOT be changed by any other speaker."

I really think this should be "MUST NOT." I can't think of any reason it
wouldn't be, except in the case of aggregation, and that case could be
mentioned here as the only known exception (?).

---

From: Yakov Rekhter <[email-masked]>
Date: Tue, 20 May 2003 09:35:07 -0700

Russ,

> Some of these are going to echo Alex's comments, but that's okay, I think.

Thanks for the comments. My response is in-line...

> describe what the AS Path is used for, right? 

Wrong. As the abstract states quite clearly that this information is used
to prune routing loops and make some policy decisions at the AS level.

> I would think we'd want to

The definition section suppose to have a *summary* of the definitions
used in the spec.

> like just putting a return after "as the routing tables change."

The two are related, as the reason for keeing updates you've received
is because the exchange of information is based on incremental updates.

> like it's jumping all over the place that way.

Disagree.

> prefix, and should probably be in the definitions.

see above.

> The paragraph "Changing attribute of a route...." needs a "the," or

Ok.

> explicit, it seems more like it's implicit throughout the doc.

Please propose the text.

> "....to inform other peers...." should be "....to inform its other

Sure.

> I think we can kill "address" here.

Sure.

> "The Length field inidicates...." The sentence can start with

I prefer to keep the current text.

> "The Prefix field indicates...." The sentence can start with

Ditto.

> routes, they're prefixes. You remove routes based on withdrawn prefixes, I

We withdraw routes. The way BGP withdraws routes is by advertising
the NLRI field of these routes in the Withdrawn Routes field of
the UPDATE message. And that is precisely what the text said:

   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.

> "BGP implementations MUST recognize all well-known attributes."

Sure.

> attributes in any updates it transmits to its peers."

Sure.

> mentioned here as the only known exception (?).

Please propose the text.

Yakov.

---

From: Russ White <[email-masked]>
Date: Tue, 20 May 2003 13:44:16 -0400 (EDT)

> to prune routing loops and make some policy decisions at the AS level.

Yes, but it's not used for inscribing a graph of interconnectivity between
the AS' in the internetwork, is it? It can be used for that, I suppose, so
the text is fine, but it's not used for that--I think that's what's
confusing about it.

> > explicit, it seems more like it's implicit throughout the doc.

Okay:

The Loc-RIB contains routes which are installed in the local routing table
and used for forwarding packets received, based on the destination address,
by the router.

>    BGP speaker - BGP speaker connection to which it has been previously

Hmmm... So, if you receive an update with no attributes, just prefixes in
the withdrawn section, you won't consider that a withdraw, and remove the
routes you have from the sending peer from the local tables?

A route without the attributes is a prefix. :-)

It depends on whether you are thinking of it in terms of what you're
sending, or what you're causing on the receiver.

> > mentioned here as the only known exception (?).

It's value MUST NOT be changed by any other speaker.

:-)

Russ

---

From: Jeffrey Haas <[email-masked]>
Date: Tue, 20 May 2003 14:05:12 -0400

> the text is fine, but it's not used for that--I think that's what's

Perhaps to elaborate on Russ's point, the AS Path gives us the 
graph for this prefix.  Even with a collection of a bunch of routes,
we're not guaranteed to have the Internet's AS graph.

The text is a *little* vague in this context, but I can't think
of better wording.

-- 
Jeff Haas 
NextHop Technologies

---

From: Russ White <[email-masked]>
Date: Tue, 20 May 2003 14:08:18 -0400 (EDT)

> The text is a *little* vague in this context, but I can't think

I agree--I've been trying to come up with a better wayh of working it, but
I can't think of one. I'd say it's too much of a nit to worry about it .

:-)

Russ

---

From: Yakov Rekhter <[email-masked]>
Date: Tue, 20 May 2003 11:10:37 -0700

Russ,

> > > In both cases this is true, I suppose, but in neither case does this 
> > > really describe what the AS Path is used for, right?
> >

In the absence of any objections within a week I'll put this in the text.

> It's value MUST NOT be changed by any other speaker.

In the absence of any objections within a week I'll put this in the text.

Yakov.

---

From: Jeffrey Haas <[email-masked]>
Date: Tue, 20 May 2003 14:28:28 -0400

> In the absence of any objections within a week I'll put this in the text.

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

I think the existing text is fine.  The gotcha is one has to read ahead
a bit in the document to find the bit I just quoted.

> In the absence of any objections within a week I'll put this in the text.

Good grief.

I refer all parties concerned back to the thread titled "Re: issue 32.1",
specifically the consensus mail from Andrew with message-id:
<[email-masked]

Short summary:
1. You shouldn't change it.
2. People *do* change it, and do so for policy reasons.
3. You shouldn't change it, but since people do, we're going to tell
   you that you shouldn't and thus imply that you can if you really
   want to. :-)

My own preference was to *not* change it and MUST would be fine with me,
but consensus was previously reached.

-- 
Jeff Haas 
NextHop Technologies