Subject: [alto] Do we need to standardise an ALTO Server to Network API?

From: Ben Niven-Jenkins <[email-masked]>
Date: Wed, 13 Apr 2011 12:32:36 +0100

Authors, Colleagues,

The meeting minutes from IETF 80 record:

"Jan Medved presents Network-to-server API.

  Jan Seedorf: scope of this work is explicitly excluded in RFC 5693
  ALTO WG scope description. Enrico: this is new work, currently not
  in the charter. We should hear it. Jan S.: we need to discuss if we
  need to standardized it. Eric: it does, but maybe not now."

Regarding whether we need to standardise the Network-to-server "API" for ALTO, my opinion is that we do not.

Extracting network topology by passively listening to routing protocols for various purposes including aiding with operations, diagnostics, root cause analysis, management, capacity planning, traffic engineering, etc. is not a new idea. There are multiple products on the market to enable operators to do just that.

An ALTO server that follows a similar approach as a mechanism to import network topology into its network topology/map/cost database is a reasonable proposition but in my opinion the ALTO WG should not attempt to standardise how a ALTO server should perform such integration with an operator's routing control plane(s), for example  because:

* Extracting network topology is not an interoperability issue between ALTO servers. Each ALTO server can extract the network topology independently and if the topology needs to be distributed between ALTO servers then it is an ALTO Server-Server API that needs standardising *not* an ALTO Server-Network API. Interoperation between an ALTO Server and the underlying network(s) is a solved problem as is demonstrated by the numerous interoperable implementations of routing protocols.

* Attempting to standardise a single approach is likely to limit the applicability of ALTO (or the relevancy of the ALTO Server-Network "API standard") because it is unlikely we would be able to converge on a single routing protocol that would satisfy the preferences of all operators that are likely to deploy an ALTO server. 

Ben

---

From: Ping Pan <[email-masked]>
Date: Wed, 13 Apr 2011 08:22:45 -0700

> ALTO, my opinion is that we do not.
I concur for now.

It's not clear to me that we fully understand the network abstraction
information to be gathered in the first place. Draft-sun has recommended to
gather information at BAS granularity. Another draft was talking about
inter-ISP network abstraction for better asyn transmission etc.Comcast has
shown that coarse and fine network maps have the similar effect...

Further, I think that the current ALTO WG scope is to define the mechanism
to bind application and network, not the actual network abstraction. Correct
me if I am wrong.

Regards,

Ping

