Subject: Re: [alto] ALTO topology design: separation design

From: Wendy Roome <[email-masked]>
Date: Wed, 25 Feb 2015 15:51:05 -0500

I also prefer the separation strategy. I don't think we have enough legacy
clients to worry about (*sigh*), but a PID as a collection of endpoints
defined by a set of CIDRs is a simple, easy-to-understand concept. Most
ALTO clients will not care about topology. So why complicate life for them?

To summarize my idea of the separation approach:

* We define a new entity, called (say) a Network Element (NE). An NE is
something that packets must go through to get from one PID to another. An
NE can be a link, a router, a node, or some conglomeration of all of
those. If you want to make it crystal clear that NEs can be a
conglomerate, we could call them Abstract Network Elements, or ANEs.

* Like PIDs, NEs have unique names. And like PID names, NE names are
meaningless outside of the context of the ALTO server that defines them.

* A new cost metric gives the set of NEs involved in delivering packets
from the source PID to the destination PID. Note that although those NEs
are represented with a JSON array, the order is irrelevant; it really is a
set.

* Like endpoints and PIDs, NEs can have properties. Eg, type, bandwidth,
delay, etc.

* If the NE set from Pid1->Pid2 intersects the NE set from Pid3->Pid4,
then the client knows those two flows are dependent: they may have a
common point of failure, or they may limit each other, or whatever.

	- Wendy Roome

>Date: Wed, 25 Feb 2015 15:29:16 +0000
>From: "Scharf, Michael (Michael)" <[email-masked]>
>Subject: Re: [alto] ALTO topology design: separation design
>
>
>I think one the key ideas of ALTO is that a PID refers to (potential)
>locations of application instances, i.e., endpoints. ALTO is a solution
>to provide topology guidance between endpoints.
>
>With path vector encoding, we have additional entities for ?something?
>that is in the middle between endpoints, e.g., a shared bottleneck of two
>path vectors. Conceptually, this entity representing a shared bottleneck
>is quite different to an endpoint: First, in many cases we won?t expect
>that an application runs instances at such a bottleneck. And second,
>these entities may use other identifiers. For instance, a switch or a
>router may not have any globally unique IP address, or even if it has one
>(e.g., router system address), the network operator may not necessarily
>be interested in exposing this in an ALTO server, e.g., to P2P
>applications.
>
>To me, the question of whether to use unified PID comes down to:
>
>1)      Distinguish different types of PIDs, i.e., add some form of ?type
>field? for PIDs. I think we had a related discussion some time ago
>regarding ?Transactional PIDs?.
>
>2)      Add a new entity in addition to PIDs that is used e.g. in the
>path-vector format, i.e., separation design.
>
>I think both approaches can work. IMHO, one of the constraints for
>picking a solution would be ?legacy? ALTO clients. For instances, let?s
>assume that an ALTO server offers path-vector style ALTO maps, but not
>all ALTO clients support it. For instance, a P2P application may only
>understand ?traditional? network and cost maps. In this case, it probably
>makes sense not to expose in network maps those PIDs a ?legacy?
>application would not care about. This means that path-vector guidance
>would probably be exposed in a new network map (e.g., different MIME
>type). Furthermore, I?d argue that in this scenario it could make sense
>to allow an ALTO server operator to use the same PID names both in the
>network maps for ?legacy? and ?path-vector? users, in order to simplify
>management. In general, I believe that separation is a slightly more
>natural design choice under these constraints.
>
>Thoughts?
>
>Michael

---

From: "Scharf, Michael (Michael)" <[email-masked]>
Date: Wed, 25 Feb 2015 21:09:37 +0000

Regarding terminology: I like the idea of introducing an Abstract Network Elements (ANE). Maybe we could also use a term like Abstract Element/Entity (AE).

We should probably avoid the acronym NE, since this is used by the network management community, but in a different context (typically implying a device).

Michael 

-----Ursprüngliche Nachricht-----
Von: alto [mailto:[email-masked]] Im Auftrag von Wendy Roome
Gesendet: Mittwoch, 25. Februar 2015 21:51
An: [email-masked]
Betreff: Re: [alto] ALTO topology design: separation design

I also prefer the separation strategy. I don't think we have enough legacy clients to worry about (*sigh*), but a PID as a collection of endpoints defined by a set of CIDRs is a simple, easy-to-understand concept. Most ALTO clients will not care about topology. So why complicate life for them?

