Subject: Re: [Idr] [irs-discuss] About ALTO Vs. BGP-LS

From: "Y. Richard Yang" <[email-masked]>
Date: Fri, 03 Aug 2012 11:46:12 -0700

Hi,

Sue suggested that I forward this email to idr for more discussions.

Thanks.

Richard

On 8/3/12 11:24 AM, Susan Hares wrote:
> Richard:
>
> Could you cross-post this note to the [email-masked] list. The BGP-LS draft is being considered for WG adoption. I think this perspective would help the idr WG.
>
> Thank you,
>
> Sue
>
> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of Y. Richard Yang
> Sent: Friday, August 03, 2012 11:04 AM
> To: stefano previdi
> Cc: Thomas Nadeau; James Kempf; IETF ALTO; [email-masked]; [email-masked]
> Subject: Re: [irs-discuss] About ALTO Vs. BGP-LS
>
> Hi Stefano,
>
> Good post! I added the ALTO mailing list, given the relevance. I hope
> that this is OK cross posting.
>
> First, a few comments on ALTO:
>
> View granularity:
>
> - ALTO currently defines two abstract network topology data structures:
> Network Map and Cost Map(s). More link-state oriented maps (graphs),
> with aggregations and transformations, can be added efficiently to ALTO.
> Some initial efforts are already on the way (e.g., see the graph
> representation proposal at page 9:
> http://www.ietf.org/proceedings/84/slides/slides-84-alto-1.pdf). Hence,
> I see a natural next-step is for ALTO to provide a link-state view to
> external entities.
>
> - It is a good comment on the level of details that ALTO should
> deliver. This is a good question for the ALTO working group and the
> community to discuss. I feel that ALTO should provide multi-levels of
> granularity of views, and we should discuss in the working group.
>
> Pull vs push delivery mechanism:
>
> - There are more discussions on adding the incremental update in ALTO.
> Multiple mechanisms have been discussed. I feel that it is the right
> direction for ALTO.
>
> Now let me understand the deployment model of BGP-LS. Your explanation
> on the issues of acquiring routing state is excellent. Let me start by
> understanding more details on the deployment model of BGP-LS inside a
> network:
>
> - A set N_igp of BGP-LS instances are deployed to collect IGP info. You
> need multiple instances because IGP needs direct connectivity
> (adjacency). Each instance here receives (potentially multiple) IGP
> updates and streams (relays) to an another (remote) entity, which I
> assume is a master BGP-LS instance. So each of these N_igp instances is
> IGP-in and BGP-LS out. This appears to be shown in Figure 1 of
> draft-gredler-idr-ls-distribution.
>
> - A set N_egp of BGP-LS instances are deployed to collect BGP feeds. You
> also may need multiple instances because the network does not want to
> see aggregated states but raw states. These instances will feed to the
> master BGP-LS as well.
>
> - The master BGP-LS aggregates the multiple BGP-LS ins (and maybe some
> direct IGP/EGP ins) and pushes (after policy) to other BGP-LS peers to
> use: for example, an ALTO Server transforms/aggregates the feed to
> generate ALTO views (maps and graphs), and an PCE uses the feed to
> maintain its TED. One could even imagine that ALTO builds a detailed TED
> and feeds to PCE, but this beyond the scope of this discussion. The
> master BGP-LS is BGP-LS in and BGP-LS out. It is also possible that the
> master BGP-LS does not push to any other entities and simply maintains
> an internal DB for others to query.
>
> Do I understand it correctly?
>
> Now, we can take a look at more specifics of BGP-LS.
>
> A first perspective is the semantics of the content. If the objective is
> to solve the aforementioned deployment issue, then an alternative
> solution is to introduce a simple LS update tunneling protocol, where a
> link-state proxy forwards LS messages to a collector. The current design
> of BGP-LS starts with such a feeling (i.e., an NLRI starts with the
> Protocol ID, which indicates it is from IS-IS level 1 IS-IS level 2,
> OSPF, etc).  However, the protocol appears to (try to) go beyond simple
> tunneling and introduces a common LS schema, by converting/filtering
> individual IGP LS messages to some common format. I feel that it can be
> helpful to first specify the schema (LS data model) instead of the
> specific encoding. For example, OSPF specifies LS Age, and this is
> filtered. (Please correct me if I missed it). On the other hand, one can
> think that some Age info can be helpful for one to understand the
> "freshness" of the LS. A problem studied in database is heterogeneous
> databases, to merge multiple data sources (IS-IS, OSPF, etc) to a single
> schema, and there can be many problems. If there is such a study, please
> do share a pointer.
>
> A second perspective is using BGP as the transport. What key features
> from BGP do we really need (yes, weak-typed TLV encoding offers a lot of
> flexibility)? What features of BGP do we not need (e.g., BGP is a
> routing protocol and hence builds in features to handle convergence such
> as dampening)? What may be missing (e.g., a capability of pull or
> filtering of push). I feel that these issues should be discussed. If
> they have already been discussed, please do share a pointer, as I am
> definitely a new comer.
>
> Thanks!
>
> Richard
>
> On 8/2/12 11:54 PM, stefano previdi wrote:
>> All,
>>
>> as co-author of both BGP-LS and ALTO drafts, I'd try to clarify a few
>> things:
>>
>> ALTO has been designed in order to deliver to applications (through
>> http/json):
>>
>> 1. two maps representing the network topology in an abstracted view
>>      (or set of views through multiple maps). The map does not include
>>      the details of a link-state database and therefore have little use
>>      for any element that would need to retrieve from the network the
>>      detailed/complete network layer topology, for example: link
>>      addresses or link BW resources, etc. IOW: ALTO maps do not have
>>      the granularity of a link-state database and ALTO protocol is not
>>      designed to deliver such details.
>>
>> and/or
>>
>> 2. Ranking services where a client sends a bunch of IP addresses in
>>      a message and the ALTO server replies by ranking these addresses
>>      based on their topological/network distance (or whatever criteria
>>      the ALTO server has been configured for). This is called: Endpoint
>>      Cost Service.
>>
>> When using ALTO maps, and the ALTO protocol being http/pull based,
>> there's no such concept of unsolicited routing updates. An ALTO
>> client is typically a browser that will pull the maps from an ALTO
>> server using http. The ALTO server will make no effort to ensure the
>> client has the latest view of the topology (i.e.: It's the role of the
>> client to poll for new maps time to time).
>>
>> Now, in order for an ALTO server to deliver Maps or Ranking services,
>> it needs to build some form of topology and in order to achieve this,
>> it needs somehow to be fed by either the operator (configuration) or
>> to receive dynamically topology information from the network (e.g.:
>> ISIS/OSPF/BGP).
>>
>> Here we had two options:
>> 1. ALTO server to implement ISIS/OSPF/BGP and establish IGP adjacencies
>>      to ABRs or L1L2 routers in each area so to retrieve the LSDB from
>>      each area. In practice I know no SP willing/accepting to open their
>>      IGP to an ALTO server. Also, IGP requires direct connectivity
>>      (adjacency) so from an operation point of view is complex and not
>>      desired.
>> 2. Use a database distribution protocol running on top of a reliable
>>      transport layer that would allow an ALTO server to connect to a
>>      _single_ and _remote_ Route Reflector (i.e.: no need to be directly
>>      connected) and grab the whole network topology that will be updated
>>      using standard routing protocol mechanisms (i.e.: routing updates)
>>      and that would allow the operator to control (through policies and
>>      filters) what to distribute and to which server.
>>
>>      Benefits: single (or dual at most for redundancy) connection for
>>      the ALTO server (rather than having a direct adjacency with each
>>      ABR) and, from the operator perspective, single point of
>>      distribution of network topology (easier to apply policies and
>>      control what you deliver). This is what BGP-LS is about.
>>
>> BGP-LS defines new AFI/SAFI for a new NLRI and attributes that convey
>> link-state and, more generically, any type of topology information.
>> The draft specifies NLRI and attributes that map whatever you can
>> find in a link-state database.
>>
>> We currently have draft-gredler-idr-ls-distribution in the process
>> (hopefully) to be adopted as WG item in IDR WG (so far we 're getting
>> good support). We also have 3 implementations of BGP-LS.
>>
>> Deployment-wise: BGP-LS is not yet deployed, however, we already have
>> deployments (I know at least two) where an ALTO server retrieves IP
>> prefix information from remote BGP RRs (for ipv4). The same scheme
>> will be used once BGP-LS will be deployed (so to say that it is not
>> something that we invented after a couple of beers but corresponds to
>> requirements for delivering network services to upper layers while
>> still controlling efficiently what you distribute, to whom and in
>> which form (note that, often, beers are anyway part of the process).
>>
>> More information here:
>> http://tools.ietf.org/html/draft-gredler-idr-ls-distribution-02
>> http://tools.ietf.org/html/draft-ietf-alto-protocol-12
>>
>> Hope this helps.
>>
>> s.
>>
>>
>>
>> On Aug 3, 2012, at 1:29 AM, Robert Raszuk wrote:
>>> Tom,
>>>
>>>> I agree that one of the top work items for this effort should be a
>>>> standardized topology function, and one that is accessible via a
>>>> non-routing protocol.
>>> So if the requirement is to have topology export via non-routing protocol then I think we should seriously revisit or repackage the draft-gredler-idr-ls-distribution-01 which works for for both OSPF and ISIS.
>>>
>>> However before that let's really understand the requirement why it must be exported via non-routing protocol .... Keep in mind that just to parse BGP UPDATE messages and retrieve interesting pieces out it it requires very little code rather then full BGP implementation.
>>>
>>> The particular feature I like about draft-gredler-idr-ls-distribution-01 is that it is read-only ;)
>>>
>>> R.
>>>
>>>> 	I agree that one of the top work items for this effort should be a
>>>> standardized topology function, and one that is accessible via a
>>>> non-routing protocol.  While not exactly "low hanging fruit", it is
>>>> something that (to me) is a clear work item with clear goals that should
>>>> be tackled straight away.
>>>>
>>>> 	--Tom
>>>>
>>>>
>>>>
>>>> On 8/2/12 3:24 PM, "James Kempf" <[email-masked]> wrote:
>>>>
>>>>> So after seeing part of Alia's talk this morning (I had to leave in the
>>>>> middle unfortunately), I'd like to make a couple suggestions. There were
>>>>> a lot of ideas presented in the talk, enough for an entire IETF Area. I
>>>>> think to make tangible progress, the work needs to be focussed on a small
>>>>> subset that would be of immediate interest and usability.
>>>>>
>>>>> There are a couple areas that suggest themselves, but one that would be
>>>>> useful in work that I've been involved in is a standardized format for
>>>>> network topology representation and a protocol for exchanging it. The
>>>>> Onix OpenFlow controller has a network information base with a
>>>>> specialized format for network topology, and every OpenFlow controller
>>>>> requires this. Having a standardized way to represent it might foster a
>>>>> common topology database package. Another application is network
>>>>> management. Every network management system needs some kind of topology
>>>>> representation. Finally, though I am not an expert in PCE construction,
>>>>> it would seem to me that a PCE would need some kind of topology
>>>>> representation in order to perform path calculations. Having a way,for
>>>>> example, for the OpenFlow controller and the PCE to exchange topology
>>>>> information would be really useful.  I would say to start with physical
>>>>> topology because that is fundamental, but make the format flexible enough
>>>>> to support
>>>>> virtual topology representation.
>>>>>
>>>>> 			jak
>>>>> _______________________________________________
>>>>> irs-discuss mailing list
>>>>> [email-masked]
>>>>> https://www.ietf.org/mailman/listinfo/irs-discuss
>>>> _______________________________________________
>>>> irs-discuss mailing list
>>>> [email-masked]
>>>> https://www.ietf.org/mailman/listinfo/irs-discuss
>>>>
>>>>
>>> _______________________________________________
>>> irs-discuss mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/irs-discuss
>>>
>> _______________________________________________
>> irs-discuss mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/irs-discuss
> _______________________________________________
> irs-discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/irs-discuss