> Extracting network topology by passively listening to routing protocols for
> various purposes including aiding with operations, diagnostics, root cause
> analysis, management, capacity planning, traffic engineering, etc. is not a
> new idea. There are multiple products on the market to enable operators to
> do just that.
>
> An ALTO server that follows a similar approach as a mechanism to import
> network topology into its network topology/map/cost database is a reasonable
> proposition but in my opinion the ALTO WG should not attempt to standardise
> how a ALTO server should perform such integration with an operator's routing
> control plane(s), for example  because:
>
> * Extracting network topology is not an interoperability issue between ALTO
> servers. Each ALTO server can extract the network topology independently and
> if the topology needs to be distributed between ALTO servers then it is an
> ALTO Server-Server API that needs standardising *not* an ALTO Server-Network
> API. Interoperation between an ALTO Server and the underlying network(s) is
> a solved problem as is demonstrated by the numerous interoperable
> implementations of routing protocols.
>
> * Attempting to standardise a single approach is likely to limit the
> applicability of ALTO (or the relevancy of the ALTO Server-Network "API
> standard") because it is unlikely we would be able to converge on a single
> routing protocol that would satisfy the preferences of all operators that
> are likely to deploy an ALTO server.
>
> Ben
>
>
> _______________________________________________
> alto mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/alto
>

---

From: Jan Medved <[email-masked]>
Date: Wed, 13 Apr 2011 16:54:40 -0700

Ben,

Please see inline.

Thanks,
Jan

On 4/13/11 4:32 AM, "Ben Niven-Jenkins" <[email-masked]> wrote:

>Extracting network topology by passively listening to routing protocols
>for various purposes including aiding with operations, diagnostics, root
>cause analysis, management, capacity planning, traffic engineering, etc.
>is not a new idea. There are multiple products on the market to enable
>operators to do just that.

Agreed that extracting network topology by passively listening to routing
protocols is not a new idea. What is a new idea, though, is that it can be
accomplished by listening to a single protocol (BGP with TE extensions),
rather than listening to both BGP and IGPs.

This significantly simplifies (even enables) the operation and deployment
of an ALTO Server that wishes to listen routing protocol updates.
Streamlining / simplifying the ALTO Server's operation is the primary
motivation for this draft.

>network topology into its network topology/map/cost database is a
>reasonable proposition but in my opinion the ALTO WG should not attempt
>to standardise how a ALTO server should perform such integration with an
>operator's routing control plane(s), for example  because:
>
>* Extracting network topology is not an interoperability issue between
>ALTO servers. Each ALTO server can extract the network topology
>independently and if the topology needs to be distributed between ALTO
>servers then it is an ALTO Server-Server API that needs standardising
>*not* an ALTO Server-Network API.

Actually, extracting network topology and generating the abstracted
network topology (maps) is an interoperability issue between ALTO Servers,
and it can not be completely separated from the exchange of topology
between ALTO servers. For ALTO Servers to be able to exchange (and
reconcile) their respective abstracted topologies (maps) with each other,
the topologies need to be equivalent. This then drives the need for a
common set of data from which the topology is created and a normalized way
to generate the topology from the data (which we mentioned in the draft,
but did not attempt to specify).

>Interoperation between an ALTO Server and the underlying network(s) is a
>solved problem as is demonstrated by the numerous interoperable

Not really. First, the interoperable implementations of routing protocols
are used to talk between routers themselves, not as a northbound API to
the network. Now, we need to differentiate between BGP and IGPs. BGP can
(and has been) used to get network topology to interested clients. IGPs
are not, and it is highly unlikely that operators will let an ALTO Server
to hook into their IGP (at least this has been my experience over the past
several years...). Even if they do, there are a lot of issues with it -
security, worries about network stability, multi-area deployment
complexity, etc. (more listed in the draft). We need both BGP and IGP data
to generate cost maps, and unfortunately today there is no practical way
to get it. 

Today, the vast majority of clients that need network topology data simply
hook into BGP. ALTO is much easier to use to get network topology than
BGP. But for ALTO to be usable for this purpose, we need a deterministic
way to generate ALTO maps from a well defined set of network data, so that
clients know what they're getting. One part of this definition is the
Network-Server API which defines the data set and the way to get it,
another is a normalized way to generate the maps.

>standard") because it is unlikely we would be able to converge on a
>single routing protocol that would satisfy the preferences of all
>operators that are likely to deploy an ALTO server.

I am not sure what you mean - there is a single routing protocol that
operators have converged on - BGP. If you mean operators have not
converged on a single IGP, I agree. But that is precisely one of the
problems we are addressing with the draft. Operators can use a single
protocol - BGP - that (with appropriate extensions) can convey all the
information required to generate ALTO maps. Since BGP has the necessary
security and policy knobs, and it is already being used to exchange
information between different admin domains, it is definitely a good
candidate for a northbound API to propagate topology information to
interested clients. Some of the diagnostics, root cause analysis,
management, capacity planning, traffic engineering etc. tools could also
benefit from this API, since it will make life a lot easier for them. Or,
better yet, they will be able to use the ALTO interface, which will make
it even easier :-) 

Standardizing the way to get network topology through ALTO will extend
ALTO's applicability rather than limit it. If ALTO does not define a
standardized way to generate maps from topology data, people will simply
use BGP (eventually with extensions that will convey the TE / IGP topology
information), and bypass an ALTO Service that a provider may offer.

Now, I would like to point out that the draft is only focusing on ALTO
maps that are generated from network topology data. There can be other
maps, generated from other types of data (for example from RTD
measurements, network probes, or from resource utilization measurements),
which will require their own APIs. This "other data" and "other APIs" are
not in the scope of the draft.

---

From: Robert Raszuk <[email-masked]>
Date: Thu, 14 Apr 2011 09:01:01 +0200

Hi Ben,

 > for ALTO, my opinion is that we do not.

I highly agree with that opinion. Any attempt to standardize ALTO server 
API to network is a clear attempt to limit it's range of functionality.

Number of reasons:

- Attaching an ALTO server as passive IGP node is not an issue. Using
   BGP to propagate local IGP area topology to ALTO server attached to
   such area is really highly questionable improvement