* We define a new entity, called (say) a Network Element (NE). An NE is something that packets must go through to get from one PID to another. An NE can be a link, a router, a node, or some conglomeration of all of those. If you want to make it crystal clear that NEs can be a conglomerate, we could call them Abstract Network Elements, or ANEs.

* Like PIDs, NEs have unique names. And like PID names, NE names are meaningless outside of the context of the ALTO server that defines them.

* A new cost metric gives the set of NEs involved in delivering packets from the source PID to the destination PID. Note that although those NEs are represented with a JSON array, the order is irrelevant; it really is a set.

* Like endpoints and PIDs, NEs can have properties. Eg, type, bandwidth, delay, etc.

* If the NE set from Pid1->Pid2 intersects the NE set from Pid3->Pid4, then the client knows those two flows are dependent: they may have a common point of failure, or they may limit each other, or whatever.

	- Wendy Roome

>that is in the middle between endpoints, e.g., a shared bottleneck of 
>two path vectors. Conceptually, this entity representing a shared 
>bottleneck is quite different to an endpoint: First, in many cases we 
>won?t expect that an application runs instances at such a bottleneck. 
>And second, these entities may use other identifiers. For instance, a 
>switch or a router may not have any globally unique IP address, or even 
>if it has one (e.g., router system address), the network operator may 
>not necessarily be interested in exposing this in an ALTO server, e.g., 
>to P2P applications.
>
>understand ?traditional? network and cost maps. In this case, it 
>probably makes sense not to expose in network maps those PIDs a ?legacy?

_______________________________________________
alto mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/alto

---

From: "Y. Richard Yang" <[email-masked]>
Date: Wed, 25 Feb 2015 16:24:21 -0500

I also support the terminology of Abstract Network Elements (ANE). The idea
of introducing an abstract network (graph) element that is a base for both
nodes (vertices) and links (edges) is clean. For example, this is also the
design of Blueprints; see
https://github.com/tinkerpop/blueprints/wiki/Property-Graph-Model.

Here are some more details that we need to agree on. The quoted sentences
are from Wendy's previous email:

Q1: "* A new cost metric gives the set of NEs involved in delivering packets
from the source PID to the destination PID. Note that although those NEs
are represented with a JSON array, the order is irrelevant; it really is a
set."

So this is by using cost map. All agree?

Q2: "* Like endpoints and PIDs, NEs can have properties. Eg, type,
bandwidth,
delay, etc."

What is the map (or maps) for such mapping of properties? We already have
endpoint properties. Ideally, this new mapping (and the additional PID
property mapping) should be designed to be consistent. All agree?

Thanks!
Richard

On Wed, Feb 25, 2015 at 4:09 PM, Scharf, Michael (Michael) <
[email-masked]> wrote:

> Regarding terminology: I like the idea of introducing an Abstract Network
> Elements (ANE). Maybe we could also use a term like Abstract Element/Entity
> (AE).
>
> We should probably avoid the acronym NE, since this is used by the network
> management community, but in a different context (typically implying a
> device).
>
> Michael
>
> NE can be a link, a router, a node, or some conglomeration of all of those.
> If you want to make it crystal clear that NEs can be a conglomerate, we
> could call them Abstract Network Elements, or ANEs.
>
> then the client knows those two flows are dependent: they may have a common
> point of failure, or they may limit each other, or whatever.
>
>         - Wendy Roome
>
>
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_alto&d=AwIFAw&c=-dg2m7zWuuDZ0MUcV7Sdqw&r=4G36iiEVb2m_v-0RnP2gx9KZJjYQgfvrOCE3789JGIA&m=vdG3SCjU9pqdD8xOwqkV0MWp35yXQg6YB5lY87ys60c&s=fw44WRIugHgS3r4A5CA2oBZOzuGPvZ24G3XHFSP5zD0&e=
>
> https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_alto&d=AwIFAw&c=-dg2m7zWuuDZ0MUcV7Sdqw&r=4G36iiEVb2m_v-0RnP2gx9KZJjYQgfvrOCE3789JGIA&m=vdG3SCjU9pqdD8xOwqkV0MWp35yXQg6YB5lY87ys60c&s=fw44WRIugHgS3r4A5CA2oBZOzuGPvZ24G3XHFSP5zD0&e=
>

---

From: "Y. Richard Yang" <[email-masked]>
Date: Wed, 25 Feb 2015 16:34:54 -0500

On Wed, Feb 25, 2015 at 4:24 PM, Y. Richard Yang <[email-masked]> wrote:

