Re: comments on draft-ietf-cain-request-routing-req-00.txt

[brad cain <bcain@mediaone.net>]

Dmitri,

> If the intention was to collect everybody's
> input with the purpose to refine it in the
> future to a crystal set of absolute requirements,
> then this is OK!

First cut that's what we did.. the next draft will be
slightly distilled but I don't think multiple metrics
is something that will be going away


> 
> Again, IETF is not ISO.

So I guess you consider IS-IS, OSPF, and BGP bad protocol
design because they all support multiple metrics?


> >       2. not supporting multiple metrics in the protocol
> >       is extremely shortsighted so we want to make it
> >       a requirement.  again, ip routing protocols have
> >       proved that this is invaluable.
> 
> Could you please elaborate? Until now, I've been under (now seemingly
> erroneous) impression that the situation here was just quite opposite.

yes, people want multiple metrics
 
> > > 2) Support of various types of RRSs
> > >
> > >    Interconnected RRSs perform the function
> > >    of one global RRS. The function of *any*
> > >    RRS is to intelligently map the {client
> > >    IP address (prefix), URI} duplex to an ID
> > >    (which boils down to an IP address) of some
> > >    surrogate from the set of surrogates capable
> > >    of processing request for that URI.
> > >    "Intelligently" means that the minimal
> > >    metric (which is a function of all three --
> > >    client, URI and surrogate) is searched for.
> >
> > Not true... there are TWO different DEPLOYED
> > type of architectures for request routing... BOTH
> > must be supported..
> 
> Yes, of course. I didn't get what's not true, though.
> I'd even add that there are THREE different DEPLOYED
> types of architecture that must be supported. The
> third one is L3 based. It's used by some ISPs to
> load balance their DNS servers, for example. The
> same loopback IP address configured on every DNS
> server is advertised in the backbone IGP. Clients
> requests are routed to the closest (in the IGP sense)
> DNS server.

That is INTRA-domain based request routing... inside of
a CDN, there can be many types... we are only concerned
with INTER-domain

> >       1. "inline" case: this is the layer-7 or proxy
> >       case where URIs will be advertised
> >       2. the dns case: this is the common CDN case
> >       where only DNS names are visible.  this must
> >       be supported as well
> 
> Yes, of course. I guess what I'm proposing is ***to
> define the protocol requirements so, that the resulting
> protocol would be independent of the peering RRS types***.
> This way, all (not yet even existing) RRS types would be
> automatically supported.

but to do that you need to have advertisements for BOTH network 
proximity AND "URI proximity" 

that is what we are arguing about

and i do agree that both RRS can be supported with ONE protocol --
its just that the protocol must supported multiple types of
advertisements (ala MBGP)

> > >    So, what the RRS peering protocol MUST
> > >    do is to advertise URIs (possibly with some
> > >    "default" metrics), plus to be capable of
> > >    mapping {client, URI} requests to
> > >    corresponding {surrogate, metric}
> > >    responses.
> >
> > This is true for only #1 case above
> 
> I understand that it would be only domain name
> parts in the DNS based cases. Please see the
> examples from my previous email to Oliver.

Yes but the tricky part is in WHAT to base the
advertisement on -- network proximity or URI proximity
[see above]


> ...along with the "route selection" rules the protocol will have
> to define and implement. BTW, the route selection rules is a part
> of the persistent BGP route oscillation problem, which was observed
> recently in practice.

True... this is the problem for policy based protocols... everyone
wants their own policy which isn't necessarily compatible on a
global scale...

We can argue about routing research but my opinion on this
manner is that the only way to solve it is to have coordinated
routing policies (e.g. route servers).  There is no known "right
way" to solve the policy coordination problem.

> It also seems that you're mixing two protocol design models that
> are quite different (if not incomparable from the protocol design
> perspective) -- models for IGP and BGP.
> 
> In the IGP model, metrics do exist. The only currently used IGP
> that supports multiple metrics is (E)IGRP but all the EIGRP metrics
> are mandatory. 

Not true... traffic engineering and QoS routing use multiple
metrics

> In the BGP model, there is no required or optional metrics.

Most people consider AS_PATH a metric!  

> In fact, BGP does not used metrics at all. It just advertises NLRIs
> along with a set of attributes (which can be either well-known or
> optional (well-known attributes, in turn, can be either mandatory
> or discretionary, and optional attributes can be either transitive
> or non-transitive)). The only three attributes that have to be
> present in any UPDATE message (well-known mandatory attributes)
> are ORIGIN, AS_PATH and NEXT_HOP. Route selection decisions are
> made based on the set of the route selection rules then.

Attributes are often metrics (e.g. local pref)... 

You are just arguing terminology
 
> Now, what model are we really talking about here?

I think we are leaning towards a BGP model because of the policy
issues.

 
> >       3. two types of advertisements can easily be supported by
> >       a type of "address family" (analogy: MBGP)
> >       4. selection decisions are made on a per request routing
> >       domain basis (barring loop prevention by for example a
> >       path vector algorithm)
> >
> > In many ways the requirements can be supported by a simple
> > "BGP-like" protocol... I think this is fairly straightforward
> > and simple.
> 
> Please keep in mind that loop prevention in path-vector protocols
> is worst possible. The average convergence time is much longer than
> even in the distance-vector case. 

Yes but the alternatives aren't much better... link state is
definitely out and distance vector has its own problems... 

However, CDNs are a bit different because:
	1. they are overlay networks which
	2. means that most request routing systems will only be peered in
	a two level hierarchy -- to do more doesn't make any sense
	3. most requests should resolve in one or two request routing
	hops.  this means that oscillations and other BGP problems
	will probably not surface.  and if they do they will easily
	be coordinated to be solved.

> Moreover, it was shown back in 1996
> that BGP can form persistent route oscillations. Persistent oscillations
> were *observed in practice* in special conditions when route reflectors
> or confederations were used along with MEDs. I can provide you with
> the references if you're interested.

I'm well aware of the problems with BGP... most don't have anything
to do with path vector but have to do with incompatible policies on
a global scale (see infocom 2001 paper).

-brad