- Using BGP to propagate remote IGP topologies is just a way .. clearly
   there are other ways to propagate IGP topologies from remote areas

- As defined today draft-gredler-bgp-te-00 is very selective in what
   information is propagted from LSDB or TEDB. Each addition of such
   information would require a new BGP extension definition. This will
   block ALTO innovation. There were already proposals stated during the
   last IETF to carry entire LSDB in BGP as opaque information however
   those are beyond the scope of this WG discussion.

- ALTO servers even today can benefit from other ways to get network
   information which would not have to be carried in BGP.

Many thx,
R.

---

From: Benjamin Niven-Jenkins <[email-masked]>
Date: Thu, 14 Apr 2011 23:16:20 +0100

Jan,

> but did not attempt to specify).

I think this is the crucial bit for me. If you want two ALTO servers to produce the same result you need to identify the key bits of information they need to obtain from the network and how they will translate that into a ALTO representation of the network.

How they extract that information from the network is an orthogonal problem. Throwing the entire IGP into BGP (or for that matter specifying that an ALTO server must listen to both BGP and the IGP) doesn't help you with interoperability as you haven't specified what information the ALTO server needs know and what it needs to do with that data to generate the network and cost maps, you've just specified one possible way to import the raw data into the ALTO server.

<snip>

> information), and bypass an ALTO Service that a provider may offer.

But your draft (and any ALTO Server - Network API) doesn't address how to standardise the way to get topology through ALTO. It just proposes one possible way to get topology *into* an ALTO server.

Ben

---

From: "Woundy, Richard" <[email-masked]>
Date: Fri, 15 Apr 2011 14:31:08 +0000

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

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.

That's why I am interested in an open specification for an ALTO server to network API.

-- Rich

P.S. I don't think ALTO servers need to listen to BGP *and* the IGP.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Benjamin Niven-Jenkins
Sent: Thursday, April 14, 2011 6:16 PM
To: Jan Medved
Cc: [email-masked]
Subject: Re: [alto] Do we need to standardise an ALTO Server to Network API?

Jan,

<snip>

Ben

---

From: Robert Raszuk <[email-masked]>
Date: Fri, 15 Apr 2011 17:08:13 +0200

Hi Richard,

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

But do you need to have a RFC which mandates support of BGP-TE spec by 
an ALTO server ?

How about ALTO vendors which not have BGP code at all today ?

Are they out of luck to even propose ALTO servers ? I could really 
easily imagine an ALTO vendor which does not support BGP and collects 
network information (both routing and non-routing related) via their own 
self discovering application modules running on all or on subset of 
routers of given network. Result: no need to configure and maintain 
dozens if not more of BGP sessions both on the ALTO server as well as on 
the routers, no need to support BGP or IGP on ALTO server side.

And on the other hand if you want to choose a particular deployment 
model you can select ALTO server vendor which does support BGP-TE RFC 
XYZ. Just like today when you are buying routers or other network 
devices you just make sure they speak the same language as described in 
the protocol RFC XYZ. No need for another API spec to mandate support of 
RFC XYZ.

Cheers,
R.

---

From: "Woundy, Richard" <[email-masked]>
Date: Fri, 15 Apr 2011 15:44:31 +0000

I think you are mixing two things together, that I see as independent.

> But do you need to have a RFC which mandates support of BGP-TE spec by an ALTO server ?

There is a ALTO client-to-server protocol spec. There is a ALTO server-to-network protocol spec. They should be independently specified, and can be independently implemented.

If you want to build a ALTO server that follows only the client-to-server protocol spec, go ahead. There is probably a market for a product like this. This shouldn't be prohibited.

I think there are a number of parties that want an ALTO server that would follow specifications for both client-to-server and server-to-network protocols.

> I could really easily imagine an ALTO vendor which does not support BGP and collects network information (both routing and non-routing related) via their own self discovering application modules running on all or on subset of routers of given network.

So in other words, I need to deploy "application modules" on my routers for your approach to work. And if your application modules didn't run on my routers, I have to replace my routers to enable ALTO support in my network. Hmmm.

XYZ.

Yes we could. The question is what needs to be carried in BGP-TE to be useful to ALTO servers. That's where the interoperability concerns arise, and where an open specification is needed.

-- Rich