> I also support the terminology of Abstract Network Elements (ANE). The
> idea of introducing an abstract network (graph) element that is a base for
> both nodes (vertices) and links (edges) is clean. For example, this is also
> the design of Blueprints; see

Before we go too far regarding exposing path vectors to applications. One
issue is that there can be the issue of multi-path routing (e..g, ECMP).
Hence, a more general design is to use a flow model (see slides 10 to 12 of
http://www.ietf.org/proceedings/91/slides/slides-91-alto-4.pdf). I am sure
some (Greg? :-) and some will not. We need to reach an agreement on this.

>> We should probably avoid the acronym NE, since this is used by the
>> network management community, but in a different context (typically
>> implying a device).
>>
>> Michael
>>
>> I also prefer the separation strategy. I don't think we have enough
>> legacy clients to worry about (*sigh*), but a PID as a collection of
>> endpoints defined by a set of CIDRs is a simple, easy-to-understand
>> concept. Most ALTO clients will not care about topology. So why complicate
>> life for them?
>>

---

From: "Scharf, Michael (Michael)" <[email-masked]>
Date: Thu, 26 Feb 2015 10:14:05 +0000

Richard,

I’d like to understand a simpler question first; I don’t recall whether we have already discussed this basic scenario so far: Assume we have PID1  and PID2 and the ALTO server operator wants to announce that there are two entirely disjoint paths between those PIDs. The path vector would probably just include ANE1 and ANE2 as alternatives. Is there a way to encode this simple scenario in path vector without using the “general flow” model?

If we go for general flow, could we make the weight parameter optional?

Michael

PS: Other naming suggestions: Provider-Defined Network Element (PAE), Provider-Defined Topology Entity (PTE), Provider-Defined Path Element (PPE), or use of “Abstract” instead of “Provider-Defined”, or combinations thereof…

From: [email-masked] [mailto:[email-masked]] On Behalf Of Y. Richard Yang
Sent: Wednesday, February 25, 2015 10:35 PM
To: Scharf, Michael (Michael)
Cc: ROOME, Wendy D (Wendy); [email-masked]
Subject: Re: [alto] ALTO topology design: separation design

On Wed, Feb 25, 2015 at 4:24 PM, Y. Richard Yang <[email-masked]<mailto:[email-masked]>> wrote:
I also support the terminology of Abstract Network Elements (ANE). The idea of introducing an abstract network (graph) element that is a base for both nodes (vertices) and links (edges) is clean. For example, this is also the design of Blueprints; see https://github.com/tinkerpop/blueprints/wiki/Property-Graph-Model.

Here are some more details that we need to agree on. The quoted sentences are from Wendy's previous email:

Before we go too far regarding exposing path vectors to applications. One issue is that there can be the issue of multi-path routing (e..g, ECMP). Hence, a more general design is to use a flow model (see slides 10 to 12 of http://www.ietf.org/proceedings/91/slides/slides-91-alto-4.pdf). I am sure some (Greg? :-) and some will not. We need to reach an agreement on this.

Q2: "* Like endpoints and PIDs, NEs can have properties. Eg, type, bandwidth,
delay, etc."

What is the map (or maps) for such mapping of properties? We already have endpoint properties. Ideally, this new mapping (and the additional PID property mapping) should be designed to be consistent. All agree?

Thanks!
Richard

On Wed, Feb 25, 2015 at 4:09 PM, Scharf, Michael (Michael) <[email-masked]<mailto:[email-masked]>> wrote:
Regarding terminology: I like the idea of introducing an Abstract Network Elements (ANE). Maybe we could also use a term like Abstract Element/Entity (AE).

Michael

-----Ursprüngliche Nachricht-----
Von: alto [mailto:[email-masked]<mailto:[email-masked]>] Im Auftrag von Wendy Roome
Gesendet: Mittwoch, 25. Februar 2015 21:51
An: [email-masked]<mailto:[email-masked]>
Betreff: Re: [alto] ALTO topology design: separation design

        - Wendy Roome

>From: "Scharf, Michael (Michael)" <[email-masked]<mailto:[email-masked]>>

_______________________________________________
alto mailing list
[email-masked]<mailto:[email-masked]>
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_alto&d=AwIFAw&c=-dg2m7zWuuDZ0MUcV7Sdqw&r=4G36iiEVb2m_v-0RnP2gx9KZJjYQgfvrOCE3789JGIA&m=vdG3SCjU9pqdD8xOwqkV0MWp35yXQg6YB5lY87ys60c&s=fw44WRIugHgS3r4A5CA2oBZOzuGPvZ24G3XHFSP5zD0&e=

_______________________________________________
alto mailing list
[email-masked]<mailto:[email-masked]>
https://urldefense.proofpoint.com/v2/url?u=https-3A__www.ietf.org_mailman_listinfo_alto&d=AwIFAw&c=-dg2m7zWuuDZ0MUcV7Sdqw&r=4G36iiEVb2m_v-0RnP2gx9KZJjYQgfvrOCE3789JGIA&m=vdG3SCjU9pqdD8xOwqkV0MWp35yXQg6YB5lY87ys60c&s=fw44WRIugHgS3r4A5CA2oBZOzuGPvZ24G3XHFSP5zD0&e=

---

From: Wendy Roome <[email-masked]>
Date: Thu, 26 Feb 2015 09:25:51 -0500

I think the properties should be integrated into one ALTO service. But that
service needs to be a "Network Map" property service. That is, the unified
property resource should be bound to a specific network map, as opposed to
the current Endpoint Property Service, which is independent of the network
maps.

That new network map property service can associate properties with the
various entities related to a network map: endpoints, pids, ANEs, or
anything else that comes up in the future. Property names would be simple:
pid, bandwidth, asn, etc. For the entity names -- endpoints, pids, anes, etc
-- we could extend the set of address-type prefixes with "pid" and "ane".

So the request & response for a network map property service would look
something like this:

  Request:
      properties: pid asn bandwidth
      entities: ipv4:1.2.3.4  pid:pid2   ane:link42

  Response:
      meta: vtag of network map
      properties:
          ipv4:1.2.3.4: {pid: pid23  asn: 64600}
          pid:pid2: {asn: 64700}
          ane:link42 {bandwidth: 20}

The IRD for that resource specifies the names of the properties it can
return, and the entity types for which it can return properties.

In addition to the post-mode filtered property map service, an ALTO could
provide full property map resources for sets of properties and entity types
selected by the server. E.g., one get-mode resource might return the  asn
property for all pid entities, while another might return the bandwidth
property for all ane entities.

We could even define a full property map for endpoint properties. Granted,
it not practical to enumerate *all* endpoints. But for most ALTO servers, I
expect the endpoint->property map is very sparse. That is, the server only
defines properties for a small number of endpoints. In this case, the
endpoint-property full map would only return endpoints for which properties
are explicitly defined.

And if an ALTO server really does define properties for too many endpoints
to enumerate them all, the server simply does not provide a full-map
resource for endpoint properties.

Oh yes, the current endpoint property service would be flagged as a legacy,
and we would encourage servers to drop it and switch to network-map
properties.

What do folks think of this idea? I could present it in more detail in
Dallas if there is interest.

- Wendy Roome

From:  "Y. Richard Yang" <[email-masked]>
Date:  Wed, February 25, 2015 at 16:24
To:  "Scharf, Michael (Michael)" <[email-masked]>
Cc:  Wendy Roome <[email-masked]>, "[email-masked]"
<[email-masked]>
Subject:  Re: [alto] ALTO topology design: separation design

---

From: Wendy Roome <[email-masked]>
Date: Thu, 26 Feb 2015 09:43:48 -0500

The separation-approach can represent multiple paths by allowing a path-cost
to be an array of arrays of ANEs.  Eg, to indicate that PID1 -> PID2 can use
either ane1a & ane1b, or else ane2a & ane2b, we could use:

  {"PID1": {"PID2": [["ane1a", "ane1b"], ["ane2a", "ane2b"]]}
 
    - Wendy Roome

From:  "Scharf, Michael (Michael)" <[email-masked]>
Date:  Thu, February 26, 2015 at 05:14
To:  "Y. Richard Yang" <[email-masked]>
Cc:  Wendy Roome <[email-masked]>, "[email-masked]"
<[email-masked]>
Subject:  RE: [alto] ALTO topology design: separation design

Richard,
 
I¹d like to understand a simpler question first; I don¹t recall whether we
have already discussed this basic scenario so far: Assume we have PID1  and
PID2 and the ALTO server operator wants to announce that there are two
entirely disjoint paths between those PIDs. The path vector would probably
just include ANE1 and ANE2 as alternatives. Is there a way to encode this
simple scenario in path vector without using the ³general flow² model?

Michael