Subject: [bmwg] Re: draft-ietf-bmwg-conterm-03.txt

From: Randy Bush <[email-masked]>
Date: Tue, 13 Aug 2002 16:34:49 -0700

could you folk please address these classes of issues and resubmit?

randy

---

From: Alex Zinin <[email-masked]>

  I'm reviewing the doc at the moment and one major thing
  that struck me right away is that I would expect a "terminology"
  document to be very careful about properly introducing
  terms before using them, etc., while this is not the case.
  Below's what I found in the first couple of pages. Should I
  keep reviewing it? ;)

Alex

> 2.1 BGP Instance or Device
> 
>    Definition:
>               A BGP instance is a process with a single Loc-RIB that
>               runs on a BGP device.

Note that Loc-RIB has not been defined.

>    Discussion:
>               We have chosen to use "device" as the general case, to
>               deal with the understood [e.g. [9]] and yet-to-be-invented
>               cases where the control processing may be separate from
>               forwarding [12].  A BGP device may be a traditional
>               router, a route server, a BGP-aware traffic steering
>               device, a device using BGP to exchange topology
>               information with a GMPLS environment, etc.

"exchange topology info with a GMPLS environment" sounds weird a bit.
First, BGP does not provide topology discovery, we also don't have
standards to use BGP in GMPLS... I would add "a (potentially non-forwarding)
BGP route-reflector", though.

> A device such
>               as a route server, for example, never forwards traffic, so
>               forwarding-based measurements would be meaningless for it.
> 
>    Measurement units: N/A
> 
>    Issues:
> 
>    See Also:
> 
> 2.2 BGP Peer
> 
>    Definition:
>               A BGP peer is another BGP instance to which the Device
>               Under Test (DUT) has established a TCP connection over
>               which a BGP session is active.  In the test scenarios in
>               the methodology discussion that will follow this draft,
>               peers send BGP advertisements to the DUT and receive DUT-
>               originated advertisements.

What about the situation where I have a BGP neighbor configured,
but the TCP sessions is not established yet or is being held down,
is it not a BGP peer? Also, what is the definition of "active"
for a BGP session? And, for that matter, what is a definition
of a "BGP session"? ;)

>
>    Discussion:
>               This is a protocol-specific definition, not to be confused
>               with another frequent usage, which refers to the
>               business/economic definition for the exchange of routes
>               without financial compensation.
> 
>               It is worth noting that a BGP peer, by this definition is
>               associated with a BGP peering session, and there may be
>               more than one such active session on a router or on a
>               tester.  The peering sessions referred to here may exist
>               between various classes of BGP routers (see section 2.3).
> 
>    Measurement units: number of BGP peers
> 
>    Issues:
> 
>    See Also:
> 
> 2.3 Default Route, Default Free Table, and Full Table
> 
>    An individual router's routing table may not necessarily contain a
>    default route.  Not having a default route, however, is not
>    synonymous with having a full default-free table(DFT).
>    It should be noted that the references to number of routes in this
>    section are to routes installed in the loc-RIB, not route instances,
>    and that the total number of route instances may be 4 to 10 times the
>    number of routes.

So, we're using a lot of terms here that haven't been introduced yet.

> 
>    The actual path setup and forwarding of MPLS speaking routers are
>    outside the scope of this document.  A device that computes BGP
>    routes, which a sub-IP device can use to set up paths, has its BGP
>    aspects within scope.

Hmmm... What is this para doing here?

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

---

From: "Howard C. Berkowitz" <[email-masked]>
Date: Tue, 13 Aug 2002 21:51:39 -0400

Let me start with some individual responses.

>Note that Loc-RIB has not been defined.

Good point. Perhaps the section should begin with definitions of the 
major conceptual data structures and their relationships, which do 
appear later in the section. A matter of reordering primarily.

>"exchange topology info with a GMPLS environment" sounds weird a bit.

Don't assume that this is being done in any standardized way.  A 2547 
PE can be a BGP speaker and a GMPLS node, but the coupling between 
the two functions is implementation dependent.

>BGP route-reflector", though.

How is a non-forwarding route reflector different than a route server 
(perhaps with multiple speakers)?  Or are you assuming that one 
client can forward to another?

>is it not a BGP peer?

Not for purposes of being measurable.

>Also, what is the definition of "active"

Successful exchange of OPEN.

>So, we're using a lot of terms here that haven't been introduced yet.

Again, we may just need to reorder.

>Hmmm... What is this para doing here?

Again, to indicate that a sub-IP device may use knowledge gained by 
BGP. This para does not describe how that knowledge is passed or used.

---

From: "Howard C. Berkowitz" <[email-masked]>
Date: Tue, 13 Aug 2002 21:51:39 -0400

---

From: Randy Bush <[email-masked]>
Date: Tue, 13 Aug 2002 20:58:53 -0700

