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

["Dmitri Krioukov" <dima@krioukov.net>]

> -----Original Message-----
> From: owner-cdn@ops.ietf.org [mailto:owner-cdn@ops.ietf.org]On Behalf Of
> brad cain
> Sent: Saturday, January 27, 2001 9:22 PM
> To: Dmitri Krioukov
> Cc: Cain, Brad; cdn@ops.ietf.org
> Subject: Re: comments on draft-ietf-cain-request-routing-req-00.txt
> 
> Dmitri Krioukov wrote:
> > 
> > I think that the draft follows the type of
> > logic, which is quite opposite to the one
> > suggested by Mark and Fred. Instead of
> > trying to simplify, minimize and fix the
> > set of requirements, the draft proposes to
> > include and support all possibilities in
> > the areas where trade-off between flexibility
> > and simplicity should really be on the side
> > of the latter.
> 
> I very much disagree... Altough the first draft may be
> a bit confusing, the requirements are all based around
> a simple advertisement architecture very much like
> IP routing protocols... 

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!

> > Just two examples:
> > 
> > 1) Support of various types of metric
> > 
> >    Wouldn't it be easier to support just
> >    one standard metric or, at least, to fix
> >    supported metrics to some reasonable
> >    minimal set of required ones? CPGs are
> >    then responsible for mapping the internal
> >    proprietary set of metrics to this
> >    standard one (either metric or a set of
> >    metrics) and vice versa.
> 
> Most likely there will be one DEFAULT metric (ala OSPF) and
> multiple other optional metrics.  The reasons for this are
> very simple
> 	1. nobody can agree on a specific single metric -- we
> 	will most likely therefore have one single default
> 	metric.  the analogy is ip routing protocols.

Again, IETF is not ISO.

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

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

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

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

> >    In its current form, the corresponding
> >    part of the draft:
> >    - significantly complicated the protocol
> >      design
> >    - essentially violates the "black box"
> >      approach to the individual RRSs
> >    - does not allow for peering between RRSs
> >      of different types
> >    - does not support L3 (IP routing) based RRSs
> >      (they are not popular but existent)
> > 
> > In general, the protocol satisfying the current
> > set of requirements would look very fat and
> > spooky. Interoperability would be the biggest
> > issue with such a protocol. Some significant
> > simplifications (like proposed above) are required.
> 
> I do admit that the protocol is SLIGHTLY more
> complicated than what you desire.  However, that is
> to accomodate the two types of request routing
> systems that providers use. [interestingly the
> case that you ignore (dns) is the more commonly
> deployed]
> 
> Here is why the requirements can be used to form
> a simple protocol:
> 	1. the requirements assume a simple "advertise and forget"
> 	model just like BGP
> 	2. a default metric is used with optional ones -- this does
> 	not complicate the protocol, only the policies which one
> 	may implement (analogy BGP).

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

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. There is no negotiation. A given metric may be optional
only in the sense that the corresponding k-coefficient may be put to
zero on a given router. The fixed pre-defined formula (involving all
the metrics and the coefficients) is used to come up with the final
single metric that is actually used by the protocol. Route selection
decisions are made based on the minimal metric for a given prefix.

In the BGP model, there is no required or optional metrics.
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.

Now, what model are we really talking about here?

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

The bottom line is that I wouldn't claim that BGP uses a "simple model"
that can be "easily reused."

> -brad
--
dima.