-----Original Message-----
From: Robert Raszuk [mailto:[email-masked]] 
Sent: Friday, April 15, 2011 11:08 AM
To: Woundy, Richard
Cc: Benjamin Niven-Jenkins; Jan Medved; [email-masked]
Subject: Re: [alto] Do we need to standardise an ALTO Server to Network API?

Hi Richard,

Cheers,
R.

---

From: Jan Medved <[email-masked]>
Date: Fri, 15 Apr 2011 09:57:11 -0700

Ben,

On 4/14/11 3:16 PM, "Benjamin Niven-Jenkins" <[email-masked]>
wrote:

>But your draft (and any ALTO Server - Network API) doesn't address how to
>standardise the way to get topology through ALTO.

Fair enough. We do state that the way to get the topology through ALTO
should be standardized, though:

Section 4.1.1, Requirements, last paragraph:

"  In addition to having a standardized Server-to-Network interface, the
   algorithms for generation of ALTO network / cost maps and for
   endpoint ranking should be normalized as well, to facilitate inter-
   operability of different ALTO Server implementations.  "

The idea is to have the algorithm defined in a separate draft.

>It just proposes one possible way to get topology *into* an ALTO server.
>
Yes. And having done this a couple of times, I am convinced it is the
easiest way to do it ;-)

Thanks,
/Jan

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Fri, 15 Apr 2011 18:10:52 +0100

Rich,

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

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.

> 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

---

From: Robert Raszuk <[email-masked]>
Date: Fri, 15 Apr 2011 19:15:28 +0200

To clarify .. I was not mixing two things. I was only referring to ALTO
server-to-network part in my last two posts.

So to conclude my opinion is:

- ALTO client to server protocol - required

- ALTO server to network protocol - not needed

- ALTO server to server spec - perhaps required, but only to define 
server to server network map abstraction such that two ALTO servers from 
different vendors could exchange/share their maps. Useful especially in 
the inter-domain applications (example: CDNs).

Rgs,
R.

>> But do you need to have a RFC which mandates support of BGP-TE spec
>> by an ALTO server ? How about ALTO vendors which not have BGP code
>> at all today ?
>
> There is a ALTO client-to-server protocol spec. There is a ALTO
> server-to-network protocol spec. They should be independently
> specified, and can be independently implemented.
>
> If you want to build a ALTO server that follows only the
> client-to-server protocol spec, go ahead. There is probably a market
> for a product like this. This shouldn't be prohibited.
>
> I think there are a number of parties that want an ALTO server that
> would follow specifications for both client-to-server and
> server-to-network protocols.
>
>> I could really easily imagine an ALTO vendor which does not support
>> BGP and collects network information (both routing and non-routing
>> related) via their own self discovering application modules running
>> on all or on subset of routers of given network.
>
> So in other words, I need to deploy "application modules" on my
> routers for your approach to work. And if your application modules
> didn't run on my routers, I have to replace my routers to enable ALTO
> support in my network. Hmmm.
>
> model you can select ALTO server vendor which does support BGP-TE
> RFC XYZ.
>
> Yes we could. The question is what needs to be carried in BGP-TE to
> be useful to ALTO servers. That's where the interoperability concerns
> arise, and where an open specification is needed.
>
> -- Rich
>
> -----Original Message----- From: Robert Raszuk
> [mailto:[email-masked]] Sent: Friday, April 15, 2011 11:08 AM To:
> Woundy, Richard Cc: Benjamin Niven-Jenkins; Jan Medved;
> [email-masked] Subject: Re: [alto] Do we need to standardise an ALTO
> Server to Network API?
>
> Hi Richard,
>
>> 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.
>
> easily imagine an ALTO vendor which does not support BGP and
> collects network information (both routing and non-routing related)
> via their own self discovering application modules running on all or
> on subset of routers of given network. Result: no need to configure
> and maintain dozens if not more of BGP sessions both on the ALTO
> server as well as on the routers, no need to support BGP or IGP on
> ALTO server side.
>
> model you can select ALTO server vendor which does support BGP-TE
> RFC XYZ. Just like today when you are buying routers or other
> network devices you just make sure they speak the same language as
> described in the protocol RFC XYZ. No need for another API spec to
> mandate support of RFC XYZ.
>
> Cheers, R.
>
>
>
>
>
>
>

---

From: "Woundy, Richard" <[email-masked]>
Date: Fri, 15 Apr 2011 17:40:07 +0000

