Hello Abbie/Oliver and others,
these are some comments on draft-ietf-cdi-request-routing-reqs-00.txt.
1---
" A given client request may not necessarily cause a full redirection
but may use cached information to fulfull the request"
s/fulfull/fulfill/
2---
"In Figure 1, a
conceptual view of a request-routing system is presented; it consists
of the following components: Content Topology Exchange, Content
Topology Database and Route Computation. A brief summary of these
components is provided below:"
The components names in the text do not correspond to the ones used on figure 1.
s/Adverstisment Exchange/Content Topology Exchange/
3---
" 4. Request-Routing Information Exchange Protocol: The actual
protocol used to exchange sets of content advertisements and area
advertisements [MODEL]."
s/exchange sets of content advertisements and area
advertisements/exchange sets of content and area advertisement
4---
"That is, when neighbor CN can "better" serve a set of clients, it may
be desirable to direct requests to that neighbor CN. "
when a neighbor CN can "better" serve a set of clients or the requested content is not available within the client's CN...
It might be implicit on the "better" word but I'm not sure.
5---
" 2. "In-Line" Request-Routing Systems: These request-routing
systems are "in-line" to client requests. Examples of in-line
request-routing systems are those that may be implemented within a
proxy or a layer-7 router. In-line request-routing systems have
full visibility into content requests (e.g. full URL) as well as
visibility of the client's IP address [note: this isn't always true
if transparent proxies are in place]."
How about In-Path instead of In-line to align with midcom and opes terminology?
6---
"2.1.2 "In-Line" Request-Routing Systems"
s/In-Line/In-Path/ from 2.1.2 onward
7---
" A Layer-7 router or Proxy situated close to a client may be used as
an "in-line" request-routing system."
What's the definition of close? IMO the only restriction is that an in-path RRS need to be in the normal application path between source and destination and within the client's CN. This is assumed for instance in example 2.1.2 where the client is configured to forward its requests to the RR which is a CIG for CN-A. This is CIG can be N hops away given that is within CN-A, of course.
8---
" There are three major differences between an "in-line" request-
routing system and a DNS-based request-routing system. The first is
that the full content request is exposed (e.g. a full URL). The
second is that the content type of the request is exposed (again from
the full URL). The third is that all client requests can be received
by the request-routing system; this is in contrast to DNS-based
systems where caching may prevent this."
I wonder if not only full URL but access to other important information such as HTTP method, cookies, etc.
9---
"2.2 Request-Routing Interconnection Model"
Shouldn't it be "CN Interconnection Model"? I mean, the RR (actually CIGs) are the ones that exchange the advertisements, but what you are interconnecting are CNs. That's what it seemed to me after reading draft-ietf-cdi-model-00.txt also.
10---
" Request-routing systems (RRS) present a "black-box" view of their
associated distribution systems"
Shouldn't it be "CIGs present a "black box" view..."? I mean, is the CIG that present the advertisements, right? A RRS system is composed of several RRs, but only some actually interconnect with other CNs, so the ones that present this "black box" views are the CIGs. That's what it seemed to me after reading draft-ietf-cdi-model-00.txt
11---
" - Request-routing decisions are independent; therefore request-
routing loops must be prevented."
Can someone elaborate on this?
12---
" In order to interconnect request-routing systems, one or more
protocols are required to exchange request-routing information.
These protocols are designed to operate in an inter-domain context
and therefore have the following considerations:
- Protocol sessions will need to be debugged across CN boundaries.
- Large sets of information may be exchanged between CNs.
- Policy based request-routing is needed in many scenarios.
- Protocol designs should be "Internet" scalable."
What's the definition of inter-domain here? Inter-CN?
I'm not sure "Protocol sessions will need to be debugged across CN boundaries." is something we need to mention on the protocol desing session. What new requirements this implies for the protocol? All protocols need debugging tools but this is implementation specific.
"- Policy based request-routing is needed in many scenarios." is another example of an implementation specific functionality that IMO shouldn't be on the protocol design section. For e.g. policy based BGP routing is something specific to each vendor
that is orthogonal to BGP design since it's a local (device) policy.
13---
" - Request-routing protocols SHOULD be compatible with existing
applications and protocols."
What this means exactly? If this has been hashed out on the list before I apologize, but this phrase alone in the text like this can mean anything or nothing, depends on who's reading.
14---
" - Request-routing protocols SHOULD support both iterative and
recursive redirection models."
Should at least one of the methods be a MUST? Today with a SHOULD both are optional...
Something like "- Request-routing protocols MUST support iterative redirection methods and SHOULD also support recursive redirection models."
15---
" - Request-routing protocols MUST support the exchange of area
advertisements (e.g. IP prefixes) between request-routing systems."
Area has a very special meaning from OSPF and this can be confusing. I read the definition in draft-ietf-cdi-model-00.txt but I'm still not clear on the goal of this area advertisement.
The above quote implies that area can be a collection of IP prefixes adn associated metrics/attributes? Wouldn't be better to call them CLRI (Content Layer Reachability Information), analogous to BGP NLRI, instead of area?
16---
In 3.6
" - Request-routing protocols SHOULD support exchange of information
sufficient to prevent routing loops."
then in 3.5.1
" - Request-routing protocols MUST exchange information sufficient to
avoid looping of information advertisements."
seems to be conflicting.
thanks,
Reinaldo