> Let me start with some individual responses.

i have bounced your message to alex.  please don't use me as an
smtp relay, i am not sufficiently reliable.

>> Also, what is the definition of "active" for a BGP session? And,
>> for that matter, what is a definition of a "BGP session"? ;)

i suspect alex knows this, or has some idea like it.  i suspect
that he was suggesting that a document that defines terminology
either do so, or even better, have a reference to an existing
definition.

> BGP. This para does not describe how that knowledge is passed or used.

let's stick to real layer three for now

randy

---

From: Randy Bush <[email-masked]>
Date: Tue, 13 Aug 2002 20:58:53 -0700

randy

---

From: "Howard C. Berkowitz" <[email-masked]>
Date: Wed, 14 Aug 2002 09:48:24 -0400

>either do so, or even better, have a reference to an existing

We walked a delicate line, on  the one hand trying hard not to 
reproduce the BGP specification, and at the same time to clean up 
what seemed ambiguities in RFC1771.  I suspect that we could now 
point to a particular state in the 1771bis draft as the definition of 
OPEN, but such a reference would be non-normative.

>let's stick to real layer three for now

To steal a classic phrase, "what is real?"  Personally, I believe the 
document proper deals only with BGP.  At the same time, especially 
for the less experienced reader, this para helps put BGP in the 
context that it's increasingly being used as a generic signaling 
protocol.

I've made a slight start on an applicability document, and perhaps 
this para should move there.

---

From: "Howard C. Berkowitz" <[email-masked]>
Date: Wed, 14 Aug 2002 09:48:24 -0400

---

From: Randy Bush <[email-masked]>
Date: Wed, 14 Aug 2002 07:42:22 -0700

> OPEN, but such a reference would be non-normative.

first, the entire document is not normative, as it is info.  second,
maybe point to 1771.  waiting for 1771bis is iffy.

> context that it's increasingly being used as a generic signaling 

many folk, including the iesg and the routing ads fwiw, are coming to the
conclusion that it should not be used as a general signaling protocol.

> this para should move there.

that's a start in the right direction :-)

randy

---

From: Randy Bush <[email-masked]>
Date: Wed, 14 Aug 2002 07:42:22 -0700

randy

---

From: Alex Zinin <[email-masked]>
Date: Wed, 14 Aug 2002 14:05:31 -0700

Howard,

> the two functions is implementation dependent.

I think it might be a good idea to limit this to pure
routing.

> client can forward to another?

A RS normally has multiple "views" while a RR has just one.

> Successful exchange of OPEN.

You might want to consider getting this terminology closer
to the one used in real life, i.e., a peer does not just suddenly
show up when a BGP session is established, but is a configured
BGP neighbor that can be in different states depending on it's
session FSM status.

> BGP. This para does not describe how that knowledge is passed or used.

What Randy said ;)

Alex

---

From: Alex Zinin <[email-masked]>
Date: Wed, 14 Aug 2002 14:05:31 -0700

Howard,

What Randy said ;)

Alex

---

From: "Howard C. Berkowitz" <[email-masked]>
Date: Thu, 15 Aug 2002 11:14:54 -0400

>I think it might be a good idea to limit this to pure

Would you accept this being a part of discussion in an applicability statement?

>A RS normally has multiple "views" while a RR has just one.

I still am not picturing what you mean by a non-forwarding RR. Or is 
this something (dare I say?) like a topology information source for 
sub-IP?

>BGP neighbor that can be in different states depending on it's

I'm uncomfortable with this, simply because 1771 doesn't have a 
really good FSM, and the new draft is non-normative.  Remember that 
we are not trying to redefine BGP.

The methodology document may clarify this practically.

Would it help to define it as the condition where the test generators 
and the DUT are mutually prepared to exchange UPDATEs?

---

From: "Howard C. Berkowitz" <[email-masked]>
Date: Thu, 15 Aug 2002 11:14:54 -0400

---

From: Randy Bush <[email-masked]>
Date: Thu, 15 Aug 2002 08:30:15 -0700

>> I think it might be a good idea to limit this to pure routing.  

i think it might be a good idea to limit this to pure routing.  let's not
have it bounced from the iesg for this issue.

> this something (dare I say?) like a topology information source for 

a route server has the view of more than one AS.  a route reflector has
the internal view of one AS

>> You might want to consider getting this terminology closer to
>> the one used in real life, i.e., a peer does not just suddenly

seems to me that one has to either define it, or refer to a
definition.  the reader can not guess.  i defer to alex on whether
your definition is well understood.  i defer to bmwg benchmarking
(not bgp geek) folk as to whether your suggested definition is
sufficient for a testbed builder.

randy

---

From: Randy Bush <[email-masked]>
Date: Thu, 15 Aug 2002 08:30:15 -0700

randy