> I see no Standards Track work for the ALTO WG to do to achieve that aim.

My opinion: I do agree that this work is outside the scope of the current ALTO charter.

I think the essential question is whether this effort should be captured in an ALTO re-charter. It seems we will have diverging opinions there. I'll defer to the WG chairs to figure out how to determine consensus or lack thereof.

> 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 d…

Well, I agree, sort of. draft-medved-* is just a motivation document at this time, eg why we want it, what we think are the requirements. draft-gredler-* defines the new BGP encodings but doesn't say much how an ALTO server would leverage that information. draft-gredler-* also is concerned with MPLS-TE, which is way outside the scope of ALTO.

A third document is needed (or significant updates to the other two) to say how an ALTO server would consume and react to the BGP TE information.

But right now there doesn't seem to be a forum for this discussion. It is not in scope for ALTO yet (my opinion), and it seems that IDR is not the ideal forum.

> If ALTO generates additional requirements that cannot be met by existing [routing] protocols ALTO could specify those and take them to the appropriate Routing Area WG to produce a solution.

That is a possible approach.

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

Sigh. It might also clearly demonstrate that the protocol specification work to make BGP TE work specifically with ALTO servers hasn't started yet. And that draft-medved-alto-svr-apis-00 is written as a motivational (use case / requirements) document not as a standards track protocol document.

I guess we might have to agree to disagree.

-- Rich

-----Original Message-----
From: Ben Niven-Jenkins [mailto:[email-masked]] 
Sent: Friday, April 15, 2011 1:11 PM
To: Woundy, Richard
Cc: Jan Medved; [email-masked]
Subject: Re: [alto] Do we need to standardise an ALTO Server to Network API?

Rich,

 

Ben

---

From: "Woundy, Richard" <[email-masked]>
Date: Fri, 15 Apr 2011 17:51:42 +0000

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.

-- Rich

-----Original Message-----
From: Ben Niven-Jenkins [mailto:[email-masked]] 
Sent: Friday, April 15, 2011 1:11 PM
To: Woundy, Richard
Cc: Jan Medved; [email-masked]
Subject: Re: [alto] Do we need to standardise an ALTO Server to Network API?

Rich,

 

Ben

---

From: Robert Raszuk <[email-masked]>
Date: Fri, 15 Apr 2011 22:37:12 +0200

Rich,

> One last set of comments.

Likewise :)

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

But BGP-TE is a clear example of passive listening.

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

I did not mean at all that such module should be proprietary. It should 
come with ALTO server for wide vendor's range of routing platforms.

Cheers,
R.

---

From: "Mcdysan, David E" <[email-masked]>
Date: Mon, 18 Apr 2011 10:20:48 -0400

As a co-author of draft-medved-alto-svr-apis-00, I have some responses to
this thread in line below.

Thanks,

Dave

On Friday4/15/11 1:40 PM, "Woundy, Richard"
<[email-masked]> wrote:

>I think the essential question is whether this effort should be captured
>in an ALTO re-charter. It seems we will have diverging opinions there.
>I'll defer to the WG chairs to figure out how to determine consensus or
>lack thereof.
>
>> 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.
>
>Well, I agree, sort of. draft-medved-* is just a motivation document at
>this time, eg why we want it, what we think are the requirements.
>draft-gredler-* defines the new BGP encodings but doesn't say much how an
>ALTO server would leverage that information. draft-gredler-* also is
>concerned with MPLS-TE, which is way outside the scope of ALTO.

I think the following summary is more accurate than the above:

Note that section 4.1.1 is requirements, and states all of them as
"should" (I.e., SHOULD) and are not mandatory.

Section 4.1.2 describes A solution that meets many of the desirable
requirements. 

>
>A third document is needed (or significant updates to the other two) to
>say how an ALTO server would consume and react to the BGP TE information.
>
>But right now there doesn't seem to be a forum for this discussion. It is
>not in scope for ALTO yet (my opinion), and it seems that IDR is not the
>ideal forum.
>
>> If ALTO generates additional requirements that cannot be met by
>>existing [routing] 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.
>
>Sigh. It might also clearly demonstrate that the protocol specification
>work to make BGP TE work specifically with ALTO servers hasn't started
>yet. And that draft-medved-alto-svr-apis-00 is written as a motivational
>(use case / requirements) document not as a standards track protocol
>document.
>

