On Apr 15, 2011, at 7:51 PM, Woundy, Richard wrote:
One last set of comments.
I do not believe there is Standards Track work for the ALTO WG to
do to describe how to passively listen to a routing protocol.
I could be persuaded to your point of view, if it can be shown that
passively listening to one or more routing protocol(s) is sufficient
for interoperable network information updates and distribution from
routers to ALTO servers. And I suppose in return, you will expect
someone to document why passive listening is not sufficient, which
would be a fair pushback.
If folks are suggesting that service providers need to load a
proprietary application module on their routers to get network
information into their ALTO servers, then I will be very un-
persuaded. And very unhappy.
After some initial deployments of ALTO servers, it seems that sometimes
operators prefer not to extend their igp/bgp scheme to a server not
sitting in the network layer (IOW: not a router). Keep also in mind that
link-state technology has no such concept of "passive listener" and you
always have to hope that your isis/ospf nodes are going to be good
citizens.
BGP is obviously more robust in this context and probably is one of the
motivations of draft-gredler-bgp-te-00 authors. What puzzles me with
draft-gredler-bgp-te-00 (in its current version) is the non-ability to
pass any existing igp TLV that may be used by ALTO server (probably
something amendable). So my opinion is that:
a. it makes sense to have a routing API in order for an application to
extract routing topology information without having to participate
to
the routing scheme and there are ALTO implementors already working
on
that.
b. it makes sense for an operator to have a unified/standardized way to
plug an ALTO server without having to bind the ALTO server to a
specific router flavor.
c. it makes sense to evaluate if a routing API may leverage existing
protocols. draft-gredler-bgp-te-00 is probably one attempts to do
that. It looks to me it needs substantial modifications but worth to
be evaluated.
d. The use of routing protocols or (new) routing API is not mutually
exclusive.
e. IETF WG (ALTO, routing, others) will determine the best WG if/where
routing APIs have to be worked out.
Thanks.
s.
-- Rich
-----Original Message-----
From: Ben Niven-Jenkins [mailto:[email protected]]
Sent: Friday, April 15, 2011 1:11 PM
To: Woundy, Richard
Cc: Jan Medved; [email protected]
Subject: Re: [alto] Do we need to standardise an ALTO Server to
Network API?
Rich,
On 15 Apr 2011, at 15:31, Woundy, Richard wrote:
As a co-author of draft-medved-alto-svr-apis-00, let me explain my
motivations for interest in this subject.
My primary motivation is to have *some* scalable means to populate
(my) ALTO servers with current network information. Note that I
don't think there needs to be only ONE way to populate ALTO
servers. Certainly it needs to be possible to use manual
configuration as well. Maybe there is room for proprietary
mechanisms as well -- perhaps ALTO server vendor-driven (eg unique
routing ingest mechanisms and algorithms), perhaps ALTO server
purchaser-driven (eg via open/proprietary APIs to the ALTO server).
The reason I do not think an ALTO Server - Network API needs to be
specified in ALTO is not because I think ALTO servers do not need to
extract topology from the network in a scalable way but because I
see no Standards Track work for the ALTO WG to do to achieve that aim.
I could paraphrase the contents of draft-medved-alto-svr-apis-00 as
"Go implement draft-gredler-bgp-te-00 and here are some reasons why
BGP is good". Therefore the solution proposed is not really draft-
medved-alto-svr-apis-00 it is draft-gredler-bgp-te-00.
As someone with a background in routing draft-medved-alto-svr-
apis-00 adds nothing to draft-gredler-bgp-te-00 and certainly
nothing that warrants the status of a Standards Track document.
Now, I guess given ALTO is not in the Routing Area there may be
folks in ALTO who are not routing experts and some level of
informational material explaining how routing can be used to obtain
topology may be useful, but that's an Informational document at best
(it could be a BCP once there's some real world experience of doing
it).
My secondary motivation is to ensure that, with respect to
automated population of network information into ALTO servers, I
could choose ALTO server vendors and router vendors fairly
independently. That's why the use of a common protocol (BGP) is of
interest, because it is commonly implemented by router vendors and
commonly deployed by service providers. We had talked a long time
ago in ALTO about using "looking glass servers" as a potential
network information source, and usually looking glass servers are
based on BGP routes.
No objection there. ISIS and OSPF are also commonly implemented by
router vendors and commonly deployed by service providers :-) In my
mind a Standards Track document coming out of ALTO that says "The
answer is to load everything in BGP" sets the precedent that the
IETF 'mandated' way to do it loading your IGP into BGP, when IMO
that is one possible way that is likely to suit some but not all
service providers.
That's why I am interested in an open specification for an ALTO
server to network API.
IMO those open specifications exist in the form of the RFCs that
describe existing (and future) routing protocols and extensions.
To summarise my position:
- I believe that passively listening to routing is a reasonable
approach.
- I do not believe there is Standards Track work for the ALTO WG to
do to describe how to passively listen to a routing protocol. If
ALTO generates additional requirements that cannot be met by
existing roputing protocols ALTO could specify those and take them
to the appropriate Routing Area WG to produce a solution. I think
draft-medved-alto-svr-apis-00 clearly demonstrates that as it
contains no protocol specification at all and leaves all that to
draft-gredler-bgp-te-00 which can be taken up with the IDR WG.
-- Rich
P.S. I don't think ALTO servers need to listen to BGP *and* the IGP.
I think this really depends on the particular service provider's
network. When I look at how service providers are requesting
automatic topology import into our CDN product some are requesting
ALTO, some are requesting just BGP and some are certainly requesting
that we listen to both BGP and the IGP.
Ben
_______________________________________________
alto mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/alto
_______________________________________________
alto mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/alto