---

From: "Y. Richard Yang" <[email-masked]>
Date: Fri, 03 Aug 2012 13:50:33 -0700

Hi Volker,

On 8/3/12 12:02 PM, Volker Hilt wrote:
>
> I believe that the capability to provide a simplified view on the 
> network topology to an application is a key feature rather than a bug. 
> Applications that want to have a view on network topology don't need 
> need a fine grained view on the topology in most casts and benefit 
> from having an abstracted view. This will simplify processing for the 
> application and enables providers to control the exposure of details. 
Agreed.

> We've seen some numbers for topology data sizes in the incremental 
> updates presentation in the ALTO meeting, which provide some insights 
> into the amounts of data needed for different topology sizes.
>
> I like the idea of enabling an ALTO server to offer different levels 
> of details. This will enable a server to tailor responses to the 
> specific client. It will add complexity as the ALTO server itself will 
> have to maintain the most complex topology it is offering and will 
> have to keep this topology up to date. But this is an interesting 
> question for discussion in the WG.
>
Glad that you also like the idea of different levels of details of the 
network topology. If the ALTO Server is given a detailed topology 
(constructed from multiple sources, such as routing feed, LSP feed, 
configuration files), we can offer multiple topology 
operators/aggregators to explore the detailed topology, according to 
need and policy. A simple example operator is level (i.e., hierarchy 
such as at the area level), but one might specify other operators (e.g., 
fisheye focus). There are studies on representation of multi-level 
graphs that we can try to take advantage of. This can be a subject for 
the group to explore.

We may need to study/collect use cases for multiple level topology. One 
interesting example immediately coming to mind is the Abstract Node 
concept (specify IP prefix/ASN) used in RSVP-TE.

Cheers,

Richard

> Cheers,
>
> Volker
>
>
>
>
>
>
>
> On 03.08.2012 11:03, Y. Richard Yang wrote:
>> Hi Stefano,
>>
>> delivery. This is a good question for the ALTO working group and the
>>>> So if the requirement is to have topology export via non-routing
>>>> protocol then I think we should seriously revisit or repackage the
>>>> draft-gredler-idr-ls-distribution-01 which works for for both OSPF
>>>> and ISIS.
>>>>
>>>> However before that let's really understand the requirement why it
>>>> must be exported via non-routing protocol .... Keep in mind that just
>>>> to parse BGP UPDATE messages and retrieve interesting pieces out it
>>>> it requires very little code rather then full BGP implementation.
>>>>
>>>> The particular feature I like about
>>>> draft-gredler-idr-ls-distribution-01 is that it is read-only ;)
>>>>
>>>> R.
>>>>

---

From: Susan Hares <[email-masked]>
Date: Fri, 3 Aug 2012 18:54:07 +0000

IDR people:

This discussion has been occurring on the [email-masked] list.  Please consider the questions that Richard asks about the BGP-LS work in your decision to adopt the BGP-LS work as a WG draft.

Sue 

[snip]

---

From: Volker Hilt <[email-masked]>
Date: Fri, 3 Aug 2012 12:02:31 -0700

Stefano, Richard,

great discussion.