I agree with Rich that the use case/ requirements is separable from the
protocol specifics.

Ben, would separating these address what appears to be one of your major
comments?

I suggest that we first focus on the requirements and where that work is
best chartered. 

>> 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).
>
>>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.
> 
>IMO those open specifications exist in the form of the RFCs that describe
>existing (and future) routing protocols and extensions.
>
>- 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
>> 
>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
>

---

From: stefano previdi <[email-masked]>
Date: Mon, 18 Apr 2011 18:43:23 +0200

On Apr 15, 2011, at 7:51 PM, Woundy, Richard wrote:
> 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.

>> 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).
>
> 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).
>
>> 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.
>
> IMO those open specifications exist in the form of the RFCs that  
> describe existing (and future) routing protocols and extensions.
>
> - 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  
> 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
>

---

From: Jan Medved <[email-masked]>
Date: Mon, 18 Apr 2011 10:55:24 -0700

>requesting just BGP and some are certainly requesting that we listen to
This actually underlines the need for standardizing what data is acquired
from the network, how the data is normalized, and how the ALTO server
acquires topology data from the network. If the ALTO server can accurately
reflect the topology of the underlying network, there is no need for the
CDN to listen to routing protocols. All the CDN needs to do is to
interface with the ALTO Server, which makes the CDN implementation a lot
simpler. This in turn allows for better interoperability between CDNs and
interoperability between the network and different CDNs operating on top
of 
it. 

Protocol selection aside, this discussion should be about the APIs and
utility of standardizing the map exchange. WRT the discussion of the
Network API: the pro is that ALTO servers will have the same information,
the con is that they won't and have a technology with different maps and
views of the network.

/Jan

---

From: stefano previdi <[email-masked]>
Date: Mon, 18 Apr 2011 20:19:41 +0200

On Apr 18, 2011, at 7:55 PM, Jan Medved wrote:
>> network.
> acquires topology data from the network.

I don't think we need to define what exact piece of information alto
should retrieve but rather how to formalize a link-state, TE or bgp
topology into an api so it can be retrieved independently from routing
layer operations and deployed protocols.

> If the ALTO server can accurately
> CDN to listen to routing protocols.

but the CDN does NOT listen to routing protocols anyway. The ALTO server
does it and CDN only interoperates with ALTO.

> All the CDN needs to do is to
> simpler.

again: this happens today when ALTO plays routing protocols.

s.

> This in turn allows for better interoperability between CDNs and

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Tue, 19 Apr 2011 17:43:39 +0100

Dave, Colleagues,

Please see inline below.

Ben

> Ben, would separating these address what appears to be one of your major

Yes. I would prefer ALTO WG to focus on:
- What information an ALTO server needs from the network to do its job (which may differ by use case).
- What an ALTO server may want (or be required) to do with that information

> I suggest that we first focus on the requirements and where that work is

Did you mean to insert a 'not' to make 'and not where that work is chartered'? If so, then I'd say that is a fine suggestion and one I heartily agree with :-)

Ben

---

From: "Mcdysan, David E" <[email-masked]>
Date: Tue, 19 Apr 2011 13:22:28 -0400

Hi Ben,

A response to your question below.
Dave

On Tuesday4/19/11 12:43 PM, "Ben Niven-Jenkins" <[email-masked]>
wrote:

>>>>"Go
>Did you mean to insert a 'not' to make 'and not where that work is
>chartered'? If so, then I'd say that is a fine suggestion and one I
>heartily agree with :-)

Sorry, the following is what I had in mind, with CHANGES IN ALL CAPS.

I suggest that THE ALTO WG first focus on the requirements and THEN AS A
NEXT STEP (E.G., A SEPARATE DRAFT) DETERMINE where ANY NEEDED
INFORMATIONAL, BCP OR PROTOCOL work AS DETERMINED FROM THE REQUIREMENTS
ANALYSIS WOULD best BE chartered.

---

From: Ben Niven-Jenkins <[email-masked]>
Date: Wed, 27 Apr 2011 16:49:36 +0100

Dave,

Apologies for taking some time to respond, please see below.

> ANALYSIS WOULD best BE chartered.

Agreed - I think we're on the same page :-) The first step (IMO) is definitely to start by focussing on requirements and determining which place is best to do any follow-on work can wait until after we have the requirements.

Ben