I believe that the capability to provide a simplified view on the 
network topology to an application is a key feature rather than a bug. 
Applications that want to have a view on network topology don't need 
need a fine grained view on the topology in most casts and benefit from 
having an abstracted view. This will simplify processing for the 
application and enables providers to control the exposure of details. 
We've seen some numbers for topology data sizes in the incremental 
updates presentation in the ALTO meeting, which provide some insights 
into the amounts of data needed for different topology sizes.

I like the idea of enabling an ALTO server to offer different levels of 
details. This will enable a server to tailor responses to the specific 
client. It will add complexity as the ALTO server itself will have to 
maintain the most complex topology it is offering and will have to keep 
this topology up to date. But this is an interesting question for 
discussion in the WG.

Cheers,

Volker

---

From: Alia Atlas <[email-masked]>
Date: Fri, 3 Aug 2012 19:57:07 -0400

I strongly agree that we need to start collecting the use-cases for
multiple abstraction levels as well as physical/virtual/private.

Alia
On Aug 3, 2012 4:51 PM, "Y. Richard Yang" <[email-masked]> wrote:

>> I believe that the capability to provide a simplified view on the network
>> topology to an application is a key feature rather than a bug. Applications
>> that want to have a view on network topology don't need need a fine grained
>> view on the topology in most casts and benefit from having an abstracted
>> view. This will simplify processing for the application and enables
>> providers to control the exposure of details.
>>
> Agreed.
>
>> updates presentation in the ALTO meeting, which provide some insights into
>> the amounts of data needed for different topology sizes.
>>
> configuration files), we can offer multiple topology operators/aggregators
> to explore the detailed topology, according to need and policy. A simple
> example operator is level (i.e., hierarchy such as at the area level), but
> one might specify other operators (e.g., fisheye focus). There are studies
> on representation of multi-level graphs that we can try to take advantage
> of. This can be a subject for the group to explore.
>
> interesting example immediately coming to mind is the Abstract Node concept
> (specify IP prefix/ASN) used in RSVP-TE.
>
> Cheers,
>
> Richard
>
>  Cheers,
>>
>> Volker
>>
>>
>>
>>
>>
>>
>>
>>> http://www.ietf.org/**proceedings/84/slides/slides-**84-alto-1.pdf<http://www.ietf.org/proceedings/84/slides/slides-84-alto-1.pdf>).
>>> Hence,
>>> draft-gredler-idr-ls-**distribution.
>>>
>>>> We currently have draft-gredler-idr-ls-**distribution in the process
>>>> http://tools.ietf.org/html/**draft-gredler-idr-ls-**distribution-02<http://tools.ietf.org/html/draft-gredler-idr-ls-distribution-02>
>>>> http://tools.ietf.org/html/**draft-ietf-alto-protocol-12<http://tools.ietf.org/html/draft-ietf-alto-protocol-12>
>>>>
>>>> Hope this helps.
>>>>
>>>> s.
>>>>
>>>>
>>>>
>>>>> draft-gredler-idr-ls-**distribution-01 which works for for both OSPF
>>>>> and ISIS.
>>>>>
>>>>> draft-gredler-idr-ls-**distribution-01 is that it is read-only ;)
>>>>>
>>>>> R.
>>>>>
>>>>>>> ______________________________**_________________
>>>>>>> irs-discuss mailing list
>>>>>>> [email-masked]
>>>>>>> https://www.ietf.org/mailman/**listinfo/irs-discuss<https://www.ietf.org/mailman/listinfo/irs-discuss>
>>>>>>>
>>>>>> ______________________________**_________________
>>>>>> irs-discuss mailing list
>>>>>> [email-masked]
>>>>>> https://www.ietf.org/mailman/**listinfo/irs-discuss<https://www.ietf.org/mailman/listinfo/irs-discuss>
>>>>>>
>>>>>>
>>>>>>  ______________________________**_________________
>>>>> irs-discuss mailing list
>>>>> [email-masked]
>>>>> https://www.ietf.org/mailman/**listinfo/irs-discuss<https://www.ietf.org/mailman/listinfo/irs-discuss>
>>>>>
>>>>>  ______________________________**_________________
>>>> irs-discuss mailing list
>>>> [email-masked]
>>>> https://www.ietf.org/mailman/**listinfo/irs-discuss<https://www.ietf.org/mailman/listinfo/irs-discuss>
>>>>
>>>
>>> ______________________________**_________________
>>> irs-discuss mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/**listinfo/irs-discuss<https://www.ietf.org/mailman/listinfo/irs-discuss>
>>>
>> ______________________________**_________________
> irs-discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/**listinfo/irs-discuss<https://www.ietf.org/mailman/listinfo/irs-discuss>
>

---

From: Hannes Gredler <[email-masked]>
Date: Mon, 6 Aug 2012 20:01:49 +0200

richard,

[ ... ]
| > Now, we can take a look at more specifics of BGP-LS.
| >
| > A first perspective is the semantics of the content. If the objective is
| > to solve the aforementioned deployment issue, then an alternative
| > solution is to introduce a simple LS update tunneling protocol, where a
| > link-state proxy forwards LS messages to a collector. The current design
| > of BGP-LS starts with such a feeling (i.e., an NLRI starts with the
| > Protocol ID, which indicates it is from IS-IS level 1 IS-IS level 2,
| > OSPF, etc).  However, the protocol appears to (try to) go beyond simple
| > tunneling and introduces a common LS schema, by converting/filtering
| > individual IGP LS messages to some common format. I feel that it can be
| > helpful to first specify the schema (LS data model) instead of the
| > specific encoding. For example, OSPF specifies LS Age, and this is
| > filtered. (Please correct me if I missed it). On the other hand, one can
| > think that some Age info can be helpful for one to understand the
| > "freshness" of the LS. A problem studied in database is heterogeneous
| > databases, to merge multiple data sources (IS-IS, OSPF, etc) to a single
| > schema, and there can be many problems. If there is such a study, please
| > do share a pointer.

one of the base ideas of BGP-LS has been to present a topology in a protocol
neutral form. As such it nicely solves the case where more than one
IGP (OSPF at the edge, IS-IS in the core) has been deployed.
It per does not flood IGP LSAs (including age), but rather the
normalized content of those LSAs - i find age information for the
topology less interesting as age it is purely for garbage collection.

| > A second perspective is using BGP as the transport. What key features
| > from BGP do we really need (yes, weak-typed TLV encoding offers a lot of
| > flexibility)? What features of BGP do we not need (e.g., BGP is a
| > routing protocol and hence builds in features to handle convergence such
| > as dampening)? What may be missing (e.g., a capability of pull or
| > filtering of push). I feel that these issues should be discussed.

wether BGP is a "routing-protocol" per se or not is mildly ;-) controversial
debate which we certainly cannot get full agreement by all list participants -
so let me present my view on that:

the way i see BGP is more as a multipoint (reflectors !) IPC facility where i can publish
state for the "universe". to my knowledge there are is no alternative protocol
that allows me to distribute state over a generic p2mp distribution graph.
so the reason BGP is so attractive as a generic state distribution mechanism
is because "its there" and it "works" and it has been abused exacatly
because of that by others in the past :-)

/hannes

---

From: Hannes Gredler <[email-masked]>
Date: Mon, 6 Aug 2012 20:39:11 +0200

richard,

[ ... ]

/hannes

---

From: "Y. Richard Yang" <[email-masked]>
Date: Mon, 06 Aug 2012 12:36:04 -0700

Hi Hannes,

> topology less interesting as age it is purely for garbage collection.
Providing a unified (protocol-neutral) topology state distribution
mechanism (in particular, merging the states of OSPF/IS-IS, and
maybe other protocols such as DV based protocols, which can be
trickier to merge) has definitely a good value. I definitely support
this effort. At the current moment, I see two issues to be discussed:

- A protocol-neutral LS schema. For example, in the current BGP-LS
draft, there are still (OSPF, IS-IS level 1, ...) protocol-specific 
attributes
(e.g., Table 3 Type 277/278), and indicated so. Should they be
mapped to a neutral encoding?

- Do we need to agree on the semantics of a common protocol-neutral
LS topology? For example, consider two OSPF routers R1 and R2 who
may see each other in the Hello packets, but they have a mismatch
(e.g., due to mis-configuration) on their agreed fields (e.g.,
Hello/Dead intervals). Hence, the OSPF protocol, in its specific-specific
way, says that R1 and R2 are not neighbors. Defining such semantics
and collecting them (e.g., the mismatch field example) can be challenge,
but they can be a good step forward. What do you think?
> that allows me to distribute state over a generic p2mp distribution graph.
I can think of (distributed) hash tables and other pub/sub protocols as 
some kind of
alternative. BGP has its advantages of introducing policies, but we
may need to look at its match. What do you think?

Thanks!

Richard

---

From: Hannes Gredler <[email-masked]>
Date: Mon, 6 Aug 2012 22:47:22 +0200

On Mon, Aug 06, 2012 at 12:36:04PM -0700, Y. Richard Yang wrote:
| Hi Hannes,
| 
| On 8/6/12 11:01 AM, Hannes Gredler wrote:
| >richard,
| >
| >[ ... ]
| >| > Now, we can take a look at more specifics of BGP-LS.
| >| >
| >| > A first perspective is the semantics of the content. If the objective is
| >| > to solve the aforementioned deployment issue, then an alternative
| >| > solution is to introduce a simple LS update tunneling protocol, where a
| >| > link-state proxy forwards LS messages to a collector. The current design
| >| > of BGP-LS starts with such a feeling (i.e., an NLRI starts with the
| >| > Protocol ID, which indicates it is from IS-IS level 1 IS-IS level 2,
| >| > OSPF, etc).  However, the protocol appears to (try to) go beyond simple
| >| > tunneling and introduces a common LS schema, by converting/filtering
| >| > individual IGP LS messages to some common format. I feel that it can be
| >| > helpful to first specify the schema (LS data model) instead of the
| >| > specific encoding. For example, OSPF specifies LS Age, and this is
| >| > filtered. (Please correct me if I missed it). On the other hand, one can
| >| > think that some Age info can be helpful for one to understand the
| >| > "freshness" of the LS. A problem studied in database is heterogeneous
| >| > databases, to merge multiple data sources (IS-IS, OSPF, etc) to a single
| >| > schema, and there can be many problems. If there is such a study, please
| >| > do share a pointer.
| >
| >one of the base ideas of BGP-LS has been to present a topology in a protocol
| >neutral form. As such it nicely solves the case where more than one
| >IGP (OSPF at the edge, IS-IS in the core) has been deployed.
| >It per does not flood IGP LSAs (including age), but rather the
| >normalized content of those LSAs - i find age information for the
| >topology less interesting as age it is purely for garbage collection.
| Providing a unified (protocol-neutral) topology state distribution
| mechanism (in particular, merging the states of OSPF/IS-IS, and
| maybe other protocols such as DV based protocols, which can be
| trickier to merge) has definitely a good value. I definitely support
| this effort. At the current moment, I see two issues to be discussed:
| 
| - A protocol-neutral LS schema. For example, in the current BGP-LS
| draft, there are still (OSPF, IS-IS level 1, ...) protocol-specific
| attributes
| (e.g., Table 3 Type 277/278), and indicated so. Should they be
| mapped to a neutral encoding?

those are not attributes ...
the protocol origin codes (IS-IS L1, IS-IS L2, OSPF) you are referring to
are more to discriminate concurent operation of more than one protocol
over a given link .... the semantics are "this is the link
as advertised from source-protocol-X"
 
furthermore certain attributes are protocol specific since there exists
no representation in the respective other protocol (think e.g. of the
IS-IS overload, ATT bits)

| - Do we need to agree on the semantics of a common protocol-neutral
| LS topology? For example, consider two OSPF routers R1 and R2 who
| may see each other in the Hello packets, but they have a mismatch
| (e.g., due to mis-configuration) on their agreed fields (e.g.,
| Hello/Dead intervals). Hence, the OSPF protocol, in its specific-specific
| way, says that R1 and R2 are not neighbors. Defining such semantics
| and collecting them (e.g., the mismatch field example) can be challenge,
| but they can be a good step forward. What do you think?

alia and tom have made a similar observation before, they're concerned
about e.g. an "inactive" topology similar to your example above.
today everything which gets advertised has semantics of an "active" topology.
it would certainly be possible to carry a TBD "link-status" attribute
if the case for this is appealing ...

| >| > A second perspective is using BGP as the transport. What key features
| >| > from BGP do we really need (yes, weak-typed TLV encoding offers a lot of
| >| > flexibility)? What features of BGP do we not need (e.g., BGP is a
| >| > routing protocol and hence builds in features to handle convergence such
| >| > as dampening)? What may be missing (e.g., a capability of pull or
| >| > filtering of push). I feel that these issues should be discussed.
| >
| >wether BGP is a "routing-protocol" per se or not is mildly ;-) controversial
| >debate which we certainly cannot get full agreement by all list participants -
| >so let me present my view on that:
| >
| >the way i see BGP is more as a multipoint (reflectors !) IPC facility where i can publish
| >state for the "universe". to my knowledge there are is no alternative protocol
| >that allows me to distribute state over a generic p2mp distribution graph.
| I can think of (distributed) hash tables and other pub/sub protocols
| as some kind of alternative.

| BGP has its advantages of introducing policies, but we
| may need to look at its match. What do you think?

for me the match is close to 100%, but i am admittedly biased ;-)

in the implementation that i am familiar with, we have added some policy support,
such that you can filter based on the link{local,remote} IDs which is rather static.
adding some ore sophisticated construction of the flooding graph using the BGP
established pub/sub tools (rfc4684) is certainly an option if there is interest.

| >so the reason BGP is so attractive as a generic state distribution mechanism
| >is because "its there" and it "works" and it has been abused exacatly
| >because of that by others in the past :-)

---

From: Volker Hilt <[email-masked]>
Date: Tue, 7 Aug 2012 13:16:54 +0200

Richard,
> graphs that we can try to take advantage of. This can be a subject for
Yes, I agree - this is an interesting area to explore. Another operator 
could be a view for a specific use, e.g., a view for CDN use. The 
operator can then populate this view with the desired abstraction level 
and policy.

> concept (specify IP prefix/ASN) used in RSVP-TE.
Indeed.

Volker

---

From: Greg Bernstein <[email-masked]>
Date: Thu, 09 Aug 2012 08:47:09 -0700

Some questions and comments on IRS, IDR, and ALTO...

Would IRS apply to GMPLS controlled boxes such as TDM (G.709, SDH) or 
WDM (WSON) network elements?
Setting state in a GMPLS controlled box can be rather trivial, i.e., 
just setting up a cross connect. The penalties for screwing up the state 
in a WDM box are rather terrible... Would IRS want state for all the 
LSP's traversing a box?

I'm a infrastructure plumber and trying to get folks to use the nifty 
optical control plane more. In GMPLS we have technology specific data 
models (SDH, G.709, WSON) that are fairly independent of specific 
routing protocols (OSPF, IS-IS) so these can help with the modeling 
aspect of IRS.  However, in the early days of GMPLS folks thought 
everything should be done in the same IGP instance, later the OSPF folks 
decided multiple instances were better since the service impacts of 
routing protocols is much different for circuit switched technologies 
than IP.

The model we are interested for in large-bandwidth use-cases in ALTO 
tries to abstract away as many layers as possible.  For example, suppose 
that the use-case is to set up a large IP pipe between mulitple data 
centers.  We could show an abstracted graph that helps guide paths 
choices via costs and bandwidth constraints.  The actual implementation 
technology could be IP-MPLS-G.709-MPLS-IP  or 
IP-OpenFlow-WSON-OpenFlow-IP  (here I just mean a simple OpenFlow 
controlled Ethernet switch that that can feed into our optical "express 
lane").
In other cases the data centers might want some special ethernet 
connectivity over optical pipes (a different type of service).

When I think of an IDR and sharing information between ASs then one may 
want to (or need to) keep (sub-IP) layer specific for compatibility, 
i.e., connecting the pipes between domains and adapting the higher layer 
protocols back out.  It's useful to look at publicly available service 
maps for examples, I like Level3's maps 
(http://maps.level3.com/default/#.UCFpjJYu9rh) --compare wavelength 
services to other services -- and CenturyLink 
(http://www.centurylink-business.com/demos/network-maps.html) -- note 
how wavelength service availability is limited compared to other 
services (our big pipe networks are generally simpler than other service 
networks) --.

It seems what BGP-LS would deliver to an ALTO server to digest and serve 
up in abstracted form could be very different from what might be shared 
between ASes.

Cheers
Greg

On 8/3/2012 4:57 PM, Alia Atlas wrote:
> On Aug 3, 2012 4:51 PM, "Y. Richard Yang" <[email-masked] 
> <mailto:[email-masked]>> wrote:
>
>     Hi Volker,
>
>         I believe that the capability to provide a simplified view on
>         the network topology to an application is a key feature rather
>         than a bug. Applications that want to have a view on network
>         topology don't need need a fine grained view on the topology
>         in most casts and benefit from having an abstracted view. This
>         will simplify processing for the application and enables
>         We've seen some numbers for topology data sizes in the
>         incremental updates presentation in the ALTO meeting, which
>         provide some insights into the amounts of data needed for
>         different topology sizes.
>
>         I like the idea of enabling an ALTO server to offer different
>         levels of details. This will enable a server to tailor
>         responses to the specific client. It will add complexity as
>         the ALTO server itself will have to maintain the most complex
>         topology it is offering and will have to keep this topology up
>         to date. But this is an interesting question for discussion in
>         the WG.
>
>     Glad that you also like the idea of different levels of details of
>     the network topology. If the ALTO Server is given a detailed
>     topology (constructed from multiple sources, such as routing feed,
>     LSP feed, configuration files), we can offer multiple topology
>     operators/aggregators to explore the detailed topology, according
>     to need and policy. A simple example operator is level (i.e.,
>     hierarchy such as at the area level), but one might specify other
>     operators (e.g., fisheye focus). There are studies on
>     representation of multi-level graphs that we can try to take
>     advantage of. This can be a subject for the group to explore.
>
>     We may need to study/collect use cases for multiple level
>     topology. One interesting example immediately coming to mind is
>     the Abstract Node concept (specify IP prefix/ASN) used in RSVP-TE.
>
>     Cheers,
>
>     Richard
>
>         Cheers,
>
>         Volker
>
>
>
>
>
>
>
>                         something that (to me) is a clear work item
>                         with clear goals that
>                         should
>                         On 8/2/12 3:24 PM, "James Kempf"
>                         <[email-masked]
>                         <mailto:[email-masked]>> wrote:
>
>                             So after seeing part of Alia's talk this
>                             morning (I had to leave in
>                             the
>                             middle unfortunately), I'd like to make a
>                             couple suggestions. There
>                             were
>                             a lot of ideas presented in the talk,
>                             enough for an entire IETF
>                             Area. I
>                             think to make tangible progress, the work
>                             needs to be focussed on a
>                             small
>                             There are a couple areas that suggest
>                             themselves, but one that
>                             would be
>                             requires this. Having a standardized way
>                             to represent it might
>                             foster a
>                             management. Every network management
>                             system needs some kind of
>                             topology
>                             representation. Finally, though I am not
>                             an expert in PCE
>                             construction,
>                             topology because that is fundamental, but
>                             make the format flexible
>                             enough
>                             to support
>                             <mailto:[email-masked]>
>                         [email-masked] <mailto:[email-masked]>
>                     [email-masked] <mailto:[email-masked]>
>                 [email-masked] <mailto:[email-masked]>
>             [email-masked] <mailto:[email-masked]>
>     [email-masked] <mailto:[email-masked]>
> alto mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/alto

-- 
===================================================
Dr Greg Bernstein, Grotto Networking (510) 573-2237

---

From: Hannes Gredler <[email-masked]>
Date: Thu, 9 Aug 2012 17:57:45 +0200

hi greg,

see comments inline prefixed by HG>

On Thu, Aug 09, 2012 at 08:47:09AM -0700, Greg Bernstein wrote:
| Some questions and comments on IRS, IDR, and ALTO...
| 
| Would IRS apply to GMPLS controlled boxes such as TDM (G.709, SDH) or WDM
| (WSON) network elements?
| Setting state in a GMPLS controlled box can be rather trivial, i.e., just
| setting up a cross connect. The penalties for screwing up the state in a WDM
| box are rather terrible... Would IRS want state for all the LSP's traversing a
| box?
| 
| I'm a infrastructure plumber and trying to get folks to use the nifty optical
| control plane more. In GMPLS we have technology specific data models (SDH,
| G.709, WSON) that are fairly independent of specific routing protocols (OSPF,
| IS-IS) so these can help with the modeling aspect of IRS.  However, in the
| early days of GMPLS folks thought everything should be done in the same IGP
| instance, later the OSPF folks decided multiple instances were better since the
| service impacts of routing protocols is much different for circuit switched
| technologies than IP.
| 
| The model we are interested for in large-bandwidth use-cases in ALTO tries to
| abstract away as many layers as possible.  For example, suppose that the use-
| case is to set up a large IP pipe between mulitple data centers.  We could show
| an abstracted graph that helps guide paths choices via costs and bandwidth
| constraints.  The actual implementation technology could be IP-MPLS-G.709-MPLS-
| IP  or IP-OpenFlow-WSON-OpenFlow-IP  (here I just mean a simple OpenFlow
| controlled Ethernet switch that that can feed into our optical "express lane").
| 
| In other cases the data centers might want some special ethernet connectivity
| over optical pipes (a different type of service).
| 
| When I think of an IDR and sharing information between ASs then one may want to
| (or need to) keep (sub-IP) layer specific for compatibility, i.e., connecting
| the pipes between domains and adapting the higher layer protocols back out. 
| It's useful to look at publicly available service maps for examples, I like
| Level3's maps (http://maps.level3.com/default/#.UCFpjJYu9rh) --compare
| wavelength services to other services -- and CenturyLink (http://
| www.centurylink-business.com/demos/network-maps.html) -- note how wavelength
| service availability is limited compared to other services (our big pipe
| networks are generally simpler than other service networks) --.
| 
| It seems what BGP-LS would deliver to an ALTO server to digest and serve up in
| abstracted form could be very different from what might be shared between
| ASes.  

HG> BGP-LS feeding an L3 routing topology into an ALTO server is one particular
application of the protocol. as you may have noticed the encoding of the link entries
in BGP-LS is a superset of all IGP extensions most notably including the MI
(multiple instance) drafts. as such one could carry higher or lower-layer
graphs (e.g. graphs of application clusters / graphs of DWDM wavelengths).
sicne you are concerened about optical gear feel free to send text on the
GMPLS link attributes that you would like to have supported.

| On 8/3/2012 4:57 PM, Alia Atlas wrote:
|      I strongly agree that we need to start collecting the use-cases for
|      multiple abstraction levels as well as physical/virtual/private.
|      Alia
|      On Aug 3, 2012 4:51 PM, "Y. Richard Yang" <[email-masked]> wrote:
|           Hi Volker,
| 
|           On 8/3/12 12:02 PM, Volker Hilt wrote:
| 
|                I believe that the capability to provide a
|                simplified view on the network topology to an
|                application is a key feature rather than a bug.
|                Applications that want to have a view on network
|                topology don't need need a fine grained view on
|                the topology in most casts and benefit from
|                having an abstracted view. This will simplify
|                processing for the application and enables
|                providers to control the exposure of details.
|           Agreed.
| 
|                We've seen some numbers for topology data sizes
|                in the incremental updates presentation in the
|                ALTO meeting, which provide some insights into
|                the amounts of data needed for different topology
|                sizes.
| 
|                I like the idea of enabling an ALTO server to
|                offer different levels of details. This will
|                enable a server to tailor responses to the
|                specific client. It will add complexity as the
|                ALTO server itself will have to maintain the most
|                complex topology it is offering and will have to
|                keep this topology up to date. But this is an
|                interesting question for discussion in the WG.
| 
|           Glad that you also like the idea of different levels of
|           details of the network topology. If the ALTO Server is
|           given a detailed topology (constructed from multiple
|           sources, such as routing feed, LSP feed, configuration
|           files), we can offer multiple topology operators/
|           aggregators to explore the detailed topology, according to
|           need and policy. A simple example operator is level (i.e.,
|           hierarchy such as at the area level), but one might specify
|           other operators (e.g., fisheye focus). There are studies on
|           representation of multi-level graphs that we can try to
|           take advantage of. This can be a subject for the group to
|           explore.
| 
|           We may need to study/collect use cases for multiple level
|           topology. One interesting example immediately coming to
|           mind is the Abstract Node concept (specify IP prefix/ASN)
|           used in RSVP-TE.
| 
|           Cheers,
| 
|           Richard
| 
|                Cheers,
| 
|                Volker
| 
| 
| 
| 
| 
| 
| 
|                On 03.08.2012 11:03, Y. Richard Yang wrote:
|                     Hi Stefano,
| 
|                     Good post! I added the ALTO mailing
|                     list, given the relevance. I hope
|                     that this is OK cross posting.
| 
|                     First, a few comments on ALTO:
| 
|                     View granularity:
| 
|                     - ALTO currently defines two abstract
|                     network topology data structures:
|                     Network Map and Cost Map(s). More link-
|                     state oriented maps (graphs),
|                     with aggregations and transformations,
|                     can be added efficiently to ALTO.
|                     Some initial efforts are already on the
|                     way (e.g., see the graph
|                     representation proposal at page 9:
|                     http://www.ietf.org/proceedings/84/
|                     slides/slides-84-alto-1.pdf). Hence,
|                     I see a natural next-step is for ALTO
|                     to provide a link-state view to
|                     external entities.
| 
|                     - It is a good comment on the level of
|                     details that ALTO should
|                     delivery. This is a good question for
|                     the ALTO working group and the
|                     community to discuss. I feel that ALTO
|                     should provide multi-levels of
|                     granularity of views, and we should
|                     discuss in the working group.
| 
|                     Pull vs push delivery mechanism:
| 
|                     - There are more discussions on adding
|                     the incremental update in ALTO.
|                     Multiple mechanisms have been
|                     discussed. I feel that it is the right
|                     direction for ALTO.
| 
|                     Now let me understand the deployment
|                     model of BGP-LS. Your explanation
|                     on the issues of acquiring routing
|                     state is excellent. Let me start by
|                     understanding more details on the
|                     deployment model of BGP-LS inside a
|                     network:
| 
|                     - A set N_igp of BGP-LS instances are
|                     deployed to collect IGP info. You
|                     need multiple instances because IGP
|                     needs direct connectivity
|                     (adjacency). Each instance here
|                     receives (potentially multiple) IGP
|                     updates and streams (relays) to an
|                     another (remote) entity, which I
|                     assume is a master BGP-LS instance. So
|                     each of these N_igp instances is
|                     IGP-in and BGP-LS out. This appears to
|                     be shown in Figure 1 of
|                     draft-gredler-idr-ls-distribution.
| 
|                     - A set N_egp of BGP-LS instances are
|                     deployed to collect BGP feeds. You
|                     also may need multiple instances
|                     because the network does not want to
|                     see aggregated states but raw states.
|                     These instances will feed to the
|                     master BGP-LS as well.
| 
|                     - The master BGP-LS aggregates the
|                     multiple BGP-LS ins (and maybe some
|                     direct IGP/EGP ins) and pushes (after
|                     policy) to other BGP-LS peers to
|                     use: for example, an ALTO Server
|                     transforms/aggregates the feed to
|                     generate ALTO views (maps and graphs),
|                     and an PCE uses the feed to
|                     maintain its TED. One could even
|                     imagine that ALTO builds a detailed TED
|                     and feeds to PCE, but this beyond the
|                     scope of this discussion. The
|                     master BGP-LS is BGP-LS in and BGP-LS
|                     out. It is also possible that the
|                     master BGP-LS does not push to any
|                     other entities and simply maintains
|                     an internal DB for others to query.
| 
|                     Do I understand it correctly?
| 
|                     Now, we can take a look at more
|                     specifics of BGP-LS.
| 
|                     A first perspective is the semantics of
|                     the content. If the objective is
|                     to solve the aforementioned deployment
|                     issue, then an alternative
|                     solution is to introduce a simple LS
|                     update tunneling protocol, where a
|                     link-state proxy forwards LS messages
|                     to a collector. The current design
|                     of BGP-LS starts with such a feeling
|                     (i.e., an NLRI starts with the
|                     Protocol ID, which indicates it is from
|                     IS-IS level 1 IS-IS level 2,
|                     OSPF, etc). However, the protocol
|                     appears to (try to) go beyond simple
|                     tunneling and introduces a common LS
|                     schema, by converting/filtering
|                     individual IGP LS messages to some
|                     common format. I feel that it can be
|                     helpful to first specify the schema (LS
|                     data model) instead of the
|                     specific encoding. For example, OSPF
|                     specifies LS Age, and this is
|                     filtered. (Please correct me if I
|                     missed it). On the other hand, one can
|                     think that some Age info can be helpful
|                     for one to understand the
|                     "freshness" of the LS. A problem
|                     studied in database is heterogeneous
|                     databases, to merge multiple data
|                     sources (IS-IS, OSPF, etc) to a single
|                     schema, and there can be many problems.
|                     If there is such a study, please
|                     do share a pointer.
| 
|                     A second perspective is using BGP as
|                     the transport. What key features
|                     from BGP do we really need (yes, weak-
|                     typed TLV encoding offers a lot of
|                     flexibility)? What features of BGP do
|                     we not need (e.g., BGP is a
|                     routing protocol and hence builds in
|                     features to handle convergence such
|                     as dampening)? What may be missing
|                     (e.g., a capability of pull or
|                     filtering of push). I feel that these
|                     issues should be discussed. If
|                     they have already been discussed,
|                     please do share a pointer, as I am
|                     definitely a new comer.
| 
|                     Thanks!
| 
|                     Richard
| 
|                     On 8/2/12 11:54 PM, stefano previdi
|                     wrote:
|                          All,
| 
|                          as co-author of both BGP-LS
|                          and ALTO drafts, I'd try to
|                          clarify a few
|                          things:
| 
|                          ALTO has been designed in
|                          order to deliver to
|                          applications (through
|                          http/json):
| 
|                          1. two maps representing the
|                          network topology in an
|                          abstracted view
|                          (or set of views through
|                          multiple maps). The map does
|                          not include
|                          the details of a link-state
|                          database and therefore have
|                          little use
|                          for any element that would
|                          need to retrieve from the
|                          network the
|                          detailed/complete network
|                          layer topology, for example:
|                          link
|                          addresses or link BW
|                          resources, etc. IOW: ALTO
|                          maps do not have
|                          the granularity of a link-
|                          state database and ALTO
|                          protocol is not
|                          designed to deliver such
|                          details.
| 
|                          and/or
| 
|                          2. Ranking services where a
|                          client sends a bunch of IP
|                          addresses in
|                          a message and the ALTO server
|                          replies by ranking these
|                          addresses
|                          based on their topological/
|                          network distance (or whatever
|                          criteria
|                          the ALTO server has been
|                          configured for). This is
|                          called: Endpoint
|                          Cost Service.
| 
|                          When using ALTO maps, and the
|                          ALTO protocol being http/pull
|                          based,
|                          there's no such concept of
|                          unsolicited routing updates.
|                          An ALTO
|                          client is typically a browser
|                          that will pull the maps from
|                          an ALTO
|                          server using http. The ALTO
|                          server will make no effort to
|                          ensure the
|                          client has the latest view of
|                          the topology (i.e.: It's the
|                          role of the
|                          client to poll for new maps
|                          time to time).
| 
|                          Now, in order for an ALTO
|                          server to deliver Maps or
|                          Ranking services,
|                          it needs to build some form
|                          of topology and in order to
|                          achieve this,
|                          it needs somehow to be fed by
|                          either the operator
|                          (configuration) or
|                          to receive dynamically
|                          topology information from the
|                          network (e.g.:
|                          ISIS/OSPF/BGP).
| 
|                          Here we had two options:
|                          1. ALTO server to implement
|                          ISIS/OSPF/BGP and establish
|                          IGP adjacencies
|                          to ABRs or L1L2 routers in
|                          each area so to retrieve the
|                          LSDB from
|                          each area. In practice I know
|                          no SP willing/accepting to
|                          open their
|                          IGP to an ALTO server. Also,
|                          IGP requires direct
|                          connectivity
|                          (adjacency) so from an
|                          operation point of view is
|                          complex and not
|                          desired.
|                          2. Use a database
|                          distribution protocol running
|                          on top of a reliable
|                          transport layer that would
|                          allow an ALTO server to
|                          connect to a
|                          _single_ and _remote_ Route
|                          Reflector (i.e.: no need to
|                          be directly
|                          connected) and grab the whole
|                          network topology that will be
|                          updated
|                          using standard routing
|                          protocol mechanisms (i.e.:
|                          routing updates)
|                          and that would allow the
|                          operator to control (through
|                          policies and
|                          filters) what to distribute
|                          and to which server.
| 
|                          Benefits: single (or dual at
|                          most for redundancy)
|                          connection for
|                          the ALTO server (rather than
|                          having a direct adjacency
|                          with each
|                          ABR) and, from the operator
|                          perspective, single point of
|                          distribution of network
|                          topology (easier to apply
|                          policies and
|                          control what you deliver).
|                          This is what BGP-LS is about.
| 
|                          BGP-LS defines new AFI/SAFI
|                          for a new NLRI and attributes
|                          that convey
|                          link-state and, more
|                          generically, any type of
|                          topology information.
|                          The draft specifies NLRI and
|                          attributes that map whatever
|                          you can
|                          find in a link-state
|                          database.
| 
|                          We currently have draft-
|                          gredler-idr-ls-distribution
|                          in the process
|                          (hopefully) to be adopted as
|                          WG item in IDR WG (so far we
|                          're getting
|                          good support). We also have 3
|                          implementations of BGP-LS.
| 
|                          Deployment-wise: BGP-LS is
|                          not yet deployed, however, we
|                          already have
|                          deployments (I know at least
|                          two) where an ALTO server
|                          retrieves IP
|                          prefix information from
|                          remote BGP RRs (for ipv4).
|                          The same scheme
|                          will be used once BGP-LS will
|                          be deployed (so to say that
|                          it is not
|                          something that we invented
|                          after a couple of beers but
|                          corresponds to
|                          requirements for delivering
|                          network services to upper
|                          layers while
|                          still controlling efficiently
|                          what you distribute, to whom
|                          and in
|                          which form (note that, often,
|                          beers are anyway part of the
|                          process).
| 
|                          More information here:
|                          http://tools.ietf.org/html/
|                          draft-gredler-idr-ls-
|                          distribution-02
|                          http://tools.ietf.org/html/
|                          draft-ietf-alto-protocol-12
| 
|                          Hope this helps.
| 
|                          s.
| 
| 
| 
|                          On Aug 3, 2012, at 1:29 AM,
|                          Robert Raszuk wrote:
|                               Tom,
| 
|                                    I agree
|                                    that one
|                                    of the top
|                                    work items
|                                    for this
|                                    effort
|                                    should be
|                                    a
|                                    standardized
|                                    topology
|                                    function,
|                                    and one
|                                    that is
|                                    accessible
|                                    via a
|                                    non-
|                                    routing
|                                    protocol.
|                               So if the
|                               requirement is to
|                               have topology
|                               export via non-
|                               routing
|                               protocol then I
|                               think we should
|                               seriously revisit
|                               or repackage the
|                               draft-gredler-idr-
|                               ls-distribution-01
|                               which works for for
|                               both OSPF
|                               and ISIS.
| 
|                               However before that
|                               let's really
|                               understand the
|                               requirement why it
|                               must be exported
|                               via non-routing
|                               protocol .... Keep
|                               in mind that just
|                               to parse BGP UPDATE
|                               messages and
|                               retrieve
|                               interesting pieces
|                               out it
|                               it requires very
|                               little code rather
|                               then full BGP
|                               implementation.
| 
|                               The particular
|                               feature I like
|                               about
|                               draft-gredler-idr-
|                               ls-distribution-01
|                               is that it is read-
|                               only ;)
| 
|                               R.
| 
|                                    I agree
|                                    that one
|                                    of the top
|                                    work items
|                                    for this
|                                    effort
|                                    should be
|                                    a
|                                    standardized
|                                    topology
|                                    function,
|                                    and one
|                                    that is
|                                    accessible
|                                    via a
|                                    non-
|                                    routing
|                                    protocol.
|                                    While not
|                                    exactly
|                                    "low
|                                    hanging
|                                    fruit", it
|                                    is
|                                    something
|                                    that (to
|                                    me) is a
|                                    clear work
|                                    item with
|                                    clear
|                                    goals that
|                                    should
|                                    be tackled
|                                    straight
|                                    away.
| 
|                                    --Tom
| 
| 
| 
|                                    On 8/2/12
|                                    3:24 PM,
|                                    "James
|                                    Kempf"
|                                    <[email-masked]>
|                                    wrote:
| 
|                                         So
|                                         after
|                                         seeing
|                                         part
|                                         of
|                                         Alia's
|                                         talk
|                                         this
|                                         morning
|                                         (I
|                                         had
|                                         to
|                                         leave
|                                         in
|                                         the
|                                         middle
|                                         unfortunately),
|                                         I'd
|                                         like
|                                         to
|                                         make
|                                         a
|                                         couple
|                                         suggestions.
|                                         There
|                                         were
|                                         a lot
|                                         of
|                                         ideas
|                                         presented
|                                         in
|                                         the
|                                         talk,
|                                         enough
|                                         for
|                                         an
|                                         entire
|                                         IETF
|                                         Area.
|                                         I
|                                         think
|                                         to
|                                         make
|                                         tangible
|                                         progress,
|                                         the
|                                         work
|                                         needs
|                                         to be
|                                         focussed
|                                         on a
|                                         small
|                                         subset
|                                         that
|                                         would
|                                         be of
|                                         immediate
|                                         interest
|                                         and
|                                         usability.
| 
|                                         There
|                                         are a
|                                         couple
|                                         areas
|                                         that
|                                         suggest
|                                         themselves,
|                                         but
|                                         one
|                                         that
|                                         would
|                                         be
|                                         useful
|                                         in
|                                         work
|                                         that
|                                         I've
|                                         been
|                                         involved
|                                         in is
|                                         a
|                                         standardized
|                                         format
|                                         for
|                                         network
|                                         topology
|                                         representation
|                                         and a
|                                         protocol
|                                         for
|                                         exchanging
|                                         it.
|                                         The
|                                         Onix
|                                         OpenFlow
|                                         controller
|                                         has a
|                                         network
|                                         information
|                                         base
|                                         with
|                                         a
|                                         specialized
|                                         format
|                                         for
|                                         network
|                                         topology,
|                                         and
|                                         every
|                                         OpenFlow
|                                         controller
|                                         requires
|                                         this.
|                                         Having
|                                         a
|                                         standardized
|                                         way
|                                         to
|                                         represent
|                                         it
|                                         might
|                                         foster
|                                         a
|                                         common
|                                         topology
|                                         database
|                                         package.
|                                         Another
|                                         application
|                                         is
|                                         network
|                                         management.
|                                         Every
|                                         network
|                                         management
|                                         system
|                                         needs
|                                         some
|                                         kind
|                                         of
|                                         topology
|                                         representation.
|                                         Finally,
|                                         though
|                                         I am
|                                         not
|                                         an
|                                         expert
|                                         in
|                                         PCE
|                                         construction,
|                                         it
|                                         would
|                                         seem
|                                         to me
|                                         that
|                                         a PCE
|                                         would
|                                         need
|                                         some
|                                         kind
|                                         of
|                                         topology
|                                         representation
|                                         in
|                                         order
|                                         to
|                                         perform
|                                         path
|                                         calculations.
|                                         Having
|                                         a
|                                         way,for
|                                         example,
|                                         for
|                                         the
|                                         OpenFlow
|                                         controller
|                                         and
|                                         the
|                                         PCE
|                                         to
|                                         exchange
|                                         topology
|                                         information
|                                         would
|                                         be
|                                         really
|                                         useful.
|                                         I
|                                         would
|                                         say
|                                         to
|                                         start
|                                         with
|                                         physical
|                                         topology
|                                         because
|                                         that
|                                         is
|                                         fundamental,
|                                         but
|                                         make
|                                         the
|                                         format
|                                         flexible
|                                         enough
|                                         to
|                                         support
|                                         virtual
|                                         topology
|                                         representation.
| 
|                                         jak
|                                         _______________________________________________
|                                         irs-
|                                         discuss
|                                         mailing
|                                         list
|                                         irs-
|                                         [email-masked]
|                                         https:
|                                         //
|                                         www.ietf.org/
|                                         mailman/
|                                         listinfo/
|                                         irs-
|                                         discuss
|                                    _______________________________________________
|                                    irs-
|                                    discuss
|                                    mailing
|                                    list
|                                    irs-
|                                    [email-masked]
|                                    https://
|                                    www.ietf.org/
|                                    mailman/
|                                    listinfo/
|                                    irs-
|                                    discuss
| 
| 
|                               _______________________________________________
|                               irs-discuss mailing
|                               list
|                               irs-
|                               [email-masked]
|                               https://
|                               www.ietf.org/
|                               mailman/listinfo/
|                               irs-discuss
| 
|                          _______________________________________________
|                          irs-discuss mailing list
|                          [email-masked]
|                          https://www.ietf.org/mailman/
|                          listinfo/irs-discuss
| 
|                     _______________________________________________
|                     irs-discuss mailing list
|                     [email-masked]
|                     https://www.ietf.org/mailman/listinfo/
|                     irs-discuss
|           _______________________________________________
|           irs-discuss mailing list
|           [email-masked]
|           https://www.ietf.org/mailman/listinfo/irs-discuss
| 
| 
|      _______________________________________________
|      alto mailing list
|      [email-masked]
|      https://www.ietf.org/mailman/listinfo/alto
| 
| 
| --
| ===================================================
| Dr Greg Bernstein, Grotto Networking (510) 573-2237

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

---

From: Greg Bernstein <[email-masked]>
Date: Mon, 06 Aug 2012 10:49:38 -0700

Hi Richard, Stefano, et. al. thanks for the explanations and pointers to 
the BGP-LS draft. This helps avoid any confusion that BGP-LS is in 
competition with ALTO.

BGP-LS (http://tools.ietf.org/html/draft-gredler-idr-ls-distribution-02) 
could be used to feed topology/path information to ALTO servers or path 
computation elements (PCE).  As part of that process it would collect 
link state information from IGPs and possibly abstract it.

One partial point of confusion for me as a non-BGP speaker ;-)   was in 
the BGP-LS abstract which stated "In a number of environments, */a 
component external to a network/* is called upon to perform computations 
based on the network topology and current state of the connections 
within the network, including traffic engineering information."  or  
"This document describes a mechanism by which links state and traffic 
engineering information can be collected from networks and *shared with 
external components* using the BGP routing protocol."
I always considered PCE clients and servers as being within the network 
(working with privileged or sensitive network information) and an ALTO 
server as abstracting that information for use by network clients.  I 
guess by "external" to the network meaning was external to the "data plane".

I also noticed some parallels with our ALTO large bandwidth 
use-case/modeling work (section 6 of 
http://tools.ietf.org/html/draft-bernstein-alto-large-bandwidth-cases-02) and 
BGP-LS. In particular we both seem to want graph and path abstractions.  
For path abstractions (aggregation) we needed (due to bandwidth 
constraints) model a path as one or more abstract links with appropriate 
properties.  It seems a similar situation would hold when trying to 
aggregate paths with SRLG properties. These similarities make sense 
since both drafts are concerned with sharing information about the 
network in an aggregated/abstract form.

Best Regards
Greg B.

On 8/3/2012 11:46 AM, Y. Richard Yang wrote:
>> Could you cross-post this note to the [email-masked] list. The BGP-LS 
>> draft is being considered for WG adoption. I think this perspective 
>> would help the idr WG.
>>
>> Thank you,
>>
>> Sue
>>
>> From: [email-masked] 
>> [mailto:[email-masked]] On Behalf Of Y. Richard Yang
>>>> must be exported via non-routing protocol .... Keep in mind that 
>>>> just to parse BGP UPDATE messages and retrieve interesting pieces 
>>>> out it it requires very little code rather then full BGP 
>>>> implementation.
>>>>

---

From: Greg Bernstein <[email-masked]>
Date: Mon, 06 Aug 2012 11:09:52 -0700

Hi Alia, one key use case that needs a different level of abstraction is 
the "large bandwidth" use-case. In the P4P paper Richard Yang and 
co-authors were able to affect traffic engineering by changing the path 
costs over time.  However in the "large bandwidth" case we need explicit 
information on bandwidth constraints 
(http://tools.ietf.org/html/draft-bernstein-alto-large-bandwidth-cases-02).

Another dimension to the "abstraction" levels was that of the scope/span 
of users of the information.  Currently ALTO is aimed at open, 
"Internet" -like environments.  However some of the extensions being 
proposed may apply in more "controlled" or "restricted" environments.

Although we are trying to hide network details from the ALTO users there 
may be cases with particular technology information is important. For 
example in our "large bandwidth" use-case document we showed how to 
shared multiple spanning tree instance (MSTI) Ethernet graphs in reduced 
form for VLAN to MSTI assignment in a data center.  We also gave  
optical (WDM and TDM) examples.

Cheers

Greg B.