Subject: Re: [irs-discuss] A few comments on the draft-ietf-netmod-routing-cfg-04 draft.
From: Ladislav Lhotka <[email-masked]>
To: [email-masked]
Cc: [email-masked], [email-masked]
Date: Tue, 30 Oct 2012 18:34:10 +0100
List-Id: "Interface to The Internet Routing System \(IRS\)" <irs-discuss.ietf.org>

Hi Bruno,

first of all, I have to apologise that I didn't answer your comments in a timely manner, the message somehow fell through the cracks. :-( I hope it's still not too late though the draft is now at revision -05.

So, thanks for your comments, please see my responses inline.

> 
> -------- Original Message --------
> Subject:	[irs-discuss] A few comments on the draft-ietf-netmod-routing-cfg-04 draft.
> Date:	Mon, 3 Sep 2012 07:15:08 -0400
> From:	Bruno Rijsman <[email-masked]>
> To:	[email-masked] <[email-masked]>
> CC:	[email-masked] <[email-masked]>
> 
> I have a few comments on the draft-ietf-netmod-routing-cfg-04 draft.
> 
> 1) Generalize the concept of a next-hop
> 
> It appears that in the current model, routes can point to an outgoing interface and a next-hop address. The concept of next-hops needs to be generalized. Next-hops can have multiple tuples of outgoing interfaces and next-hop addresses. The most common reasons is Equal Cost Multi Path (ECMP) where a single route has multiple next-hops. This is not the same as multi-pathing in the sense of multiple active routes to the same prefix each contributing one next-hop. A variation of this is NECMP where the next-hops are different weights. Another reason for multiple next-hops is fast re-route where the next-hops represent alternatives (the first one whose interface is up is used). Another needed generalization of next-hops is the ability to push and pop MPLS labels, VLAN tags, etc. Another is the ability to add a level of indirection (e.g. BGP indirect next-hop for fast BGP reconvergence). The OpenFlow 1.x documents are a good source to look for generalized next-hop examples.

I assume that multiple next-hops to the same destination will appear as two separate routes. And indeed, the two routes may have different weights.

MPLS is outside the scope for the core routing data model, although the framework should be ready to incorporate MPLS etc. via augments from other modules.

> 
> 
> 2) Generalize the concept of a prefix
> 
> Section 4.2 says that the core routing data model only defines the following minimal set of route attributes: destination-prefix, next-hop, outgoing-interface. However, in section 4 there are no destination-prefix or next-hop. There are only v4ur:dest-prefix, v4ur:next-hop, v6ur:dest-prefix, v6ur:next-hop. It appears that the

Why is it a problem? These parameters are address family specific, so they are defined in the ietf-ipv[46]-unicast-routing modules. Each routing table only contains routes of a single address family, so the ipv4:* and ipv6:* nodes can never appear as sibling elements in a configuration or state data.

> destination-prefix and next-hop were removed from the base object and moved to the derived object. In my opinion, it would make sense to move the destination-prefix (as a simple bit-string and length) and the next-hop back to the base object. The derived object could have a string object to contain the destination-prefix as a human-readable string (e.g. "10.0.0.0/8" for an IPv4 prefix). Furthermore, section 4.2 assumes that the routes are always IP routes (it uses repeatedly uses terms like "IP prefix"). The routes can be non-IP routes. For example, MPLS routes which are /20 exact matches on a label, or CLNS routes, or other protocols
> . Some VPLS implemen
> tations even use the "routing table" abstraction to represent Ethernet routes (as exact /48 routes on MAC addresses).

Sure, modules for other address families can define their own parameters of routes. They are supposed to be filled in via YANG augments. The core routing data model only deals with IP.

> 
> 3) Static (and direct) routes for multiple routing tables.
> 
> Figure 2 appears to imply that static and direct routes can only be inserted in the main routing table. Is it possible to install static routes in multiple additional routing tables?

This is now better explained in revision -05. Direct routes are always installed in the main routing table but the static pseudo-protocol can be connected to any table. Routes from any table can be installed in other routing tables by means of the mechanism of recipient routing tables and filters (sec. 4.3).

Figure 2 is just an example.

> 
> 
> 4) More attributes for static routes.
> 
> Configured static routes (routes in the pseudo routing-protocol "static") need more attributes  (e.g. metric).

This can be done, although the use case for metrics of static routes is not very clear to me, unless there is a way for redistributing such routes to other routing protocols. Such parameters can be added via augments from other (generic or vendor-specific) modules, if necessary. In the core routing model, we tried to limit the number of parameters to a reasonable minimum, or otherwise we will never finish this work.

> 
> 5) Add support for routing-instances.
> 
> Allow the creation of multiple routing-instances (also known as VRFs) per logical-router. Allow interfaces to be assigned to routing-instances. Allow multiple instances of routing protocols, scoped by routing-instance.

In rev. -05, each router instance has the "type" parameter so that the same flat list of router instances may contain VRFs as well as self-contained logical/virtual routers that differ in the type parameter. New modules defining a particular router type then have to specify the rules. e.g., whether/how routing tables can be shared among router instances.

> 
> 6) Ability for a client to subscribe to RIB changes
> 
> It would be very useful for a client to be able to subscribe to route table changes. (I am not a YANG expert and I don't know if such a thing is even possible in YANG.) In the subscription, the client could specify one or more routing tables in which it is interested and filter(s) to specify which subset of routes it is interested in.

This can be done using a NETCONF notification, but again - I am afraid of feature creep, so I would leave this extension to a separate module.

> 
> 7) More sophisticated filters
> 
> Section 4.5 explicitly says that the core routing data model only defines a skeleton for filtering. It would be "good" for the working group to continue this work and define more sophisticated filtering mechanisms.

When we were discussing the current NETMOD charter, I proposed to work on route filters but I didn't get support for this idea. Anyway, this should probably be addressed by routing experts - I will be happy to help.

There is now a draft/module on ACLs (http://tools.ietf.org/html/draft-huang-netmod-acl-01) that goes in this direction.

Thanks, Lada

> 
> -- Bruno
> 
> PS: Cross-post to the Interface to the Routing System (IRS) mailing list because they are discussing very similar functionality.
> _______________________________________________
> irs-discuss mailing list
> 
> [email-masked]
> https://www.ietf.org/mailman/listinfo/irs-discuss
> 
> 
> 
> 
> 
> 
> 
> 
> 

--
Ladislav Lhotka, CZ.NIC Labs
PGP Key ID: E74E8C0C

Date: Mon, 29 Oct 2012 14:14:57 +0900
From: Seiichi Kawamura <[email-masked]>
To: [email-masked]
Subject: [irs-discuss] coments on draft-keyupate-irs-bgp-usecases-01

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig9A8E98BAC5C02CC29F9E90DC
Content-Type: text/plain; charset=ISO-2022-JP
Content-Transfer-Encoding: quoted-printable

Hi Authors

This is a great draft. Exactly what I want in my ISP network.
I have a few comments and thoughts.

Section2.2

o "Filter prefixes that are not allocated by Internet Routing Registries."

  IRRs do not allocate prefixes. Do you mean filter prefixes not
  registered on IRRs, or filter prefixes not allocated by IANA/RIR?
  I would go for the latter.

o "This helps avoid prefix hijacking."

  I would say "This helps avoid prefix hijacking, including unintentional
  misconfiguration announcements."

o JPIRR, run by JPNIC in coordination with the Japanes operator community
  has quite an accurate record because it requires authorization and
  yearly updates to the data. However, the complexity of the operation
  has not caught on with other IRRs.

Miscellaneous

o I didn't see a section in the document that described the situations
  for a newly configured BGP session. When you configure a new
  session, you may want to set BGP passive, especially if the neighbor
  requests MD5 because that would generate messy logs. When the peer
  does come up though, that passive needs to be deleted. All this
  could be done through IRS. After the BGP session comes up, and if
  the neighbor is advertising unexpected address families and timers
  IRS could send that information to the controller, and the controller
  could decide whether to shut it down or not. This will mitigate
  unwanted BGP session flapping.

o Many ISPs use peeringdb.com to exchange peering info these days.
  Would an API to directly query peeringdb be helpful?
  I guess this is a question that would be nice to discuss among
  the operators and the people who maintain peeringdb.

Regards,
Seiichi

--------------enig9A8E98BAC5C02CC29F9E90DC
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

--------------enig9A8E98BAC5C02CC29F9E90DC--

Date: Fri, 26 Oct 2012 07:55:02 -0700
From: Andy Bierman <[email-masked]>
To: Russ White <[email-masked]>
Cc: [email-masked]
Subject: Re: [irs-discuss] Rough Draft IRS Charter

--20cf307d00742c44bd04ccf78184
Content-Type: text/plain; charset=UTF-8

Hi,

This charter text is very puzzling:

     ..those mechanisms impose many transactional mechanisms
    and requirements, that may slow down the interaction

What are these "slow path" mechanisms that IRS will not need?

Andy

On Mon, Oct 22, 2012 at 10:50 AM, Russ White <[email-masked]> wrote:

>
> I think this has already been brought up on the list once before, but
> I'd just like to repeat my concerns on it:
>
> =
> Thus, the IRS is a "fast path" that can be used to program routing and
> policy state in a router using operational paradigms familiar to
> operators of traditional distributed devices. This differs from the
> programmatic "slow state" that is commonly a device's configuration
> interface because those mechanisms impose many transactional mechanisms
> and requirements, that may slow down the interaction.
> =
>
> Describing the CLI or other existing interfaces as the "slow path," and
> the proposed as the "fast path," is problematic. First, it implies that
> there is a specific path already available into all control plane
> devices, and that single path is "too slow," for some meaning of "too
> slow." Second, it implies, from the start, that we need new path, rather
> than a possible structure around existing paths that we can use to make
> sense of the routing system as a whole.
>
> I think 2a needs to be better defined so it doesn't overlap with 2c, or
> 2c needs to be made a part of 2a in some way (?).
>
> Thanks!
>
> Russ
>
>
>
> --
> <><
> [email-masked]
> [email-masked]
> _______________________________________________
> irs-discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/irs-discuss
>

--20cf307d00742c44bd04ccf78184
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div><span style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:13px;background-color:rgb(255,255,255)">Hi,</span></div><div><span style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:13px;background-color:rgb(255,255,255)"><br>
</span></div><div><span style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:13px;background-color:rgb(255,255,255)">This charter text is very puzzling:</span></div><div><span style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:13px;background-color:rgb(255,255,255)"><br>
</span></div><span style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:13px;background-color:rgb(255,255,255)">     ..those mechanisms impose many transactional mechanisms</span><br style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:13px;background-color:rgb(255,255,255)">
<span style="color:rgb(34,34,34);font-family:arial,sans-serif;font-size:13px;background-color:rgb(255,255,255)">    and requirements, that may slow down the interaction</span><div><font color="#222222" face="arial, sans-serif"><br>
</font></div><div><font color="#222222" face="arial, sans-serif">What are these &quot;slow path&quot; mechanisms that IRS will not need?</font></div><div><br></div><div><font color="#222222" face="arial, sans-serif"><br></font></div>
<div><font color="#222222" face="arial, sans-serif">Andy</font></div><div><font color="#222222" face="arial, sans-serif"><br></font><br><div class="gmail_quote">On Mon, Oct 22, 2012 at 10:50 AM, Russ White <span dir="ltr">&lt;<a href="mailto:[email-masked]" target="_blank">[email-masked]</a>&gt;</span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
I think this has already been brought up on the list once before, but<br>
I&#39;d just like to repeat my concerns on it:<br>
<br>
==<br>
Thus, the IRS is a &quot;fast path&quot; that can be used to program routing and<br>
policy state in a router using operational paradigms familiar to<br>
operators of traditional distributed devices. This differs from the<br>
programmatic &quot;slow state&quot; that is commonly a device&#39;s configuration<br>
interface because those mechanisms impose many transactional mechanisms<br>
and requirements, that may slow down the interaction.<br>
==<br>
<br>
Describing the CLI or other existing interfaces as the &quot;slow path,&quot; and<br>
the proposed as the &quot;fast path,&quot; is problematic. First, it implies that<br>
there is a specific path already available into all control plane<br>
devices, and that single path is &quot;too slow,&quot; for some meaning of &quot;too<br>
slow.&quot; Second, it implies, from the start, that we need new path, rather<br>
than a possible structure around existing paths that we can use to make<br>
sense of the routing system as a whole.<br>
<br>
I think 2a needs to be better defined so it doesn&#39;t overlap with 2c, or<br>
2c needs to be made a part of 2a in some way (?).<br>
<br>
Thanks!<br>
<span class="HOEnZb"><font color="#888888"><br>
Russ<br>
<br>
<br>
<br>
--<br>
&lt;&gt;&lt;<br>
<a href="mailto:[email-masked]">[email-masked]</a><br>
<a href="mailto:[email-masked]">[email-masked]</a><br>
_______________________________________________<br>
irs-discuss mailing list<br>
<a href="mailto:[email-masked]">[email-masked]</a><br>
<a href="https://www.ietf.org/mailman/listinfo/irs-discuss" target="_blank">https://www.ietf.org/mailman/listinfo/irs-discuss</a><br>
</font></span></blockquote></div><br></div>

--20cf307d00742c44bd04ccf78184--

From: "Keyur Patel (keyupate)" <[email-masked]>
To: Robert Raszuk <[email-masked]>, idr wg <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Mon, 22 Oct 2012 23:01:59 +0000
Accept-Language: en-US
Cc: Pedro Marques <[email-masked]>, "David Ward \(wardd\)" <[email-masked]>, "[email-masked]" <[email-masked]>, Kireeti Kompella <[email-masked]>
Subject: Re: [irs-discuss] Fwd: I-D Action: draft-keyupate-bgp-services-01.txt

Hi Robert,

Thanks for the comments. :) Comments inlined #Keyur.

On 10/22/12 3:02 PM, "Robert Raszuk" <[email-masked]> wrote:

>Dear authors,
>
>After reading this document I would like to observe that BGP seems to
>not fit to the proposed application. Not that it is BGP fault, but the
>service model required for service dissemination and discovery is much
>better to be based on publish, subscribe, search primitives rather
>then p2mp data base distribution propagation which is the BGP model.

#Keyur: BGP has its own Pub sub model through use of RT. You could use it
if you like. :)

>
>Putting gateways between service providers and service consumers is a
>nice try to address the end point BGP protocol language barrier, but
>it does not address the discovery model.

#Keyur: The draft provides a way to have a service discovery.

>
>While one could argue that services could have attached RTs and
>RT-Constrain could be used to push filter to only receive what is
>necessary however current industry have already solved this problem in
>a much more elegant way by using MAP servers and IF-MAP protocol
>between producers and consumers. The database behind the MAP server
>can be build in a very robust way (as compared to today's BGP state of
>the art).

#Keyur: I haven't seen a solution yet and so cant speak for it. ;)
However, the draft provides BGP as a transport for service discovery and
service advertisement.

>
>I would recommend for the authors to consider such alternatives and
>possibly rewrite the proposal to make it fit the needs of this very
>important class of application which is service discovery.

#Keyur: Sure.

Regards,
Keyur

>
>Best regards,
>R.
>
>---------- Forwarded message ----------
>From:  <[email-masked]>
>Date: Mon, Oct 22, 2012 at 11:13 PM
>Subject: I-D Action: draft-keyupate-bgp-services-01.txt
>To: [email-masked]
>
>
>
>A New Internet-Draft is available from the on-line Internet-Drafts
>directories.
>
>
>        Title           : Service Advertisement using BGP
>        Author(s)       : Keyur Patel
>                          Jan Medved
>                          Rex Fernando
>                          Burjiz Pithawala
>        Filename        : draft-keyupate-bgp-services-01.txt
>        Pages           : 12
>        Date            : 2012-10-22
>
>Abstract:
>   A variety of services, such as NATs, firewalls, or caches, can be
>   embedded in a service provider network or instantiated in data
>   centers attached to the network.  This document proposes extensions
>   to BGP that facilitate discovery of such service instances by
>   interested clients and allows dissemination of service information,
>   such as services capabilities or capacities, throughout the network
>   domain.  The proposed extensions allow for optimal routing of
>   requests to service instances that can optimally serve them.
>
>
>The IETF datatracker status page for this draft is:
>https://datatracker.ietf.org/doc/draft-keyupate-bgp-services
>
>There's also a htmlized version available at:
>http://tools.ietf.org/html/draft-keyupate-bgp-services-01
>
>A diff from the previous version is available at:
>http://www.ietf.org/rfcdiff?url2=draft-keyupate-bgp-services-01
>
>
>Internet-Drafts are also available by anonymous FTP at:
>ftp://ftp.ietf.org/internet-drafts/
>
>_______________________________________________
>I-D-Announce mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/i-d-announce
>Internet-Draft directories: http://www.ietf.org/shadow.html
>or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>_______________________________________________
>irs-discuss mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/irs-discuss

Sender: [email-masked]
Date: Tue, 23 Oct 2012 00:02:51 +0200
From: Robert Raszuk <[email-masked]>
To: idr wg <[email-masked]>, [email-masked]
Cc: Pedro Marques <[email-masked]>, [email-masked], Kireeti Kompella <[email-masked]>
Subject: [irs-discuss] Fwd: I-D Action: draft-keyupate-bgp-services-01.txt

Dear authors,

After reading this document I would like to observe that BGP seems to
not fit to the proposed application. Not that it is BGP fault, but the
service model required for service dissemination and discovery is much
better to be based on publish, subscribe, search primitives rather
then p2mp data base distribution propagation which is the BGP model.

Putting gateways between service providers and service consumers is a
nice try to address the end point BGP protocol language barrier, but
it does not address the discovery model.

While one could argue that services could have attached RTs and
RT-Constrain could be used to push filter to only receive what is
necessary however current industry have already solved this problem in
a much more elegant way by using MAP servers and IF-MAP protocol
between producers and consumers. The database behind the MAP server
can be build in a very robust way (as compared to today's BGP state of
the art).

I would recommend for the authors to consider such alternatives and
possibly rewrite the proposal to make it fit the needs of this very
important class of application which is service discovery.

Best regards,
R.

---------- Forwarded message ----------
From:  <[email-masked]>
Date: Mon, Oct 22, 2012 at 11:13 PM
Subject: I-D Action: draft-keyupate-bgp-services-01.txt
To: [email-masked]

A New Internet-Draft is available from the on-line Internet-Drafts directories.

        Title           : Service Advertisement using BGP
        Author(s)       : Keyur Patel
                          Jan Medved
                          Rex Fernando
                          Burjiz Pithawala
        Filename        : draft-keyupate-bgp-services-01.txt
        Pages           : 12
        Date            : 2012-10-22

Abstract:
   A variety of services, such as NATs, firewalls, or caches, can be
   embedded in a service provider network or instantiated in data
   centers attached to the network.  This document proposes extensions
   to BGP that facilitate discovery of such service instances by
   interested clients and allows dissemination of service information,
   such as services capabilities or capacities, throughout the network
   domain.  The proposed extensions allow for optimal routing of
   requests to service instances that can optimally serve them.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-keyupate-bgp-services

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-keyupate-bgp-services-01

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-keyupate-bgp-services-01

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

_______________________________________________
I-D-Announce mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Sender: [email-masked]
Date: Mon, 22 Oct 2012 19:57:13 +0200
From: Robert Raszuk <[email-masked]>
To: Russ White <[email-masked]>
Cc: [email-masked]
Subject: Re: [irs-discuss] Rough Draft IRS Charter

It may be also worth to document the conflict resolution mechanism
when "fast path" contradicts with "slow path" configurations ...

r.

On Mon, Oct 22, 2012 at 7:50 PM, Russ White <[email-masked]> wrote:
>
> I think this has already been brought up on the list once before, but
> I'd just like to repeat my concerns on it:
>
> =
> Thus, the IRS is a "fast path" that can be used to program routing and
> policy state in a router using operational paradigms familiar to
> operators of traditional distributed devices. This differs from the
> programmatic "slow state" that is commonly a device's configuration
> interface because those mechanisms impose many transactional mechanisms
> and requirements, that may slow down the interaction.
> =
>
> Describing the CLI or other existing interfaces as the "slow path," and
> the proposed as the "fast path," is problematic. First, it implies that
> there is a specific path already available into all control plane
> devices, and that single path is "too slow," for some meaning of "too
> slow." Second, it implies, from the start, that we need new path, rather
> than a possible structure around existing paths that we can use to make
> sense of the routing system as a whole.
>
> I think 2a needs to be better defined so it doesn't overlap with 2c, or
> 2c needs to be made a part of 2a in some way (?).
>
> Thanks!
>
> Russ
>
>
>
> --
> <><
> [email-masked]
> [email-masked]
> _______________________________________________
> irs-discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/irs-discuss

Date: Mon, 22 Oct 2012 13:50:07 -0400
From: Russ White <[email-masked]>
To: [email-masked]
Subject: Re: [irs-discuss] Rough Draft IRS Charter

I think this has already been brought up on the list once before, but
I'd just like to repeat my concerns on it:

=
Thus, the IRS is a "fast path" that can be used to program routing and
policy state in a router using operational paradigms familiar to
operators of traditional distributed devices. This differs from the
programmatic "slow state" that is commonly a device's configuration
interface because those mechanisms impose many transactional mechanisms
and requirements, that may slow down the interaction.
=

Describing the CLI or other existing interfaces as the "slow path," and
the proposed as the "fast path," is problematic. First, it implies that
there is a specific path already available into all control plane
devices, and that single path is "too slow," for some meaning of "too
slow." Second, it implies, from the start, that we need new path, rather
than a possible structure around existing paths that we can use to make
sense of the routing system as a whole.

I think 2a needs to be better defined so it doesn't overlap with 2c, or
2c needs to be made a part of 2a in some way (?).

Thanks!

Russ

-- 
<><
[email-masked]
[email-masked]

From: <[email-masked]>
To: "[email-masked]" <[email-masked]>
Date: Fri, 19 Oct 2012 16:13:29 +0200
Accept-Language: fr-FR
acceptlanguage: fr-FR
Cc: JACQUENET Christian OLNC/OLN <[email-masked]>
Subject: [irs-discuss] IP Connectivity Provisioning Profile (draft-boucadair-connectivity-provisioning-profile)

Dear all,
 
I'm sending this message to this list as I received several comments asking how to position this I-D vs. IRS. 

I thought it would be useful to have comments and feedback from this list.

Abstract:
   This document describes the Connectivity Provisioning Profile (CPP)
   and proposes a CPP Template to capture IP connectivity requirements
   to be met in the context of delivery of services (e.g.  Voice over IP
   or IP TV) which are to be plugged upon an IP/MPLS infrastructure.
   The CPP defines the set of IP transfer parameters to be supported by
   the underlying IP/MPLS transport network together with a reachability
   scope and bandwidth/capacity needs.  Appropriate performance metrics
   such as one-way delay, one-way delay variation are used to
   characterize an IP transfer service.  Both global and restricted
   reachability scopes can be captured in the CPP.

   Having the generic CPP template allows for (1) automating the process
   of service negotiation and activation, thus accelerating service
   provisioning, (2) setting the (traffic) objectives of Traffic
   Engineering functions and service management functions and (3)
   enriching service and network management systems with 'decision-
   making' capabilities based on negotiated/offered CPPs.

https://datatracker.ietf.org/doc/draft-boucadair-connectivity-provisioning-profile
http://tools.ietf.org/html/draft-boucadair-connectivity-provisioning-profile-02

Comments are welcome.

Cheers,
Med

From: Maglione Roberta <[email-masked]>
To: 'Ross Callon' <[email-masked]>, "[email-masked]" <[email-masked]>
Date: Fri, 19 Oct 2012 14:43:25 +0200
Accept-Language: en-US, it-IT
acceptlanguage: en-US, it-IT
Cc: "[email-masked]" <[email-masked]>, Capello Alessandro <[email-masked]>
Subject: Re: [irs-discuss] Rough Draft IRS Charter

--_0c4e719e-f351-4e2c-ad63-be050bc9d0a1_
Content-Type: multipart/alternative;
	boundary="_000_282BBE8A501E1F4DA9C775F964BB21FE519702F264GRFMBX704BA02_"

--_000_282BBE8A501E1F4DA9C775F964BB21FE519702F264GRFMBX704BA02_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hello,
 I have a question on working item 2:

"The working group is chartered to work on the following items:

2.       Tightly scoped key use cases for operational use of IRS. These use cases will include at least:

a.      Interactions with the RIB

b.      Association of routing policies with routing state

c.      The ability to extract information about topology from the network
"
Does this bullet exclude the possibility to use IRS to gather information about network measurements such as available bandwidth on a link, information related to jitter delay for specific flows etc. ?

Thanks,
Roberta
________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of Ross Callon
Sent: Thursday, October 18, 2012 5:55 PM
To: [email-masked]
Cc: Ross Callon; [email-masked]
Subject: [irs-discuss] Rough Draft IRS Charter

Attached (in Word format) is a very rough initial draft charter (for a potential IRS WG) that the BOF chairs have been discussing with our friendly sponsoring routing area AD.

Comments are welcome. We will be discussing the draft IRS WG charter in Atlanta.

Thanks, Ross
(with input from Dave and Adrian)

Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle persone indicate. La diffusione, copia o qualsiasi altra azione derivante dalla conoscenza di queste informazioni sono rigorosamente vietate. Qualora abbiate ricevuto questo documento per errore siete cortesemente pregati di darne immediata comunicazione al mittente e di provvedere alla sua distruzione, Grazie.

This e-mail and any attachments is confidential and may contain privileged information intended for the addressee(s) only. Dissemination, copying, printing or use by anybody else is unauthorised. If you are not the intended recipient, please delete this message and any attachments and advise the sender by return e-mail, Thanks.

Rispetta l'ambiente. Non stampare questa mail se non ? necessario.

--_000_282BBE8A501E1F4DA9C775F964BB21FE519702F264GRFMBX704BA02_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:st1="urn:schemas-microsoft-com:office:smarttags" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
<meta name="Generator" content="Microsoft Word 11 (filtered medium)">
<!--[if !mso]>
<style>
v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
</style>
<![endif]--><o:SmartTagType namespaceuri="urn:schemas-microsoft-com:office:smarttags" name="City" /><o:SmartTagType namespaceuri="urn:schemas-microsoft-com:office:smarttags" name="place" /><!--[if !mso]>
<style>
st1\:*{behavior:url(#default#ieooui) }
</style>
<![endif]--><style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:"MS Mincho";
	panose-1:2 2 6 9 4 2 5 8 3 4;}
@font-face
	{font-family:Verdana;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
@font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
@font-face
	{font-family:Cambria;
	panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
	{font-family:"\@MS Mincho";
	panose-1:0 0 0 0 0 0 0 0 0 0;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0cm;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman";}
a:link, span.MsoHyperlink
	{color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{color:purple;
	text-decoration:underline;}
p.emailquote, li.emailquote, div.emailquote
	{mso-margin-top-alt:auto;
	margin-right:0cm;
	mso-margin-bottom-alt:auto;
	margin-left:1.0pt;
	border:none;
	padding:0cm;
	font-size:12.0pt;
	font-family:"Times New Roman";}
span.EmailStyle18
	{mso-style-type:personal-reply;
	font-family:Verdana;
	color:blue;
	font-weight:normal;
	font-style:normal;
	text-decoration:none none;}
p.ListParagraph, li.ListParagraph, div.ListParagraph
	{margin-top:0cm;
	margin-right:0cm;
	margin-bottom:0cm;
	margin-left:36.0pt;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:Cambria;}
p.ListParagraphCxSpFirst, li.ListParagraphCxSpFirst, div.ListParagraphCxSpFirst
	{mso-style-type:export-only;
	margin-top:0cm;
	margin-right:0cm;
	margin-bottom:0cm;
	margin-left:36.0pt;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:Cambria;}
p.ListParagraphCxSpMiddle, li.ListParagraphCxSpMiddle, div.ListParagraphCxSpMiddle
	{mso-style-type:export-only;
	margin-top:0cm;
	margin-right:0cm;
	margin-bottom:0cm;
	margin-left:36.0pt;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:Cambria;}
p.ListParagraphCxSpLast, li.ListParagraphCxSpLast, div.ListParagraphCxSpLast
	{mso-style-type:export-only;
	margin-top:0cm;
	margin-right:0cm;
	margin-bottom:0cm;
	margin-left:36.0pt;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:Cambria;}
@page Section1
	{size:612.0pt 792.0pt;
	margin:70.85pt 2.0cm 2.0cm 2.0cm;}
div.Section1
	{page:Section1;}
 /* List Definitions */
 @list l0
	{mso-list-id:188836904;
	mso-list-type:hybrid;
	mso-list-template-ids:-1905122362 1173243028 134807577 134807579 134807567 134807577 134807579 134807567 134807577 134807579;}
@list l0:level1
	{mso-level-start-at:2;
	mso-level-tab-stop:0cm;
	mso-level-number-position:left;
	text-indent:-18.0pt;
	mso-bidi-font-family:"Times New Roman";}
@list l0:level2
	{mso-level-number-format:alpha-lower;
	mso-level-tab-stop:none;
	mso-level-number-position:left;
	text-indent:-18.0pt;
	mso-bidi-font-family:"Times New Roman";}
@list l1
	{mso-list-id:556667903;
	mso-list-template-ids:956698022;}
@list l1:level1
	{mso-level-tab-stop:none;
	mso-level-number-position:left;
	text-indent:-18.0pt;
	mso-bidi-font-family:"Times New Roman";}
@list l1:level2
	{mso-level-number-format:alpha-lower;
	mso-level-tab-stop:none;
	mso-level-number-position:left;
	text-indent:-18.0pt;
	mso-bidi-font-family:"Times New Roman";}
@list l1:level3
	{mso-level-number-format:roman-lower;
	mso-level-tab-stop:none;
	mso-level-number-position:right;
	text-indent:-9.0pt;
	mso-bidi-font-family:"Times New Roman";}
@list l1:level4
	{mso-level-tab-stop:none;
	mso-level-number-position:left;
	text-indent:-18.0pt;
	mso-bidi-font-family:"Times New Roman";}
@list l1:level5
	{mso-level-number-format:alpha-lower;
	mso-level-tab-stop:none;
	mso-level-number-position:left;
	text-indent:-18.0pt;
	mso-bidi-font-family:"Times New Roman";}
@list l1:level6
	{mso-level-number-format:roman-lower;
	mso-level-tab-stop:none;
	mso-level-number-position:right;
	text-indent:-9.0pt;
	mso-bidi-font-family:"Times New Roman";}
@list l1:level7
	{mso-level-tab-stop:none;
	mso-level-number-position:left;
	text-indent:-18.0pt;
	mso-bidi-font-family:"Times New Roman";}
@list l1:level8
	{mso-level-number-format:alpha-lower;
	mso-level-tab-stop:none;
	mso-level-number-position:left;
	text-indent:-18.0pt;
	mso-bidi-font-family:"Times New Roman";}
@list l1:level9
	{mso-level-number-format:roman-lower;
	mso-level-tab-stop:none;
	mso-level-number-position:right;
	text-indent:-9.0pt;
	mso-bidi-font-family:"Times New Roman";}
ol
	{margin-bottom:0cm;}
ul
	{margin-bottom:0cm;}
-->
</style><!-- converted from rtf --><!--[if gte mso 9]><xml>
 <o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
 <o:shapelayout v:ext="edit">
  <o:idmap v:ext="edit" data="1" />
 </o:shapelayout></xml><![endif]-->
</head>
<body lang="EN-US" link="blue" vlink="purple">
<div class="Section1">
<p class="MsoNormal"><font size="2" color="blue" face="Verdana"><span style="font-size:
10.0pt;font-family:Verdana;color:blue">Hello,
<o:p></o:p></span></font></p>
<p class="MsoNormal"><font size="2" color="blue" face="Verdana"><span style="font-size:
10.0pt;font-family:Verdana;color:blue">&nbsp;I have a question on working item 2:<o:p></o:p></span></font></p>
<p class="MsoNormal"><font size="2" color="blue" face="Verdana"><span style="font-size:
10.0pt;font-family:Verdana;color:blue"><o:p>&nbsp;</o:p></span></font></p>
<p class="MsoNormal"><font size="2" face="Verdana"><span style="font-size:10.0pt;
font-family:Verdana">&#8220;The working group is chartered to work on the following items:<o:p></o:p></span></font></p>
<p class="MsoNormal"><font size="2" face="Verdana"><span style="font-size:10.0pt;
font-family:Verdana"><o:p>&nbsp;</o:p></span></font></p>
<p class="ListParagraphCxSpFirst" style="text-indent:-18.0pt;mso-list:l0 level1 lfo1">
<![if !supportLists]><font size="2" face="Verdana"><span style="font-size:10.0pt;font-family:Verdana"><span style="mso-list:Ignore">2.<font size="1" face="Times New Roman"><span style="font:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</span></font></span></span></font><![endif]><font size="2" face="Verdana"><span style="font-size:10.0pt;font-family:Verdana">&nbsp;Tightly scoped key use cases for operational use of IRS. These use cases will include at least:<o:p></o:p></span></font></p>
<p class="ListParagraphCxSpMiddle" style="margin-left:72.0pt;text-indent:-18.0pt;
mso-list:l0 level2 lfo1">
<![if !supportLists]><font size="2" face="Verdana"><span style="font-size:10.0pt;font-family:Verdana"><span style="mso-list:Ignore">a.<font size="1" face="Times New Roman"><span style="font:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</span></font></span></span></font><![endif]><font size="2" face="Verdana"><span style="font-size:10.0pt;font-family:Verdana">Interactions with the RIB<o:p></o:p></span></font></p>
<p class="ListParagraphCxSpMiddle" style="margin-left:72.0pt;text-indent:-18.0pt;
mso-list:l0 level2 lfo1">
<![if !supportLists]><font size="2" face="Verdana"><span style="font-size:10.0pt;font-family:Verdana"><span style="mso-list:Ignore">b.<font size="1" face="Times New Roman"><span style="font:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</span></font></span></span></font><![endif]><font size="2" face="Verdana"><span style="font-size:10.0pt;font-family:Verdana">Association of routing policies with routing state<o:p></o:p></span></font></p>
<p class="ListParagraphCxSpLast" style="margin-left:72.0pt;text-indent:-18.0pt;
mso-list:l0 level2 lfo1">
<![if !supportLists]><font size="2" face="Verdana"><span style="font-size:10.0pt;font-family:Verdana"><span style="mso-list:Ignore">c.<font size="1" face="Times New Roman"><span style="font:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</span></font></span></span></font><![endif]><font size="2" face="Verdana"><span style="font-size:10.0pt;font-family:Verdana">The ability to extract information about topology from the network<o:p></o:p></span></font></p>
<p class="MsoNormal"><font size="2" face="Verdana"><span style="font-size:10.0pt;
font-family:Verdana">&#8220;<o:p></o:p></span></font></p>
<p class="MsoNormal"><font size="2" color="blue" face="Verdana"><span style="font-size:
10.0pt;font-family:Verdana;color:blue">Does this bullet exclude the possibility to use IRS to gather information about network measurements such as available bandwidth
 on a link, information related to jitter delay for specific flows etc. ?<o:p></o:p></span></font></p>
<p class="MsoNormal"><font size="2" color="blue" face="Verdana"><span style="font-size:
10.0pt;font-family:Verdana;color:blue"><o:p>&nbsp;</o:p></span></font></p>
<p class="MsoNormal"><font size="2" color="blue" face="Verdana"><span style="font-size:
10.0pt;font-family:Verdana;color:blue">Thanks,<o:p></o:p></span></font></p>
<p class="MsoNormal"><font size="2" color="blue" face="Verdana"><span style="font-size:
10.0pt;font-family:Verdana;color:blue">Roberta
<o:p></o:p></span></font></p>
<div>
<div class="MsoNormal" align="center" style="text-align:center"><font size="3" face="Times New Roman"><span style="font-size:12.0pt">
<hr size="2" width="100%" align="center" tabindex="-1">
</span></font></div>
<p class="MsoNormal"><b><font size="2" face="Tahoma"><span style="font-size:10.0pt;
font-family:Tahoma;font-weight:bold">From:</span></font></b><font size="2" face="Tahoma"><span style="font-size:10.0pt;font-family:Tahoma"> [email-masked] [mailto:[email-masked]]
<b><span style="font-weight:bold">On Behalf Of </span></b>Ross Callon<br>
<b><span style="font-weight:bold">Sent:</span></b> Thursday, October 18, 2012 5:55 PM<br>
<b><span style="font-weight:bold">To:</span></b> [email-masked]<br>
<b><span style="font-weight:bold">Cc:</span></b> Ross Callon; [email-masked]<br>
<b><span style="font-weight:bold">Subject:</span></b> [irs-discuss] Rough Draft IRS Charter</span></font><o:p></o:p></p>
</div>
<p class="MsoNormal"><font size="3" face="Times New Roman"><span style="font-size:
12.0pt"><o:p>&nbsp;</o:p></span></font></p>
<div>
<p class="MsoNormal"><font size="2" face="Calibri"><span style="font-size:10.0pt;
font-family:Calibri">Attached (in Word format) is a very rough initial draft charter (for a potential IRS WG) that the BOF chairs have been discussing with our friendly sponsoring
 routing area AD. <o:p></o:p></span></font></p>
</div>
<div>
<p class="MsoNormal"><font size="2" face="Calibri"><span style="font-size:10.0pt;
font-family:Calibri">&nbsp;<o:p></o:p></span></font></p>
</div>
<div>
<p class="MsoNormal"><font size="2" face="Calibri"><span style="font-size:10.0pt;
font-family:Calibri">Comments are welcome. We will be discussing the draft IRS WG charter in
<st1:City w:st="on"><st1:place w:st="on">Atlanta</st1:place></st1:City>. <o:p></o:p></span></font></p>
</div>
<div>
<p class="MsoNormal"><font size="2" face="Calibri"><span style="font-size:10.0pt;
font-family:Calibri">&nbsp;<o:p></o:p></span></font></p>
</div>
<div>
<p class="MsoNormal"><font size="2" face="Calibri"><span style="font-size:10.0pt;
font-family:Calibri">Thanks, Ross<o:p></o:p></span></font></p>
</div>
<div>
<p class="MsoNormal"><font size="2" face="Calibri"><span style="font-size:10.0pt;
font-family:Calibri">(with input from Dave and Adrian)<o:p></o:p></span></font></p>
</div>
<div>
<p class="MsoNormal"><font size="2" face="Calibri"><span style="font-size:10.0pt;
font-family:Calibri">&nbsp;<o:p></o:p></span></font></p>
</div>
<div>
<p class="MsoNormal"><font size="2" face="Calibri"><span style="font-size:10.0pt;
font-family:Calibri">&nbsp;<o:p></o:p></span></font></p>
</div>
<div>
<p class="MsoNormal"><font size="2" face="Calibri"><span style="font-size:10.0pt;
font-family:Calibri">&nbsp;<o:p></o:p></span></font></p>
</div>
</div>
<style type="text/css">
<!--
span.GramE {mso-style-name:"";
	mso-gram-e:yes;}
-->
</style>
<table style="width:600px;">
<tbody>
<tr>
<td style="width:585px; font-family: Verdana, Arial; font-size:12px; color:#000; text-align: justify" width="395">
<div align="justify"><span class="MsoNormal" style="text-align:justify; line-height:normal"><span style="font-size:7.5pt;font-family:Verdana">Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle persone indicate. La diffusione, copia o qualsiasi
 altra azione derivante dalla conoscenza di queste informazioni sono rigorosamente vietate. Qualora abbiate ricevuto questo documento per errore siete cortesemente pregati di darne immediata comunicazione al mittente e di provvedere alla sua distruzione, Grazie.
</span></span></div>
<p align="justify"><span class="MsoNormal" style="text-align:justify; line-height:normal"><i><span lang="EN-GB" style="font-size:7.5pt;font-family:Verdana;mso-ansi-language:EN-GB">This e-mail and any attachments</span></i><i><span lang="EN-GB" style="font-size:
  7.5pt;mso-bidi-font-size:11.0pt;font-family:Verdana;mso-ansi-language:EN-GB">&nbsp;<span class="GramE">is</span>&nbsp;</span></i><i><span lang="EN-GB" style="font-size:
  7.5pt;font-family:Verdana;mso-ansi-language:EN-GB">confidential
 and may contain privileged information intended for the addressee(s) only. Dissemination, copying, printing or use by anybody else is unauthorised. If you are not the intended recipient, please delete this message and any attachments and advise the sender
 by return e-mail, Thanks.</span></i><span lang="EN-GB" style="mso-ansi-language:EN-GB">
</span></span></p>
<b><span style="font-size:7.5pt;
  font-family:Verdana"><img src="cid:[email-masked]" alt="rispetta l'ambiente" width="26" height="40">Rispetta l'ambiente. Non stampare questa mail se non &egrave; necessario.</span></b>
<p></p>
</td>
</tr>
</tbody>
</table>
</body>
</html>

--_000_282BBE8A501E1F4DA9C775F964BB21FE519702F264GRFMBX704BA02_--

--_0c4e719e-f351-4e2c-ad63-be050bc9d0a1_
Content-Description: logo Ambiente_foglia2.jpg
Content-Type: image/jpeg; name="logo Ambiente_foglia2.jpg"
Content-Disposition: inline; filename="logo Ambiente_foglia2.jpg"
Content-Transfer-Encoding: base64
Content-ID: [email-masked]

--_0c4e719e-f351-4e2c-ad63-be050bc9d0a1_--

Date: Thu, 18 Oct 2012 20:14:23 -0400
From: Russ White <[email-masked]>
To: [email-masked]
Subject: Re: [irs-discuss] Rough Draft IRS Charter

>> It seems to me that the second paragraph of the description is misleading
>> and unfortunate.  The proposed interface is not inherently any faster (or
>> slower) than any other existing interface.  It may in fact use existing
>> protocols and mechanisms.  At the same time, the stated goal is to expose
>> information and models that are generalizations or synthesized combinations
>> of what the devices currently expose.  This is unlikely to be meaningfully
>> manipulated using the same paradigms that operators currently use.
> 
> Agree Joel. In addition, there can easily be confusion as terms like
> "fast path" are more conventionally used to refer to switching paths.

+1

It's always easy to say, "this will be faster," but it's going to wind
up being far too implementation dependent to be a really meaningful or
useful measure.

Russ

-- 
<><
[email-masked]
[email-masked]

Date: Thu, 18 Oct 2012 15:23:39 -0700
From: David Meyer <[email-masked]>
To: "Joel M. Halpern" <[email-masked]>
Cc: Ross Callon <[email-masked]>, "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [irs-discuss] Rough Draft IRS Charter

On Thu, Oct 18, 2012 at 11:12 AM, Joel M. Halpern <[email-masked]> wrote:
> It seems to me that the second paragraph of the description is misleading
> and unfortunate.  The proposed interface is not inherently any faster (or
> slower) than any other existing interface.  It may in fact use existing
> protocols and mechanisms.  At the same time, the stated goal is to expose
> information and models that are generalizations or synthesized combinations
> of what the devices currently expose.  This is unlikely to be meaningfully
> manipulated using the same paradigms that operators currently use.

Agree Joel. In addition, there can easily be confusion as terms like
"fast path" are more conventionally used to refer to switching paths.

--dmm

Date: Thu, 18 Oct 2012 18:07:00 -0400
From: Lou Berger <[email-masked]>
To: Ross Callon <[email-masked]>,  "[email-masked]" <[email-masked]>
Cc: "Joel M. Halpern" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [irs-discuss] Rough Draft IRS Charter

I have to say I agree with Joel on this.

Also, an unrelated comment: do you/we want to scope what is meant by
"Topology"?  For example, is TE/resource information in or out of scope?
 What about LFIB?  TMF.DM-1 of draft-medved-irs-topology-requirements
has a long list, are any out of scope?

Lou

On 10/18/2012 2:12 PM, Joel M. Halpern wrote:
> It seems to me that the second paragraph of the description is 
> misleading and unfortunate.  The proposed interface is not inherently 
> any faster (or slower) than any other existing interface.  It may in 
> fact use existing protocols and mechanisms.  At the same time, the 
> stated goal is to expose information and models that are generalizations 
> or synthesized combinations of what the devices currently expose.  This 
> is unlikely to be meaningfully manipulated using the same paradigms that 
> operators currently use.
> 
> Would it still hang together if he paragraph were simply removed?
> 
> Yours,
> Joel
> 
> On 10/18/2012 11:55 AM, Ross Callon wrote:
>> Attached (in Word format) is a very rough initial draft charter (for a
>> potential IRS WG) that the BOF chairs have been discussing with our
>> friendly sponsoring routing area AD.
>> Comments are welcome. We will be discussing the draft IRS WG charter in
>> Atlanta.
>> Thanks, Ross
>> (with input from Dave and Adrian)
>>
>>
>> _______________________________________________
>> 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
> 
> 
> 
> 

Date: Thu, 18 Oct 2012 14:12:22 -0400
From: "Joel M. Halpern" <[email-masked]>
To: Ross Callon <[email-masked]>
Cc: "[email-masked]" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [irs-discuss] Rough Draft IRS Charter

It seems to me that the second paragraph of the description is 
misleading and unfortunate.  The proposed interface is not inherently 
any faster (or slower) than any other existing interface.  It may in 
fact use existing protocols and mechanisms.  At the same time, the 
stated goal is to expose information and models that are generalizations 
or synthesized combinations of what the devices currently expose.  This 
is unlikely to be meaningfully manipulated using the same paradigms that 
operators currently use.

Would it still hang together if he paragraph were simply removed?

Yours,
Joel

On 10/18/2012 11:55 AM, Ross Callon wrote:
> Attached (in Word format) is a very rough initial draft charter (for a
> potential IRS WG) that the BOF chairs have been discussing with our
> friendly sponsoring routing area AD.
> Comments are welcome. We will be discussing the draft IRS WG charter in
> Atlanta.
> Thanks, Ross
> (with input from Dave and Adrian)
>
>
> _______________________________________________
> irs-discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/irs-discuss
>

From: Ross Callon <[email-masked]>
To: "[email-masked]" <[email-masked]>
Date: Thu, 18 Oct 2012 11:55:07 -0400
Accept-Language: en-US
acceptlanguage: en-US
Cc: Ross Callon <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: [irs-discuss] Rough Draft IRS Charter

--_004_DF7F294AF4153D498141CBEFADB17704C7EC9FE484EMBX01WFjnprn_
Content-Type: multipart/alternative;
	boundary="_000_DF7F294AF4153D498141CBEFADB17704C7EC9FE484EMBX01WFjnprn_"

--_000_DF7F294AF4153D498141CBEFADB17704C7EC9FE484EMBX01WFjnprn_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Attached (in Word format) is a very rough initial draft charter (for a potential IRS WG) that the BOF chairs have been discussing with our friendly sponsoring routing area AD.

Comments are welcome. We will be discussing the draft IRS WG charter in Atlanta.

Thanks, Ross
(with input from Dave and Adrian)

--_000_DF7F294AF4153D498141CBEFADB17704C7EC9FE484EMBX01WFjnprn_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
<meta name="Generator" content="Microsoft Exchange Server">
<!-- converted from rtf -->
<style><!-- .EmailQuote { margin-left: 1pt; padding-left: 4pt; border-left: #800000 2px solid; } --></style>
</head>
<body>
<font face="Calibri, sans-serif" size="2">
<div>Attached (in Word format) is a very rough initial draft charter (for a potential IRS WG) that the BOF chairs have been discussing with our friendly sponsoring routing area AD. </div>
<div>&nbsp;</div>
<div>Comments are welcome. We will be discussing the draft IRS WG charter in Atlanta. </div>
<div>&nbsp;</div>
<div>Thanks, Ross</div>
<div>(with input from Dave and Adrian)</div>
<div>&nbsp;</div>
<div>&nbsp;</div>
<div> </div>
<div>&nbsp;</div>
</font>
</body>
</html>

--_000_DF7F294AF4153D498141CBEFADB17704C7EC9FE484EMBX01WFjnprn_--

--_004_DF7F294AF4153D498141CBEFADB17704C7EC9FE484EMBX01WFjnprn_
Content-Type: application/vnd.openxmlformats-officedocument.wordprocessingml.document;
	name="First-draft-IRS-charter.docx"
Content-Description: First-draft-IRS-charter.docx
Content-Disposition: attachment; filename="First-draft-IRS-charter.docx";
	size072; creation-date="Thu, 18 Oct 2012 15:50:01 GMT";
	modification-date="Thu, 18 Oct 2012 15:50:02 GMT"
Content-Transfer-Encoding: base64

AAAA

--_004_DF7F294AF4153D498141CBEFADB17704C7EC9FE484EMBX01WFjnprn_--

From: "Rex Fernando (rex)" <[email-masked]>
To: "[email-masked]" <[email-masked]>
Date: Wed, 17 Oct 2012 18:07:34 +0000
Accept-Language: en-US
Cc: Ross Callon <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: [irs-discuss] IRS framework requirements

--_000_868851912C182241B686E0BD4D73BC17142C97xmbalnx08ciscocom_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Folks,

We've submitted a framework requirements draft for IRS. Its located here,

http://tools.ietf.org/html/draft-rfernando-irs-framework-requirement-00

The draft tries to outline the various concerns and requirements to be addressed in making the IRS framework. It also establishes a  vocabulary so that we speak the same language when describing matters related to IRS. This is a preliminary version and expected to evolve (quite a bit)  to its final form with community input.

Please review and provide comments.

Cheers,

- Rex

--_000_868851912C182241B686E0BD4D73BC17142C97xmbalnx08ciscocom_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
<meta name="Generator" content="Microsoft Word 14 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
	{font-family:"Cambria Math";
	panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
p.MsoPlainText, li.MsoPlainText, div.MsoPlainText
	{mso-style-priority:99;
	mso-style-link:"Plain Text Char";
	margin:0in;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:"Calibri","sans-serif";}
p.emailquote, li.emailquote, div.emailquote
	{mso-style-name:emailquote;
	mso-margin-top-alt:auto;
	margin-right:0in;
	mso-margin-bottom-alt:auto;
	margin-left:1.0pt;
	border:none;
	padding:0in;
	font-size:12.0pt;
	font-family:"Times New Roman","serif";}
span.EmailStyle18
	{mso-style-type:personal-reply;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
span.PlainTextChar
	{mso-style-name:"Plain Text Char";
	mso-style-priority:99;
	mso-style-link:"Plain Text";
	font-family:"Calibri","sans-serif";}
.MsoChpDefault
	{mso-style-type:export-only;
	font-size:10.0pt;}
@page WordSection1
	{size:8.5in 11.0in;
	margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
	{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang="EN-US" link="blue" vlink="purple">
<div class="WordSection1">
<p class="MsoPlainText">Folks,<o:p></o:p></p>
<p class="MsoPlainText"><o:p>&nbsp;</o:p></p>
<p class="MsoPlainText">We've submitted a framework requirements draft for IRS. Its located here,<o:p></o:p></p>
<p class="MsoPlainText"><o:p>&nbsp;</o:p></p>
<p class="MsoPlainText"><a href="http://tools.ietf.org/html/draft-rfernando-irs-framework-requirement-00">http://tools.ietf.org/html/draft-rfernando-irs-framework-requirement-00</a><o:p></o:p></p>
<p class="MsoPlainText"><o:p>&nbsp;</o:p></p>
<p class="MsoPlainText">The draft tries to outline the various concerns and requirements to be addressed in making the IRS framework. It also establishes a&nbsp; vocabulary so that we speak the same language when describing matters related to IRS. This is a preliminary
 version and expected to evolve (quite a bit)&nbsp; to its final form with community input.
<o:p></o:p></p>
<p class="MsoPlainText"><o:p>&nbsp;</o:p></p>
<p class="MsoPlainText">Please review and provide comments.<o:p></o:p></p>
<p class="MsoPlainText"><o:p>&nbsp;</o:p></p>
<p class="MsoPlainText">Cheers,<o:p></o:p></p>
<p class="MsoPlainText">- Rex<o:p></o:p></p>
</div>
</body>
</html>

--_000_868851912C182241B686E0BD4D73BC17142C97xmbalnx08ciscocom_--

From: "Susan Hares" <[email-masked]>
To: "'Ross Callon'" <[email-masked]>, <[email-masked]>
Date: Wed, 17 Oct 2012 06:00:11 -0400
Subject: Re: [irs-discuss] Spam:*******,  IRS Internet Drafts

This is a multipart message in MIME format.

------=_NextPart_000_005E_01CDAC2C.ABEE1DA0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit

Ross:

Please add draft-hares-use-case-vn-vc-00
<http://datatracker.ietf.org/doc/draft-hares-use-case-vn-vc/>  to you list.

Sue 

From: [email-masked] [mailto:[email-masked]] On
Behalf Of Ross Callon
Sent: Tuesday, October 16, 2012 11:45 PM
To: [email-masked]
Subject: Spam:*******, [irs-discuss] IRS Internet Drafts

We now have nine Internet Drafts related to IRS. This is a great start! (and
given that the -00 deadline has passed, I am guessing that this might be the
number until the IETF starts). Thanks to all of the authors for their work. 

I would like to encourage the authors of these nine drafts to introduce them
to the IRS-discuss email list. 

The nine drafts are follows (please let the list know if I am missing any): 

draft-amante-irs-topology-use-cases-00

draft-atlas-irs-policy-framework-00

draft-atlas-irs-problem-statement-00

draft-dimitri-irs-arch-frame-00

draft-keyupate-irs-bgp-usecases-00

draft-medved-irs-topology-requirements-00

draft-rfernando-irs-framework-requirement-00

draft-ward-irs-framework-00

draft-white-irs-use-case-00

Thanks, Ross

------=_NextPart_000_005E_01CDAC2C.ABEE1DA0
Content-Type: text/html;
	charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40"><head><META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=us-ascii"><meta name=Generator content="Microsoft Word 14 (filtered medium)"><style><!--
/* Font Definitions */
@font-face
	{font-family:"Cambria Math";
	panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
p.emailquote, li.emailquote, div.emailquote
	{mso-style-name:emailquote;
	mso-margin-top-alt:auto;
	margin-right:0in;
	mso-margin-bottom-alt:auto;
	margin-left:1.0pt;
	border:none;
	padding:0in;
	font-size:12.0pt;
	font-family:"Times New Roman","serif";}
span.EmailStyle18
	{mso-style-type:personal-reply;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
.MsoChpDefault
	{mso-style-type:export-only;
	font-size:10.0pt;}
@page WordSection1
	{size:8.5in 11.0in;
	margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
	{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]--></head><body lang=EN-US link=blue vlink=purple><div class=WordSection1><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'>Ross:<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><br>Please add </span><span style='font-size:10.0pt;font-family:"Arial","sans-serif"'><a href="http://datatracker.ietf.org/doc/draft-hares-use-case-vn-vc/">draft-hares-use-case-vn-vc-00</a> to you list.<o:p></o:p></span></p><p class=MsoNormal><span style='font-size:10.0pt;font-family:"Arial","sans-serif"'><o:p>&nbsp;</o:p></span></p><p class=MsoNormal><span style='font-size:10.0pt;font-family:"Arial","sans-serif"'>Sue </span><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p></o:p></span></p><p class=MsoNormal><span style='font-size:11.0pt;font-family:"Calibri","sans-serif";color:#1F497D'><o:p>&nbsp;</o:p></span></p><div><div style='border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in'><p class=MsoNormal><b><span style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'>From:</span></b><span style='font-size:10.0pt;font-family:"Tahoma","sans-serif"'> [email-masked] [mailto:[email-masked]] <b>On Behalf Of </b>Ross Callon<br><b>Sent:</b> Tuesday, October 16, 2012 11:45 PM<br><b>To:</b> [email-masked]<br><b>Subject:</b> Spam:*******, [irs-discuss] IRS Internet Drafts<o:p></o:p></span></p></div></div><p class=MsoNormal><o:p>&nbsp;</o:p></p><div><p class=MsoNormal><span style='font-size:10.0pt;font-family:"Calibri","sans-serif"'>We now have nine Internet Drafts related to IRS. This is a great start! (and given that the -00 deadline has passed, I am guessing that this might be the number until the IETF starts). Thanks to all of the authors for their work. <o:p></o:p></span></p></div><div><p class=MsoNormal><span style='font-size:10.0pt;font-family:"Calibri","sans-serif"'>&nbsp;<o:p></o:p></span></p></div><div><p class=MsoNormal><span style='font-size:10.0pt;font-family:"Calibri","sans-serif"'>I would like to encourage the authors of these nine drafts to introduce them to the IRS-discuss email list. <o:p></o:p></span></p></div><div><p class=MsoNormal><span style='font-size:10.0pt;font-family:"Calibri","sans-serif"'>&nbsp;<o:p></o:p></span></p></div><div><p class=MsoNormal><span style='font-size:10.0pt;font-family:"Calibri","sans-serif"'>The nine drafts are follows (please let the list know if I am missing any): <o:p></o:p></span></p></div><div><p class=MsoNormal><span style='font-size:10.0pt;font-family:"Calibri","sans-serif"'>&nbsp;<o:p></o:p></span></p></div><div><p class=MsoNormal><span style='font-size:10.0pt;font-family:"Courier New"'>draft-amante-irs-topology-use-cases-00</span><span style='font-size:10.0pt;font-family:"Calibri","sans-serif"'><o:p></o:p></span></p></div><div><p class=MsoNormal><span style='font-size:10.0pt;font-family:"Courier New"'>draft-atlas-irs-policy-framework-00</span><span style='font-size:10.0pt;font-family:"Calibri","sans-serif"'><o:p></o:p></span></p></div><div><p class=MsoNormal><span style='font-size:10.0pt;font-family:"Courier New"'>draft-atlas-irs-problem-statement-00</span><span style='font-size:10.0pt;font-family:"Calibri","sans-serif"'><o:p></o:p></span></p></div><div><p class=MsoNormal><span style='font-size:10.0pt;font-family:"Courier New"'>draft-dimitri-irs-arch-frame-00</span><span style='font-size:10.0pt;font-family:"Calibri","sans-serif"'><o:p></o:p></span></p></div><div><p class=MsoNormal><span style='font-size:10.0pt;font-family:"Courier New"'>draft-keyupate-irs-bgp-usecases-00</span><span style='font-size:10.0pt;font-family:"Calibri","sans-serif"'><o:p></o:p></span></p></div><div><p class=MsoNormal><span style='font-size:10.0pt;font-family:"Courier New"'>draft-medved-irs-topology-requirements-00</span><span style='font-size:10.0pt;font-family:"Calibri","sans-serif"'><o:p></o:p></span></p></div><div><p class=MsoNormal><span style='font-size:10.0pt;font-family:"Courier New"'>draft-rfernando-irs-framework-requirement-00</span><span style='font-size:10.0pt;font-family:"Calibri","sans-serif"'><o:p></o:p></span></p></div><div><p class=MsoNormal><span style='font-size:10.0pt;font-family:"Courier New"'>draft-ward-irs-framework-00</span><span style='font-size:10.0pt;font-family:"Calibri","sans-serif"'><o:p></o:p></span></p></div><div><p class=MsoNormal><span style='font-size:10.0pt;font-family:"Courier New"'>draft-white-irs-use-case-00</span><span style='font-size:10.0pt;font-family:"Calibri","sans-serif"'><o:p></o:p></span></p></div><div><p class=MsoNormal><span style='font-size:10.0pt;font-family:"Calibri","sans-serif"'>&nbsp;<o:p></o:p></span></p></div><div><p class=MsoNormal><span style='font-size:10.0pt;font-family:"Calibri","sans-serif"'>Thanks, Ross<o:p></o:p></span></p></div><div><p class=MsoNormal><span style='font-size:10.0pt;font-family:"Calibri","sans-serif"'>&nbsp;<o:p></o:p></span></p></div></div></body></html>
------=_NextPart_000_005E_01CDAC2C.ABEE1DA0--

From: Ross Callon <[email-masked]>
To: "[email-masked]" <[email-masked]>
Date: Tue, 16 Oct 2012 23:44:44 -0400
Accept-Language: en-US
acceptlanguage: en-US
Subject: [irs-discuss] IRS Internet Drafts

--_000_DF7F294AF4153D498141CBEFADB17704C7EC8DA5F2EMBX01WFjnprn_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

We now have nine Internet Drafts related to IRS. This is a great start! (and given that the -00 deadline has passed, I am guessing that this might be the number until the IETF starts). Thanks to all of the authors for their work.

I would like to encourage the authors of these nine drafts to introduce them to the IRS-discuss email list.

The nine drafts are follows (please let the list know if I am missing any):

draft-amante-irs-topology-use-cases-00
draft-atlas-irs-policy-framework-00
draft-atlas-irs-problem-statement-00
draft-dimitri-irs-arch-frame-00
draft-keyupate-irs-bgp-usecases-00
draft-medved-irs-topology-requirements-00
draft-rfernando-irs-framework-requirement-00
draft-ward-irs-framework-00
draft-white-irs-use-case-00

Thanks, Ross

--_000_DF7F294AF4153D498141CBEFADB17704C7EC8DA5F2EMBX01WFjnprn_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
<meta name="Generator" content="Microsoft Exchange Server">
<!-- converted from rtf -->
<style><!-- .EmailQuote { margin-left: 1pt; padding-left: 4pt; border-left: #800000 2px solid; } --></style>
</head>
<body>
<font face="Calibri, sans-serif" size="2">
<div>We now have nine Internet Drafts related to IRS. This is a great start! (and given that the -00 deadline has passed, I am guessing that this might be the number until the IETF starts). Thanks to all of the authors for their work. </div>
<div>&nbsp;</div>
<div>I would like to encourage the authors of these nine drafts to introduce them to the IRS-discuss email list. </div>
<div>&nbsp;</div>
<div>The nine drafts are follows (please let the list know if I am missing any): </div>
<div>&nbsp;</div>
<div><font face="Courier New, monospace" size="2">draft-amante-irs-topology-use-cases-00</font></div>
<div><font face="Courier New, monospace" size="2">draft-atlas-irs-policy-framework-00</font></div>
<div><font face="Courier New, monospace" size="2">draft-atlas-irs-problem-statement-00</font></div>
<div><font face="Courier New, monospace" size="2">draft-dimitri-irs-arch-frame-00</font></div>
<div><font face="Courier New, monospace" size="2">draft-keyupate-irs-bgp-usecases-00</font></div>
<div><font face="Courier New, monospace" size="2">draft-medved-irs-topology-requirements-00</font></div>
<div><font face="Courier New, monospace" size="2">draft-rfernando-irs-framework-requirement-00</font></div>
<div><font face="Courier New, monospace" size="2">draft-ward-irs-framework-00</font></div>
<div><font face="Courier New, monospace" size="2">draft-white-irs-use-case-00</font></div>
<div>&nbsp;</div>
<div>Thanks, Ross</div>
<div>&nbsp;</div>
</font>
</body>
</html>

--_000_DF7F294AF4153D498141CBEFADB17704C7EC8DA5F2EMBX01WFjnprn_--

From: "Kausik Majumdar (kmajumda)" <[email-masked]>
To: "[email-masked]" <[email-masked]>
Date: Wed, 10 Oct 2012 15:22:04 +0000
Accept-Language: en-US
Subject: [irs-discuss]  central membership computation for mpls VPNs

--_000_B81B498DA819A64E907482A44E472CE40F517247xmbrcdx12ciscoc_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi,

I am new in irs alias. I was looking through the draft http://www.ietf.org/id/draft-white-irs-use-case-00.txt to find out some more details on the central membership computation for MPLS VPNs as mentioned in the doc -

   MPLS based VPNs use route target extended communities to express
   membership information.  Every PE router holds incoming BGP NLRI and
   processes them to determine membership and then import the NLRI into
   the appropriate MPLS/VPN routing tables.  This consumes resources,
   both memory and compute on each of the PE devices.

   An alternative approach is to monitor routing updates on every PE
   from the attached CEs and then compute membership in a central
   manner.  Once computed the routes are pushed to the VPN RIBs of the
   participating PEs.

Are we talking about exporting the route updates from each PEs to a central server out of hw devices and compute BGP membership centrally and then downloading the selective/optimized routes to the respective PEs ? Can someone point me some details on how to compute membership in a central manner.

Thanks in advance,
Kausik

--_000_B81B498DA819A64E907482A44E472CE40F517247xmbrcdx12ciscoc_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
<meta name="Generator" content="Microsoft Word 12 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
	{font-family:"Cambria Math";
	panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:11.0pt;
	font-family:"Calibri","sans-serif";}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
pre
	{mso-style-priority:99;
	mso-style-link:"HTML Preformatted Char";
	margin:0in;
	margin-bottom:.0001pt;
	font-size:10.0pt;
	font-family:"Courier New";}
span.EmailStyle17
	{mso-style-type:personal-compose;
	font-family:"Calibri","sans-serif";
	color:windowtext;}
span.HTMLPreformattedChar
	{mso-style-name:"HTML Preformatted Char";
	mso-style-priority:99;
	mso-style-link:"HTML Preformatted";
	font-family:"Courier New";}
.MsoChpDefault
	{mso-style-type:export-only;}
@page WordSection1
	{size:8.5in 11.0in;
	margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
	{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang="EN-US" link="blue" vlink="purple">
<div class="WordSection1">
<p class="MsoNormal"><o:p>&nbsp;</o:p></p>
<p class="MsoNormal">Hi,<o:p></o:p></p>
<p class="MsoNormal"><o:p>&nbsp;</o:p></p>
<p class="MsoNormal">I am new in irs alias. I was looking through the draft <a href="http://www.ietf.org/id/draft-white-irs-use-case-00.txt">
http://www.ietf.org/id/draft-white-irs-use-case-00.txt</a> to find out some more details on the central membership computation for MPLS VPNs as mentioned in the doc &#8211;<o:p></o:p></p>
<p class="MsoNormal"><o:p>&nbsp;</o:p></p>
<p class="MsoNormal"><span style="font-size:10.0pt;font-family:&quot;Courier New&quot;">&nbsp;&nbsp; MPLS based VPNs use route target extended communities to express<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:10.0pt;font-family:&quot;Courier New&quot;">&nbsp;&nbsp; membership information.&nbsp; Every PE router holds incoming BGP NLRI and<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:10.0pt;font-family:&quot;Courier New&quot;">&nbsp;&nbsp; processes them to determine membership and then import the NLRI into<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:10.0pt;font-family:&quot;Courier New&quot;">&nbsp;&nbsp; the appropriate MPLS/VPN routing tables.&nbsp; This consumes resources,<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:10.0pt;font-family:&quot;Courier New&quot;">&nbsp;&nbsp; both memory and compute on each of the PE devices.<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:10.0pt;font-family:&quot;Courier New&quot;"><o:p>&nbsp;</o:p></span></p>
<p class="MsoNormal"><span style="font-size:10.0pt;font-family:&quot;Courier New&quot;">&nbsp;&nbsp; <span style="background:yellow;mso-highlight:yellow">
An alternative approach is to monitor routing updates on every PE<o:p></o:p></span></span></p>
<p class="MsoNormal"><span style="font-size:10.0pt;font-family:&quot;Courier New&quot;;background:yellow;mso-highlight:yellow">&nbsp;&nbsp; from the attached CEs and then compute membership in a central<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:10.0pt;font-family:&quot;Courier New&quot;;background:yellow;mso-highlight:yellow">&nbsp;&nbsp; manner.&nbsp; Once computed the routes are pushed to the VPN RIBs of the<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:10.0pt;font-family:&quot;Courier New&quot;;background:yellow;mso-highlight:yellow">&nbsp;&nbsp; participating PEs.</span><span style="font-size:10.0pt;font-family:&quot;Courier New&quot;"><o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:10.0pt;font-family:&quot;Courier New&quot;"><o:p>&nbsp;</o:p></span></p>
<p class="MsoNormal">Are we talking about exporting the route updates from each PEs to a central server out of hw devices and compute BGP membership centrally and then downloading the selective/optimized routes to the respective PEs ? Can someone point me some
 details on how to compute membership in a central manner.<o:p></o:p></p>
<p class="MsoNormal"><o:p>&nbsp;</o:p></p>
<p class="MsoNormal">Thanks in advance,<o:p></o:p></p>
<p class="MsoNormal">Kausik &nbsp;<o:p></o:p></p>
<p class="MsoNormal"><o:p>&nbsp;</o:p></p>
</div>
</body>
</html>

--_000_B81B498DA819A64E907482A44E472CE40F517247xmbrcdx12ciscoc_--

From: Thomas Nadeau <[email-masked]>
To: Iftekhar Hussain <[email-masked]>, "<[email-masked]>" <[email-masked]>
Accept-Language: en-US
Subject: Re: [irs-discuss] Fwd: New Version Notification for draft-amante-irs-topology-use-cases-00.txt

--_000_CC98CC62FC18tnadeaujunipernet_
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

Will do.

Also, hopefully the forthcoming requirements draft that Jan is publishing tomorrow morning, should help too.

--Tom

From: Iftekhar Hussain <[email-masked]<mailto:[email-masked]>>
Date: Monday, October 8, 2012 6:21 PM
To: Thomas Nadeau <[email-masked]<mailto:[email-masked]>>, "<[email-masked]<mailto:[email-masked]>>" <[email-masked]<mailto:[email-masked]>>
Subject: RE: [irs-discuss] Fwd: New Version Notification for draft-amante-irs-topology-use-cases-00.txt

Hi Tom,

Okay, I see.  I think, it would be helpful to:

�         Clarify the context of this example as currently it is a little unclear. For example, ROADM layer �active� topology would normally be �visible� to the IGP�s LSDB (i.e., IGPs with GMPLS extensions).

�         Add few multi-layer topology examples and their use by network applications (e.g., what type of info one would like to reveal etc.).
Thanks,
Iftekhar
From: Thomas Nadeau [mailto:[email-masked]]
Sent: Monday, October 08, 2012 2:11 PM
To: Iftekhar Hussain; <[email-masked]<mailto:[email-masked]>>
Subject: Re: [irs-discuss] Fwd: New Version Notification for draft-amante-irs-topology-use-cases-00.txt

Hi!

The IRS topology effort is not about what is visible to what devices per se; its about revealing different topological components in a normalized topology database. So in this example, capturing the active information (which is visible via LSDB/IGP routing protocols), is complimented with other inactive (or passive) topological components.

--Tom

From: Iftekhar Hussain <[email-masked]<mailto:[email-masked]>>
Date: Sunday, October 7, 2012 6:00 PM
To: "<[email-masked]<mailto:[email-masked]>>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [irs-discuss] Fwd: New Version Notification for draft-amante-irs-topology-use-cases-00.txt

Hi Authors,
��and visible within the Link State Database (LSDB) of an active IGP, but also network elements who are active, but invisible to a LSDB (e.g.: L2 Ethernet switches, ROADM's, etc.)�
Shouldn�t ROADMs topology be visible to IGP? Perhaps you intend to say optical line amplifier (OLA).
Regards,
Iftekhar

--_000_CC98CC62FC18tnadeaujunipernet_
Content-Type: text/html; charset="Windows-1252"
Content-ID: <[email-masked]>
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=Windows-1252">
</head>
<body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; color: rgb(0, 0, 0); font-size: 14px; font-family: Calibri, sans-serif; ">
<div><br>
</div>
<div><span class="Apple-tab-span" style="white-space:pre"></span>Will do.</div>
<div><br>
</div>
<div><span class="Apple-tab-span" style="white-space:pre"></span>Also, hopefully the forthcoming requirements draft that Jan is publishing tomorrow morning, should help too.</div>
<div><br>
</div>
<div><span class="Apple-tab-span" style="white-space:pre"></span>--Tom</div>
<div><br>
</div>
<div><br>
</div>
<div><br>
</div>
<span id="OLK_SRC_BODY_SECTION">
<div style="font-family:Calibri; font-size:11pt; text-align:left; color:black; BORDER-BOTTOM: medium none; BORDER-LEFT: medium none; PADDING-BOTTOM: 0in; PADDING-LEFT: 0in; PADDING-RIGHT: 0in; BORDER-TOP: #b5c4df 1pt solid; BORDER-RIGHT: medium none; PADDING-TOP: 3pt">
<span style="font-weight:bold">From: </span>Iftekhar Hussain &lt;<a href="mailto:[email-masked]">[email-masked]</a>&gt;<br>
<span style="font-weight:bold">Date: </span>Monday, October 8, 2012 6:21 PM<br>
<span style="font-weight:bold">To: </span>Thomas Nadeau &lt;<a href="mailto:[email-masked]">[email-masked]</a>&gt;, &quot;&lt;<a href="mailto:[email-masked]">[email-masked]</a>&gt;&quot; &lt;<a href="mailto:[email-masked]">[email-masked]</a>&gt;<br>
<span style="font-weight:bold">Subject: </span>RE: [irs-discuss] Fwd: New Version Notification for draft-amante-irs-topology-use-cases-00.txt<br>
</div>
<div><br>
</div>
<blockquote id="MAC_OUTLOOK_ATTRIBUTION_BLOCKQUOTE" style="BORDER-LEFT: #b5c4df 5 solid; PADDING:0 0 0 5; MARGIN:0 0 0 5;">
<div xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<meta name="Generator" content="Microsoft Word 14 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
	{font-family:Wingdings;
	panose-1:5 0 0 0 0 0 0 0 0 0;}
@font-face
	{font-family:Wingdings;
	panose-1:5 0 0 0 0 0 0 0 0 0;}
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
p.MsoAcetate, li.MsoAcetate, div.MsoAcetate
	{mso-style-priority:99;
	mso-style-link:"Balloon Text Char";
	margin:0in;
	margin-bottom:.0001pt;
	font-size:8.0pt;
	font-family:"Tahoma","sans-serif";}
p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph
	{mso-style-priority:34;
	margin-top:0in;
	margin-right:0in;
	margin-bottom:0in;
	margin-left:.5in;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman","serif";}
span.apple-tab-span
	{mso-style-name:apple-tab-span;}
span.BalloonTextChar
	{mso-style-name:"Balloon Text Char";
	mso-style-priority:99;
	mso-style-link:"Balloon Text";
	font-family:"Tahoma","sans-serif";}
span.EmailStyle20
	{mso-style-type:personal;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
span.EmailStyle21
	{mso-style-type:personal-reply;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
.MsoChpDefault
	{mso-style-type:export-only;
	font-size:10.0pt;}
@page WordSection1
	{size:8.5in 11.0in;
	margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
	{page:WordSection1;}
/* List Definitions */
@list l0
	{mso-list-id:1995989403;
	mso-list-type:hybrid;
	mso-list-template-ids:-1578184424 67698689 67698691 67698693 67698689 67698691 67698693 67698689 67698691 67698693;}
@list l0:level1
	{mso-level-number-format:bullet;
	mso-level-text:\F0B7;
	mso-level-tab-stop:none;
	mso-level-number-position:left;
	text-indent:-.25in;
	font-family:Symbol;}
@list l0:level2
	{mso-level-number-format:bullet;
	mso-level-text:o;
	mso-level-tab-stop:none;
	mso-level-number-position:left;
	text-indent:-.25in;
	font-family:"Courier New";}
@list l0:level3
	{mso-level-number-format:bullet;
	mso-level-text:\F0A7;
	mso-level-tab-stop:none;
	mso-level-number-position:left;
	text-indent:-.25in;
	font-family:Wingdings;}
@list l0:level4
	{mso-level-number-format:bullet;
	mso-level-text:\F0B7;
	mso-level-tab-stop:none;
	mso-level-number-position:left;
	text-indent:-.25in;
	font-family:Symbol;}
@list l0:level5
	{mso-level-number-format:bullet;
	mso-level-text:o;
	mso-level-tab-stop:none;
	mso-level-number-position:left;
	text-indent:-.25in;
	font-family:"Courier New";}
@list l0:level6
	{mso-level-number-format:bullet;
	mso-level-text:\F0A7;
	mso-level-tab-stop:none;
	mso-level-number-position:left;
	text-indent:-.25in;
	font-family:Wingdings;}
@list l0:level7
	{mso-level-number-format:bullet;
	mso-level-text:\F0B7;
	mso-level-tab-stop:none;
	mso-level-number-position:left;
	text-indent:-.25in;
	font-family:Symbol;}
@list l0:level8
	{mso-level-number-format:bullet;
	mso-level-text:o;
	mso-level-tab-stop:none;
	mso-level-number-position:left;
	text-indent:-.25in;
	font-family:"Courier New";}
@list l0:level9
	{mso-level-number-format:bullet;
	mso-level-text:\F0A7;
	mso-level-tab-stop:none;
	mso-level-number-position:left;
	text-indent:-.25in;
	font-family:Wingdings;}
ol
	{margin-bottom:0in;}
ul
	{margin-bottom:0in;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
<div lang="EN-US" link="blue" vlink="purple">
<div class="WordSection1">
<p class="MsoNormal"><span style="font-size: 11pt; font-family: Calibri, sans-serif; color: rgb(31, 73, 125); ">Hi Tom,<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size: 11pt; font-family: Calibri, sans-serif; color: rgb(31, 73, 125); "><o:p>&nbsp;</o:p></span></p>
<p class="MsoNormal"><span style="font-size: 11pt; font-family: Calibri, sans-serif; color: rgb(31, 73, 125); ">Okay, I see. &nbsp;I think, it would be helpful to:<o:p></o:p></span></p>
<p class="MsoListParagraph" style="text-indent:-.25in;mso-list:l0 level1 lfo1"><!--[if !supportLists]--><span style="font-size: 11pt; color: rgb(31, 73, 125); "><span style="mso-list:Ignore">�<span style="font-style: normal; font-variant: normal; font-weight: normal; font-size: 7pt; line-height: normal; font-family: 'Times New Roman'; ">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</span></span></span><!--[endif]--><span style="font-size: 11pt; font-family: Calibri, sans-serif; color: rgb(31, 73, 125); ">Clarify the context of this example as currently it is a little unclear. For example, ROADM layer �active� topology would normally
 be �visible� to the IGP�s LSDB (i.e., IGPs with GMPLS extensions).<o:p></o:p></span></p>
<p class="MsoListParagraph" style="text-indent:-.25in;mso-list:l0 level1 lfo1"><!--[if !supportLists]--><span style="font-size: 11pt; color: rgb(31, 73, 125); "><span style="mso-list:Ignore">�<span style="font-style: normal; font-variant: normal; font-weight: normal; font-size: 7pt; line-height: normal; font-family: 'Times New Roman'; ">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</span></span></span><!--[endif]--><span style="font-size: 11pt; font-family: Calibri, sans-serif; color: rgb(31, 73, 125); ">Add few multi-layer topology examples and their use by network applications (e.g., what type of info one would like to reveal etc.).<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size: 11pt; font-family: Calibri, sans-serif; color: rgb(31, 73, 125); ">Thanks,<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size: 11pt; font-family: Calibri, sans-serif; color: rgb(31, 73, 125); ">Iftekhar<o:p></o:p></span></p>
<div>
<div style="border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b><span style="font-size: 10pt; font-family: Tahoma, sans-serif; ">From:</span></b><span style="font-size: 10pt; font-family: Tahoma, sans-serif; "> Thomas Nadeau [<a href="mailto:[email-masked]">mailto:[email-masked]</a>]
<br>
<b>Sent:</b> Monday, October 08, 2012 2:11 PM<br>
<b>To:</b> Iftekhar Hussain; &lt;<a href="mailto:[email-masked]">[email-masked]</a>&gt;<br>
<b>Subject:</b> Re: [irs-discuss] Fwd: New Version Notification for draft-amante-irs-topology-use-cases-00.txt<o:p></o:p></span></p>
</div>
</div>
<p class="MsoNormal"><o:p>&nbsp;</o:p></p>
<div>
<p class="MsoNormal"><span style="font-size: 10.5pt; font-family: Calibri, sans-serif; color: black; "><o:p>&nbsp;</o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size: 10.5pt; font-family: Calibri, sans-serif; color: black; ">Hi!<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size: 10.5pt; font-family: Calibri, sans-serif; color: black; "><o:p>&nbsp;</o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size: 10.5pt; font-family: Calibri, sans-serif; color: black; ">The IRS topology effort is&nbsp;not about what is visible to what devices per se; its about revealing different topological components in a normalized topology
 database. So in this example, capturing the active information (which is visible via LSDB/IGP routing protocols), is complimented with other inactive (or passive) topological components.&nbsp;<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size: 10.5pt; font-family: Calibri, sans-serif; color: black; "><o:p>&nbsp;</o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size: 10.5pt; font-family: Calibri, sans-serif; color: black; ">--Tom<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size: 10.5pt; font-family: Calibri, sans-serif; color: black; "><o:p>&nbsp;</o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size: 10.5pt; font-family: Calibri, sans-serif; color: black; "><o:p>&nbsp;</o:p></span></p>
</div>
<div style="border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b><span style="font-size: 11pt; font-family: Calibri, sans-serif; color: black; ">From:
</span></b><span style="font-size: 11pt; font-family: Calibri, sans-serif; color: black; ">Iftekhar Hussain &lt;<a href="mailto:[email-masked]">[email-masked]</a>&gt;<br>
<b>Date: </b>Sunday, October 7, 2012 6:00 PM<br>
<b>To: </b>&quot;&lt;<a href="mailto:[email-masked]">[email-masked]</a>&gt;&quot; &lt;<a href="mailto:[email-masked]">[email-masked]</a>&gt;<br>
<b>Subject: </b>Re: [irs-discuss] Fwd: New Version Notification for draft-amante-irs-topology-use-cases-00.txt<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size: 10.5pt; font-family: Calibri, sans-serif; color: black; "><o:p>&nbsp;</o:p></span></p>
</div>
<blockquote style="border:none;border-left:solid #B5C4DF 4.5pt;padding:0in 0in 0in 4.0pt;margin-left:3.75pt;margin-right:0in" id="MAC_OUTLOOK_ATTRIBUTION_BLOCKQUOTE">
<div>
<div>
<p class="MsoNormal" style="margin-bottom:12.0pt"><span style="color:black">Hi Authors,<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-bottom:12.0pt"><span style="color:black">��and visible within the Link State Database (LSDB) of an active IGP, but also network elements who are active, but invisible to a LSDB (e.g.: L2 Ethernet switches, ROADM's, etc.)�<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-bottom:12.0pt"><span style="color:black">Shouldn�t ROADMs topology be visible to IGP? Perhaps you intend to say optical line amplifier (OLA).<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-bottom:12.0pt"><span style="color:black">Regards,<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-bottom:12.0pt"><span style="color:black">Iftekhar<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-bottom:12.0pt"><span style="color:black">&nbsp;<o:p></o:p></span></p>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<div>
<p class="MsoNormal" style="margin-bottom:12.0pt"><span style="color:black">&nbsp;<o:p></o:p></span></p>
</div>
</blockquote>
</div>
</div>
</blockquote>
</div>
</div>
</div>
</blockquote>
</span>
</body>
</html>

--_000_CC98CC62FC18tnadeaujunipernet_--

From: Iftekhar Hussain <[email-masked]>
To: Thomas Nadeau <[email-masked]>, "<[email-masked]>" <[email-masked]>
Date: Mon, 8 Oct 2012 22:21:01 +0000
Accept-Language: en-US
Subject: Re: [irs-discuss] Fwd: New Version Notification for draft-amante-irs-topology-use-cases-00.txt

--_000_D7D7AB44C06A2440B716F1F1F5E70AE53F98363FSVEXDBPROD1infi_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi Tom,

Okay, I see.  I think, it would be helpful to:

*         Clarify the context of this example as currently it is a little unclear. For example, ROADM layer 'active' topology would normally be 'visible' to the IGP's LSDB (i.e., IGPs with GMPLS extensions).

*         Add few multi-layer topology examples and their use by network applications (e.g., what type of info one would like to reveal etc.).
Thanks,
Iftekhar
From: Thomas Nadeau [mailto:[email-masked]]
Sent: Monday, October 08, 2012 2:11 PM
To: Iftekhar Hussain; <[email-masked]>
Subject: Re: [irs-discuss] Fwd: New Version Notification for draft-amante-irs-topology-use-cases-00.txt

Hi!

The IRS topology effort is not about what is visible to what devices per se; its about revealing different topological components in a normalized topology database. So in this example, capturing the active information (which is visible via LSDB/IGP routing protocols), is complimented with other inactive (or passive) topological components.

--Tom

From: Iftekhar Hussain <[email-masked]<mailto:[email-masked]>>
Date: Sunday, October 7, 2012 6:00 PM
To: "<[email-masked]<mailto:[email-masked]>>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [irs-discuss] Fwd: New Version Notification for draft-amante-irs-topology-use-cases-00.txt

Hi Authors,
"...and visible within the Link State Database (LSDB) of an active IGP, but also network elements who are active, but invisible to a LSDB (e.g.: L2 Ethernet switches, ROADM's, etc.)"
Shouldn't ROADMs topology be visible to IGP? Perhaps you intend to say optical line amplifier (OLA).
Regards,
Iftekhar

--_000_D7D7AB44C06A2440B716F1F1F5E70AE53F98363FSVEXDBPROD1infi_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
<meta name="Generator" content="Microsoft Word 14 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
	{font-family:Wingdings;
	panose-1:5 0 0 0 0 0 0 0 0 0;}
@font-face
	{font-family:Wingdings;
	panose-1:5 0 0 0 0 0 0 0 0 0;}
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
p.MsoAcetate, li.MsoAcetate, div.MsoAcetate
	{mso-style-priority:99;
	mso-style-link:"Balloon Text Char";
	margin:0in;
	margin-bottom:.0001pt;
	font-size:8.0pt;
	font-family:"Tahoma","sans-serif";}
p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph
	{mso-style-priority:34;
	margin-top:0in;
	margin-right:0in;
	margin-bottom:0in;
	margin-left:.5in;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman","serif";}
span.apple-tab-span
	{mso-style-name:apple-tab-span;}
span.BalloonTextChar
	{mso-style-name:"Balloon Text Char";
	mso-style-priority:99;
	mso-style-link:"Balloon Text";
	font-family:"Tahoma","sans-serif";}
span.EmailStyle20
	{mso-style-type:personal;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
span.EmailStyle21
	{mso-style-type:personal-reply;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
.MsoChpDefault
	{mso-style-type:export-only;
	font-size:10.0pt;}
@page WordSection1
	{size:8.5in 11.0in;
	margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
	{page:WordSection1;}
/* List Definitions */
@list l0
	{mso-list-id:1995989403;
	mso-list-type:hybrid;
	mso-list-template-ids:-1578184424 67698689 67698691 67698693 67698689 67698691 67698693 67698689 67698691 67698693;}
@list l0:level1
	{mso-level-number-format:bullet;
	mso-level-text:\F0B7;
	mso-level-tab-stop:none;
	mso-level-number-position:left;
	text-indent:-.25in;
	font-family:Symbol;}
@list l0:level2
	{mso-level-number-format:bullet;
	mso-level-text:o;
	mso-level-tab-stop:none;
	mso-level-number-position:left;
	text-indent:-.25in;
	font-family:"Courier New";}
@list l0:level3
	{mso-level-number-format:bullet;
	mso-level-text:\F0A7;
	mso-level-tab-stop:none;
	mso-level-number-position:left;
	text-indent:-.25in;
	font-family:Wingdings;}
@list l0:level4
	{mso-level-number-format:bullet;
	mso-level-text:\F0B7;
	mso-level-tab-stop:none;
	mso-level-number-position:left;
	text-indent:-.25in;
	font-family:Symbol;}
@list l0:level5
	{mso-level-number-format:bullet;
	mso-level-text:o;
	mso-level-tab-stop:none;
	mso-level-number-position:left;
	text-indent:-.25in;
	font-family:"Courier New";}
@list l0:level6
	{mso-level-number-format:bullet;
	mso-level-text:\F0A7;
	mso-level-tab-stop:none;
	mso-level-number-position:left;
	text-indent:-.25in;
	font-family:Wingdings;}
@list l0:level7
	{mso-level-number-format:bullet;
	mso-level-text:\F0B7;
	mso-level-tab-stop:none;
	mso-level-number-position:left;
	text-indent:-.25in;
	font-family:Symbol;}
@list l0:level8
	{mso-level-number-format:bullet;
	mso-level-text:o;
	mso-level-tab-stop:none;
	mso-level-number-position:left;
	text-indent:-.25in;
	font-family:"Courier New";}
@list l0:level9
	{mso-level-number-format:bullet;
	mso-level-text:\F0A7;
	mso-level-tab-stop:none;
	mso-level-number-position:left;
	text-indent:-.25in;
	font-family:Wingdings;}
ol
	{margin-bottom:0in;}
ul
	{margin-bottom:0in;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang="EN-US" link="blue" vlink="purple">
<div class="WordSection1">
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D">Hi Tom,<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D"><o:p>&nbsp;</o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D">Okay, I see. &nbsp;I think, it would be helpful to:<o:p></o:p></span></p>
<p class="MsoListParagraph" style="text-indent:-.25in;mso-list:l0 level1 lfo1"><![if !supportLists]><span style="font-size:11.0pt;font-family:Symbol;color:#1F497D"><span style="mso-list:Ignore">&middot;<span style="font:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</span></span></span><![endif]><span style="font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D">Clarify the context of this example as currently it is a little unclear. For example, ROADM layer &#8216;active&#8217; topology would normally be &#8216;visible&#8217; to
 the IGP&#8217;s LSDB (i.e., IGPs with GMPLS extensions).<o:p></o:p></span></p>
<p class="MsoListParagraph" style="text-indent:-.25in;mso-list:l0 level1 lfo1"><![if !supportLists]><span style="font-size:11.0pt;font-family:Symbol;color:#1F497D"><span style="mso-list:Ignore">&middot;<span style="font:7.0pt &quot;Times New Roman&quot;">&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;
</span></span></span><![endif]><span style="font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D">Add few multi-layer topology examples and their use by network applications (e.g., what type of info one would like to reveal etc.).<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D">Thanks,<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:#1F497D">Iftekhar<o:p></o:p></span></p>
<div>
<div style="border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b><span style="font-size:10.0pt;font-family:&quot;Tahoma&quot;,&quot;sans-serif&quot;">From:</span></b><span style="font-size:10.0pt;font-family:&quot;Tahoma&quot;,&quot;sans-serif&quot;"> Thomas Nadeau [mailto:[email-masked]]
<br>
<b>Sent:</b> Monday, October 08, 2012 2:11 PM<br>
<b>To:</b> Iftekhar Hussain; &lt;[email-masked]&gt;<br>
<b>Subject:</b> Re: [irs-discuss] Fwd: New Version Notification for draft-amante-irs-topology-use-cases-00.txt<o:p></o:p></span></p>
</div>
</div>
<p class="MsoNormal"><o:p>&nbsp;</o:p></p>
<div>
<p class="MsoNormal"><span style="font-size:10.5pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:black"><o:p>&nbsp;</o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:10.5pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:black">Hi!<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:10.5pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:black"><o:p>&nbsp;</o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:10.5pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:black">The IRS topology effort is&nbsp;not about what is visible to what devices per se; its about revealing different topological components in a normalized topology database.
 So in this example, capturing the active information (which is visible via LSDB/IGP routing protocols), is complimented with other inactive (or passive) topological components.&nbsp;<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:10.5pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:black"><o:p>&nbsp;</o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:10.5pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:black">--Tom<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:10.5pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:black"><o:p>&nbsp;</o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:10.5pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:black"><o:p>&nbsp;</o:p></span></p>
</div>
<div style="border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b><span style="font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:black">From:
</span></b><span style="font-size:11.0pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:black">Iftekhar Hussain &lt;<a href="mailto:[email-masked]">[email-masked]</a>&gt;<br>
<b>Date: </b>Sunday, October 7, 2012 6:00 PM<br>
<b>To: </b>&quot;&lt;<a href="mailto:[email-masked]">[email-masked]</a>&gt;&quot; &lt;<a href="mailto:[email-masked]">[email-masked]</a>&gt;<br>
<b>Subject: </b>Re: [irs-discuss] Fwd: New Version Notification for draft-amante-irs-topology-use-cases-00.txt<o:p></o:p></span></p>
</div>
<div>
<p class="MsoNormal"><span style="font-size:10.5pt;font-family:&quot;Calibri&quot;,&quot;sans-serif&quot;;color:black"><o:p>&nbsp;</o:p></span></p>
</div>
<blockquote style="border:none;border-left:solid #B5C4DF 4.5pt;padding:0in 0in 0in 4.0pt;margin-left:3.75pt;margin-right:0in" id="MAC_OUTLOOK_ATTRIBUTION_BLOCKQUOTE">
<div>
<div>
<p class="MsoNormal" style="margin-bottom:12.0pt"><span style="color:black">Hi Authors,<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-bottom:12.0pt"><span style="color:black">&#8220;&#8230;and visible within the Link State Database (LSDB) of an active IGP, but also network elements who are active, but invisible to a LSDB (e.g.: L2 Ethernet switches, ROADM's, etc.)&#8221;<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-bottom:12.0pt"><span style="color:black">Shouldn&#8217;t ROADMs topology be visible to IGP? Perhaps you intend to say optical line amplifier (OLA).<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-bottom:12.0pt"><span style="color:black">Regards,<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-bottom:12.0pt"><span style="color:black">Iftekhar<o:p></o:p></span></p>
<p class="MsoNormal" style="margin-bottom:12.0pt"><span style="color:black">&nbsp;<o:p></o:p></span></p>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<div>
<p class="MsoNormal" style="margin-bottom:12.0pt"><span style="color:black">&nbsp;<o:p></o:p></span></p>
</div>
</blockquote>
</div>
</div>
</blockquote>
</div>
</body>
</html>

--_000_D7D7AB44C06A2440B716F1F1F5E70AE53F98363FSVEXDBPROD1infi_--

From: Thomas Nadeau <[email-masked]>
To: Iftekhar Hussain <[email-masked]>, "<[email-masked]>" <[email-masked]>
Date: Mon, 8 Oct 2012 21:10:33 +0000
Accept-Language: en-US
Subject: Re: [irs-discuss] Fwd: New Version Notification for draft-amante-irs-topology-use-cases-00.txt

--_000_CC98B91CFBF1tnadeaujunipernet_
Content-Type: text/plain; charset="Windows-1252"
Content-Transfer-Encoding: quoted-printable

Hi!

The IRS topology effort is not about what is visible to what devices per se; its about revealing different topological components in a normalized topology database. So in this example, capturing the active information (which is visible via LSDB/IGP routing protocols), is complimented with other inactive (or passive) topological components.

--Tom

From: Iftekhar Hussain <[email-masked]<mailto:[email-masked]>>
Date: Sunday, October 7, 2012 6:00 PM
To: "<[email-masked]<mailto:[email-masked]>>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [irs-discuss] Fwd: New Version Notification for draft-amante-irs-topology-use-cases-00.txt

Hi Authors,
��and visible within the Link State Database (LSDB) of an active IGP, but also network elements who are active, but invisible to a LSDB (e.g.: L2 Ethernet switches, ROADM's, etc.)�
Shouldn�t ROADMs topology be visible to IGP? Perhaps you intend to say optical line amplifier (OLA).
Regards,
Iftekhar

--_000_CC98B91CFBF1tnadeaujunipernet_
Content-Type: text/html; charset="Windows-1252"
Content-ID: <[email-masked]>
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=Windows-1252">
</head>
<body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; color: rgb(0, 0, 0); font-size: 14px; font-family: Calibri, sans-serif; ">
<div><br>
</div>
<div><span class="Apple-tab-span" style="white-space:pre"></span>Hi!</div>
<div><br>
</div>
<div><span class="Apple-tab-span" style="white-space:pre"></span>The IRS topology effort is&nbsp;not about what is visible to what devices per se; its about revealing different topological components in a normalized topology database. So in this example, capturing
 the active information (which is visible via LSDB/IGP routing protocols), is complimented with other inactive (or passive) topological components.&nbsp;</div>
<div><br>
</div>
<div><span class="Apple-tab-span" style="white-space:pre"></span>--Tom</div>
<div><br>
</div>
<div><br>
</div>
<span id="OLK_SRC_BODY_SECTION">
<div style="font-family:Calibri; font-size:11pt; text-align:left; color:black; BORDER-BOTTOM: medium none; BORDER-LEFT: medium none; PADDING-BOTTOM: 0in; PADDING-LEFT: 0in; PADDING-RIGHT: 0in; BORDER-TOP: #b5c4df 1pt solid; BORDER-RIGHT: medium none; PADDING-TOP: 3pt">
<span style="font-weight:bold">From: </span>Iftekhar Hussain &lt;<a href="mailto:[email-masked]">[email-masked]</a>&gt;<br>
<span style="font-weight:bold">Date: </span>Sunday, October 7, 2012 6:00 PM<br>
<span style="font-weight:bold">To: </span>&quot;&lt;<a href="mailto:[email-masked]">[email-masked]</a>&gt;&quot; &lt;<a href="mailto:[email-masked]">[email-masked]</a>&gt;<br>
<span style="font-weight:bold">Subject: </span>Re: [irs-discuss] Fwd: New Version Notification for draft-amante-irs-topology-use-cases-00.txt<br>
</div>
<div><br>
</div>
<blockquote id="MAC_OUTLOOK_ATTRIBUTION_BLOCKQUOTE" style="BORDER-LEFT: #b5c4df 5 solid; PADDING:0 0 0 5; MARGIN:0 0 0 5;">
<div xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<meta name="Generator" content="Microsoft Word 14 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
p.MsoAcetate, li.MsoAcetate, div.MsoAcetate
	{mso-style-priority:99;
	mso-style-link:"Balloon Text Char";
	margin:0in;
	margin-bottom:.0001pt;
	font-size:8.0pt;
	font-family:"Tahoma","sans-serif";}
span.BalloonTextChar
	{mso-style-name:"Balloon Text Char";
	mso-style-priority:99;
	mso-style-link:"Balloon Text";
	font-family:"Tahoma","sans-serif";}
span.EmailStyle19
	{mso-style-type:personal-reply;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
.MsoChpDefault
	{mso-style-type:export-only;
	font-size:10.0pt;}
@page WordSection1
	{size:8.5in 11.0in;
	margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
	{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
<div lang="EN-US" link="blue" vlink="purple">
<div class="WordSection1">
<p class="MsoNormal" style="margin-bottom:12.0pt">Hi Authors,<o:p></o:p></p>
<p class="MsoNormal" style="margin-bottom:12.0pt">��and visible within the Link State Database (LSDB) of an active IGP, but also network elements who are active, but invisible to a LSDB (e.g.: L2 Ethernet switches, ROADM's, etc.)�<o:p></o:p></p>
<p class="MsoNormal" style="margin-bottom:12.0pt">Shouldn�t ROADMs topology be visible to IGP? Perhaps you intend to say optical line amplifier (OLA).<o:p></o:p></p>
<p class="MsoNormal" style="margin-bottom:12.0pt">Regards,<o:p></o:p></p>
<p class="MsoNormal" style="margin-bottom:12.0pt">Iftekhar<o:p></o:p></p>
<p class="MsoNormal" style="margin-bottom:12.0pt"><o:p>&nbsp;</o:p></p>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<div>
<p class="MsoNormal" style="margin-bottom:12.0pt"><o:p>&nbsp;</o:p></p>
</div>
</blockquote>
</div>
</div>
</div>
</blockquote>
</span>
</body>
</html>

--_000_CC98B91CFBF1tnadeaujunipernet_--

From: Iftekhar Hussain <[email-masked]>
To: "<[email-masked]>" <[email-masked]>
Date: Sun, 7 Oct 2012 22:00:14 +0000
Accept-Language: en-US
Subject: Re: [irs-discuss] Fwd: New Version Notification	for	draft-amante-irs-topology-use-cases-00.txt

--_000_D7D7AB44C06A2440B716F1F1F5E70AE53F9833F7SVEXDBPROD1infi_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Hi Authors,
"...and visible within the Link State Database (LSDB) of an active IGP, but also network elements who are active, but invisible to a LSDB (e.g.: L2 Ethernet switches, ROADM's, etc.)"
Shouldn't ROADMs topology be visible to IGP? Perhaps you intend to say optical line amplifier (OLA).
Regards,
Iftekhar

--_000_D7D7AB44C06A2440B716F1F1F5E70AE53F9833F7SVEXDBPROD1infi_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
<meta name="Generator" content="Microsoft Word 14 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0in;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
p.MsoAcetate, li.MsoAcetate, div.MsoAcetate
	{mso-style-priority:99;
	mso-style-link:"Balloon Text Char";
	margin:0in;
	margin-bottom:.0001pt;
	font-size:8.0pt;
	font-family:"Tahoma","sans-serif";}
span.BalloonTextChar
	{mso-style-name:"Balloon Text Char";
	mso-style-priority:99;
	mso-style-link:"Balloon Text";
	font-family:"Tahoma","sans-serif";}
span.EmailStyle19
	{mso-style-type:personal-reply;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
.MsoChpDefault
	{mso-style-type:export-only;
	font-size:10.0pt;}
@page WordSection1
	{size:8.5in 11.0in;
	margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
	{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang="EN-US" link="blue" vlink="purple">
<div class="WordSection1">
<p class="MsoNormal" style="margin-bottom:12.0pt">Hi Authors,<o:p></o:p></p>
<p class="MsoNormal" style="margin-bottom:12.0pt">&#8220;&#8230;and visible within the Link State Database (LSDB) of an active IGP, but also network elements who are active, but invisible to a LSDB (e.g.: L2 Ethernet switches, ROADM's, etc.)&#8221;<o:p></o:p></p>
<p class="MsoNormal" style="margin-bottom:12.0pt">Shouldn&#8217;t ROADMs topology be visible to IGP? Perhaps you intend to say optical line amplifier (OLA).<o:p></o:p></p>
<p class="MsoNormal" style="margin-bottom:12.0pt">Regards,<o:p></o:p></p>
<p class="MsoNormal" style="margin-bottom:12.0pt">Iftekhar<o:p></o:p></p>
<p class="MsoNormal" style="margin-bottom:12.0pt"><o:p>&nbsp;</o:p></p>
<blockquote style="margin-top:5.0pt;margin-bottom:5.0pt">
<div>
<p class="MsoNormal" style="margin-bottom:12.0pt"><o:p>&nbsp;</o:p></p>
</div>
</blockquote>
</div>
</body>
</html>

--_000_D7D7AB44C06A2440B716F1F1F5E70AE53F9833F7SVEXDBPROD1infi_--

Date: Thu, 04 Oct 2012 00:24:38 -0400
From: "Joel M. Halpern" <[email-masked]>
To: Shane Amante <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [irs-discuss] Comments on Topology API use case document

I agreethat we need to look at using existing protocols / mechaisms.
My concern is merely that the wording in the raft, in trying to raise 
that, describes using existing configuration protocols and direct 
manipulation of the routing protocol internals.  There are significantly 
more alternatives, both i the extant category and in the new category.

Hence, I am merely asking that the use case not get cluttered with text 
on the specifics.  (All solving this takes is removing one or two 
sentences.)

Yours,
Joel

On 10/3/2012 11:46 PM, Shane Amante wrote:
> Hi Joel,
>
> On Oct 3, 2012, at 7:36 AM, Joel M. Halpern <[email-masked]> wrote:
>> Thanks for the prompt and helpful response Shane.
>>
>> With regard to the hierarchical topology model, I strongly agree that we need a model that supports hierarchy / layering / service dependence.
>> My concern is that the text currently says that the ISO layers are a good starting point for this.  As far as I can tell, the ISO model is a very bad pace o start developing such a model.
>
> OK; however, we need some way to address it.  I'd welcome your and others opinions on a better alternative.
>
>
>> With regard to the configuration protocol, the text talks about injecting information into the routing protocol instance, or using the existing configuration tools.  Other drafts have talked about the IRS agent as a new channel, which provides a similar but distinguished set of configuration.  There have also been discussions of how information gets intoIGPs (directly telling the GP to emit a route vs configuring a class of static route and having it imported.)  It seems to methat this is an important area, with much work to be done.  Thus, it seems simpler if this draft simply said it would use IRS related confiuration mechanisms to make its changes, and did not try to categorize or approximate those.
>
> Actually, before submitting the draft we (co-authors) had been having a debate on this very subject.  I think this will be an area of "lively" discussion, both on the mailing list and in-person.
>
> Ultimately, there's likely several dimensions we need to evaluate to determine what the possibly-to-be-formed IRS WG will work on, what other (existing) IETF WG's will work on, what _already_exists_ by other IETF WG's that can get re-used, etc.  With respect to the latter, we tried to recognize that "IRS" does not have to solve for every single use case.  Rather, there are likely classes of use cases where existing (IETF) protocols are more than adequate to fulfill that need -- some immediate examples that comes to mind are: NETCONF & YANG.  These protocols seem adequate for use cases where there is no requirement for (near-)real-time communication/transactions, there is not a substantial concern about on-the-wire-overhead, etc.  Example use cases in this draft that may fit this criteria are: Cap Planning and Traffic Engineering, assuming their intervals are defined in terms of hours or longer.  That said, there still is a critical need to recognize that these use cases cou
 ld use 
NETCONF/YANG, *but* we need to "encourage" the work to define an appropriate data-model within, probably, NETMOD to carry/exchange the required set of information to/from NE's.  Likewise, there's also a need to have a data-model that can work from the Topology Manager to/from the Applications/Client that consume this information.  With respect to the latter, is that something that the maybe to-be-formed IRS WG will get tasked with?  Or, is there another WG already set-up to do this?  If not, can we possibly consider re-chartering an existing WG to do this ... even if the WG doesn't exist in the Routing Area?
>
> OTOH, where there is a critical requirement for (near-)real-time communication, that's where things get more interesting.  As has been pointed out in the past, there was /a lot/ of discussion on the need for a "streaming interface" -- however, the conversation got muddy & stalled out, seemingly because there was an assertion on the need for such a thing, but not the use cases and articulation of what is required in a "streaming interface".  IMO, I think that this draft, and others, are hopefully bringing more light to specific use cases to help move the conversation forward.  In particular, I think some use cases that are definitely in this category of requiring (near-)real-time communication is: detecting & mitigating DDoS attacks, reactionary Traffic Engineering (i.e.: due to unplanned events), etc. through IRS.  I'm sure others can add more to that list.
>
> Anyway, I hope this helps shed light on why we've chosen, for now, to try to articulate that there may be existing mechanisms/protocols that *could* be used to solve *some* of these use cases, but that more work still needs to be done (i.e.: defining data-models) and we should discuss whether to do that work and, of course, where.  Obviously, for those use cases that require (near-)real-time communication, and possibly other requirements that can't be accommodated by today's protocols, that will likely lead to a more focused set of requirements, etc. that will drive a set of short-term deliverables for maybe-to-be-formed IRS WG ...
>
> Thanks,
>
> -shane
>
>
>>
>> Yours,
>> Joel
>>
>> On 10/3/2012 12:56 AM, Shane Amante wrote:
>>> Hi Joel,
>>>
>>> Thanks for your review.  Please see below.
>>>
>>> On Oct 2, 2012, at 8:38 PM, Joel M. Halpern <[email-masked]> wrote:
>>>> Overall, this looks very helpful.
>>>>
>>>> In the terminology section, two things struck me:
>>>> First, we probably need to consistently qualify the term "Policy Manager".  What is described in this document as the "Policy Manager" is a very interesting and powerful function.  it is a policy function.  But it is no more the entire policy manager than a security policy manager is the entire policy manager.  It seems to me that this is a discipline we need to acquire early, or we will forever find ourselves arguing about the meaning of terms when we actually agree.  (The later description of the Policy Manager edges into the broader perspective, but isn't really the same.)
>>>
>>> We'll look at making the text in terminology section better align with the broader definition of a Policy Manager in Section 3.3.
>>>
>>> Indeed, a "Policy Management" function is indeed critical.  Arguably, it's in the top two most critical elements of this work, IMO.  And, you're right that we need to align on definitions for what it is for fear or forever qualifying it.  The reason we chose "Policy Manager" is that it seemed the closest match to what are (likely) considered routine functions in networking today, namely, "routing policies" (cf: BGP), "security policies" (cf: ACL preventing/allowing packets through), etc.  Is that part clear?  Note, at this stage, we're depicting this as a single "Policy Manager" function; however, if this work evolves it's likely this will get broken down into sub-components (security, routing, etc.) to more precisely define their domain-specific attributes.
>>>
>>>
>>>> I have to disagree with the definition of Multi-Layer Topology.  I agree that topologies are layered.  However, the OSI topology abstraction is absolutely wrong.  As was pointed out to me many years ago, and has become more prevalent ever sine, w run L2 VPN services on MPLS infrastructure on IP infrastructure, which is in term supported by Ethernet, some which may actually be emulated Ethernet on MPLS on ...
>>>
>>> Hrm.  Ultimately, what I think you're describe is a perfect example of building a specific hierarchical network.  The problem is, today, we *DO NOT* have any (standards-based) way to represent the reality of those hierarchical relationships /outside of/ the data-plane and control-plane[1].  Over the years, we've clearly engineered such hierarchy directly into the routing (and, forwarding) planes of network equipment.  In addition, we've barely enumerated some attributes of *individual* protocols or network components, (cf: SNMP MIB's), but they are entirely /standalone/.  Instead, we need to take the next step.  Specifically, we need to fully enumerate attributes and, more importantly, metadata of individual control & data-plane protocols (and, related network components) using a common, standards-based *vocabulary*.  Only once we do that will it be possible to:
>>> a) Define hierarchical relationships between network components (protocols, services, etc.), using the aforementioned attributes/metadata as filtering/selection criteria, as appropriate; and,
>>> b) Summarize all of this vocabulary into schemas/data-models that can then be exchanged between systems that *DO NOT* (cannot *and* will not) directly participate in routing & forwarding.
>>> Ultimately, this is the core essence of SDN/IRS.
>>>
>>> [1] BGP recursing to an IGP for next-hop; LDP relying on IGP to determine shortest-path, etc.
>>>
>>>
>>>> While I appreciate the importance of the Inventory function in evaluating SRLGs, I think the document should probably point out that this often depends upon physical realities not visible to any automated system.  (The number of stories of operators failing to meet diversity guarantees are legion.)
>>>
>>> Really!?!?  ;-)
>>>
>>> More seriously, I thought this was made clear in the first two paragraphs of Section 4.1.1, "Capacity Planning and Traffic Engineering":
>>> ---snip---
>>>     [...] Due to this inefficiency, the
>>>     underlying physical network inventory information, (containing SRLG
>>>     and corresponding critical network asset information), used by the
>>>     IP/MPLS Capacity Planning and TE applications is not updated
>>>     frequently, thus exposing the network to, at minimum, inefficient
>>>     utilization and, at worst, critical impairments.
>>> ---snip---
>>>
>>>
>>>> I find it strange that this draft describes change application using a different paradigm than the other IRS drafts.  Is this deliberate, indicating that these use cases need a different mechanism than is elsewhere described?  (I wold have simply indicated that the Topology manager will need to apply changes, and left it there as far as this document is concerned.
>>>
>>> I'm not sure I understand the above comment.  Can you elaborate?
>>>
>>> -shane
>>> _______________________________________________
>>> irs-discuss mailing list
>>> [email-masked]
>>> https://www.ietf.org/mailman/listinfo/irs-discuss
>>>
>>
>
>

From: Shane Amante <[email-masked]>
Date: Wed, 3 Oct 2012 21:46:16 -0600
To: Joel M. Halpern <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [irs-discuss] Comments on Topology API use case document

Hi Joel,

On Oct 3, 2012, at 7:36 AM, Joel M. Halpern <[email-masked]> wrote:
> Thanks for the prompt and helpful response Shane.
> 
> With regard to the hierarchical topology model, I strongly agree that we need a model that supports hierarchy / layering / service dependence.
> My concern is that the text currently says that the ISO layers are a good starting point for this.  As far as I can tell, the ISO model is a very bad pace o start developing such a model.

OK; however, we need some way to address it.  I'd welcome your and others opinions on a better alternative.

> With regard to the configuration protocol, the text talks about injecting information into the routing protocol instance, or using the existing configuration tools.  Other drafts have talked about the IRS agent as a new channel, which provides a similar but distinguished set of configuration.  There have also been discussions of how information gets intoIGPs (directly telling the GP to emit a route vs configuring a class of static route and having it imported.)  It seems to methat this is an important area, with much work to be done.  Thus, it seems simpler if this draft simply said it would use IRS related confiuration mechanisms to make its changes, and did not try to categorize or approximate those.

Actually, before submitting the draft we (co-authors) had been having a debate on this very subject.  I think this will be an area of "lively" discussion, both on the mailing list and in-person.

Ultimately, there's likely several dimensions we need to evaluate to determine what the possibly-to-be-formed IRS WG will work on, what other (existing) IETF WG's will work on, what _already_exists_ by other IETF WG's that can get re-used, etc.  With respect to the latter, we tried to recognize that "IRS" does not have to solve for every single use case.  Rather, there are likely classes of use cases where existing (IETF) protocols are more than adequate to fulfill that need -- some immediate examples that comes to mind are: NETCONF & YANG.  These protocols seem adequate for use cases where there is no requirement for (near-)real-time communication/transactions, there is not a substantial concern about on-the-wire-overhead, etc.  Example use cases in this draft that may fit this criteria are: Cap Planning and Traffic Engineering, assuming their intervals are defined in terms of hours or longer.  That said, there still is a critical need to recognize that these use cases could use NETCONF/YANG, *but* we need to "encourage" the work to define an appropriate data-model within, probably, NETMOD to carry/exchange the required set of information to/from NE's.  Likewise, there's also a need to have a data-model that can work from the Topology Manager to/from the Applications/Client that consume this information.  With respect to the latter, is that something that the maybe to-be-formed IRS WG will get tasked with?  Or, is there another WG already set-up to do this?  If not, can we possibly consider re-chartering an existing WG to do this ... even if the WG doesn't exist in the Routing Area?

OTOH, where there is a critical requirement for (near-)real-time communication, that's where things get more interesting.  As has been pointed out in the past, there was /a lot/ of discussion on the need for a "streaming interface" -- however, the conversation got muddy & stalled out, seemingly because there was an assertion on the need for such a thing, but not the use cases and articulation of what is required in a "streaming interface".  IMO, I think that this draft, and others, are hopefully bringing more light to specific use cases to help move the conversation forward.  In particular, I think some use cases that are definitely in this category of requiring (near-)real-time communication is: detecting & mitigating DDoS attacks, reactionary Traffic Engineering (i.e.: due to unplanned events), etc. through IRS.  I'm sure others can add more to that list.

Anyway, I hope this helps shed light on why we've chosen, for now, to try to articulate that there may be existing mechanisms/protocols that *could* be used to solve *some* of these use cases, but that more work still needs to be done (i.e.: defining data-models) and we should discuss whether to do that work and, of course, where.  Obviously, for those use cases that require (near-)real-time communication, and possibly other requirements that can't be accommodated by today's protocols, that will likely lead to a more focused set of requirements, etc. that will drive a set of short-term deliverables for maybe-to-be-formed IRS WG ...

Thanks,

-shane

> 
> Yours,
> Joel
> 
> On 10/3/2012 12:56 AM, Shane Amante wrote:
>> Hi Joel,
>> 
>> Thanks for your review.  Please see below.
>> 
>> On Oct 2, 2012, at 8:38 PM, Joel M. Halpern <[email-masked]> wrote:
>>> Overall, this looks very helpful.
>>> 
>>> In the terminology section, two things struck me:
>>> First, we probably need to consistently qualify the term "Policy Manager".  What is described in this document as the "Policy Manager" is a very interesting and powerful function.  it is a policy function.  But it is no more the entire policy manager than a security policy manager is the entire policy manager.  It seems to me that this is a discipline we need to acquire early, or we will forever find ourselves arguing about the meaning of terms when we actually agree.  (The later description of the Policy Manager edges into the broader perspective, but isn't really the same.)
>> 
>> We'll look at making the text in terminology section better align with the broader definition of a Policy Manager in Section 3.3.
>> 
>> Indeed, a "Policy Management" function is indeed critical.  Arguably, it's in the top two most critical elements of this work, IMO.  And, you're right that we need to align on definitions for what it is for fear or forever qualifying it.  The reason we chose "Policy Manager" is that it seemed the closest match to what are (likely) considered routine functions in networking today, namely, "routing policies" (cf: BGP), "security policies" (cf: ACL preventing/allowing packets through), etc.  Is that part clear?  Note, at this stage, we're depicting this as a single "Policy Manager" function; however, if this work evolves it's likely this will get broken down into sub-components (security, routing, etc.) to more precisely define their domain-specific attributes.
>> 
>> 
>>> I have to disagree with the definition of Multi-Layer Topology.  I agree that topologies are layered.  However, the OSI topology abstraction is absolutely wrong.  As was pointed out to me many years ago, and has become more prevalent ever sine, w run L2 VPN services on MPLS infrastructure on IP infrastructure, which is in term supported by Ethernet, some which may actually be emulated Ethernet on MPLS on ...
>> 
>> Hrm.  Ultimately, what I think you're describe is a perfect example of building a specific hierarchical network.  The problem is, today, we *DO NOT* have any (standards-based) way to represent the reality of those hierarchical relationships /outside of/ the data-plane and control-plane[1].  Over the years, we've clearly engineered such hierarchy directly into the routing (and, forwarding) planes of network equipment.  In addition, we've barely enumerated some attributes of *individual* protocols or network components, (cf: SNMP MIB's), but they are entirely /standalone/.  Instead, we need to take the next step.  Specifically, we need to fully enumerate attributes and, more importantly, metadata of individual control & data-plane protocols (and, related network components) using a common, standards-based *vocabulary*.  Only once we do that will it be possible to:
>> a) Define hierarchical relationships between network components (protocols, services, etc.), using the aforementioned attributes/metadata as filtering/selection criteria, as appropriate; and,
>> b) Summarize all of this vocabulary into schemas/data-models that can then be exchanged between systems that *DO NOT* (cannot *and* will not) directly participate in routing & forwarding.
>> Ultimately, this is the core essence of SDN/IRS.
>> 
>> [1] BGP recursing to an IGP for next-hop; LDP relying on IGP to determine shortest-path, etc.
>> 
>> 
>>> While I appreciate the importance of the Inventory function in evaluating SRLGs, I think the document should probably point out that this often depends upon physical realities not visible to any automated system.  (The number of stories of operators failing to meet diversity guarantees are legion.)
>> 
>> Really!?!?  ;-)
>> 
>> More seriously, I thought this was made clear in the first two paragraphs of Section 4.1.1, "Capacity Planning and Traffic Engineering":
>> ---snip---
>>    [...] Due to this inefficiency, the
>>    underlying physical network inventory information, (containing SRLG
>>    and corresponding critical network asset information), used by the
>>    IP/MPLS Capacity Planning and TE applications is not updated
>>    frequently, thus exposing the network to, at minimum, inefficient
>>    utilization and, at worst, critical impairments.
>> ---snip---
>> 
>> 
>>> I find it strange that this draft describes change application using a different paradigm than the other IRS drafts.  Is this deliberate, indicating that these use cases need a different mechanism than is elsewhere described?  (I wold have simply indicated that the Topology manager will need to apply changes, and left it there as far as this document is concerned.
>> 
>> I'm not sure I understand the above comment.  Can you elaborate?
>> 
>> -shane
>> _______________________________________________
>> irs-discuss mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/irs-discuss
>> 
> 

Date: Wed, 03 Oct 2012 09:36:49 -0400
From: "Joel M. Halpern" <[email-masked]>
To: Shane Amante <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [irs-discuss] Comments on Topology API use case document

Thanks for the prompt and helpful response Shane.

With regard to the hierarchical topology model, I strongly agree that we 
need a model that supports hierarchy / layering / service dependence.
My concern is that the text currently says that the ISO layers are a 
good starting point for this.  As far as I can tell, the ISO model is a 
very bad pace o start developing such a model.

With regard to the configuration protocol, the text talks about 
injecting information into the routing protocol instance, or using the 
existing configuration tools.  Other drafts have talked about the IRS 
agent as a new channel, which provides a similar but distinguished set 
of configuration.  There have also been discussions of how information 
gets intoIGPs (directly telling the GP to emit a route vs configuring a 
class of static route and having it imported.)  It seems to methat this 
is an important area, with much work to be done.  Thus, it seems simpler 
if this draft simply said it would use IRS related confiuration 
mechanisms to make its changes, and did not try to categorize or 
approximate those.

Yours,
Joel

On 10/3/2012 12:56 AM, Shane Amante wrote:
> Hi Joel,
>
> Thanks for your review.  Please see below.
>
> On Oct 2, 2012, at 8:38 PM, Joel M. Halpern <[email-masked]> wrote:
>> Overall, this looks very helpful.
>>
>> In the terminology section, two things struck me:
>> First, we probably need to consistently qualify the term "Policy Manager".  What is described in this document as the "Policy Manager" is a very interesting and powerful function.  it is a policy function.  But it is no more the entire policy manager than a security policy manager is the entire policy manager.  It seems to me that this is a discipline we need to acquire early, or we will forever find ourselves arguing about the meaning of terms when we actually agree.  (The later description of the Policy Manager edges into the broader perspective, but isn't really the same.)
>
> We'll look at making the text in terminology section better align with the broader definition of a Policy Manager in Section 3.3.
>
> Indeed, a "Policy Management" function is indeed critical.  Arguably, it's in the top two most critical elements of this work, IMO.  And, you're right that we need to align on definitions for what it is for fear or forever qualifying it.  The reason we chose "Policy Manager" is that it seemed the closest match to what are (likely) considered routine functions in networking today, namely, "routing policies" (cf: BGP), "security policies" (cf: ACL preventing/allowing packets through), etc.  Is that part clear?  Note, at this stage, we're depicting this as a single "Policy Manager" function; however, if this work evolves it's likely this will get broken down into sub-components (security, routing, etc.) to more precisely define their domain-specific attributes.
>
>
>> I have to disagree with the definition of Multi-Layer Topology.  I agree that topologies are layered.  However, the OSI topology abstraction is absolutely wrong.  As was pointed out to me many years ago, and has become more prevalent ever sine, w run L2 VPN services on MPLS infrastructure on IP infrastructure, which is in term supported by Ethernet, some which may actually be emulated Ethernet on MPLS on ...
>
> Hrm.  Ultimately, what I think you're describe is a perfect example of building a specific hierarchical network.  The problem is, today, we *DO NOT* have any (standards-based) way to represent the reality of those hierarchical relationships /outside of/ the data-plane and control-plane[1].  Over the years, we've clearly engineered such hierarchy directly into the routing (and, forwarding) planes of network equipment.  In addition, we've barely enumerated some attributes of *individual* protocols or network components, (cf: SNMP MIB's), but they are entirely /standalone/.  Instead, we need to take the next step.  Specifically, we need to fully enumerate attributes and, more importantly, metadata of individual control & data-plane protocols (and, related network components) using a common, standards-based *vocabulary*.  Only once we do that will it be possible to:
> a) Define hierarchical relationships between network components (protocols, services, etc.), using the aforementioned attributes/metadata as filtering/selection criteria, as appropriate; and,
> b) Summarize all of this vocabulary into schemas/data-models that can then be exchanged between systems that *DO NOT* (cannot *and* will not) directly participate in routing & forwarding.
> Ultimately, this is the core essence of SDN/IRS.
>
> [1] BGP recursing to an IGP for next-hop; LDP relying on IGP to determine shortest-path, etc.
>
>
>> While I appreciate the importance of the Inventory function in evaluating SRLGs, I think the document should probably point out that this often depends upon physical realities not visible to any automated system.  (The number of stories of operators failing to meet diversity guarantees are legion.)
>
> Really!?!?  ;-)
>
> More seriously, I thought this was made clear in the first two paragraphs of Section 4.1.1, "Capacity Planning and Traffic Engineering":
> ---snip---
>     [...] Due to this inefficiency, the
>     underlying physical network inventory information, (containing SRLG
>     and corresponding critical network asset information), used by the
>     IP/MPLS Capacity Planning and TE applications is not updated
>     frequently, thus exposing the network to, at minimum, inefficient
>     utilization and, at worst, critical impairments.
> ---snip---
>
>
>> I find it strange that this draft describes change application using a different paradigm than the other IRS drafts.  Is this deliberate, indicating that these use cases need a different mechanism than is elsewhere described?  (I wold have simply indicated that the Topology manager will need to apply changes, and left it there as far as this document is concerned.
>
> I'm not sure I understand the above comment.  Can you elaborate?
>
> -shane
> _______________________________________________
> irs-discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/irs-discuss
>

From: "Sadler, Jonathan B." <[email-masked]>
To: Shane Amante <[email-masked]>, Joel M.Halpern <[email-masked]>
Date: Wed, 3 Oct 2012 07:49:21 -0500
Accept-Language: en-US
acceptlanguage: en-US
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [irs-discuss] Comments on Topology API use case document

Shane, Joel, et al -

You may be interested in modeling work that was done at ITU-T discussing multi-layer topology relationships.  The specific document to look at is G.800 (2012): Unified Functional Architecture of Transport Networks. (http://www.itu.int/rec/T-REC-G.800)

The specific component in this approach to describing networks that describes multi-layer topology relationships is the Transitional Link.  See Section 6.2.1.

There was a liaison sent from ITU-T SG 15 to CCAMP that described how this topological component can be used in multi-layer ODU networks.  Please see SG15 LS221 - Examples of the use of Transitional Links (ITU-T G.709) (https://datatracker.ietf.org/liaison/953/).

>From this, work has been started on how a transitional link can be represented in link-state routing protocols thereby providing detail of the hierarchical relationships to path computation entities.

I see strong value in including this in IRS style applications as it enables the entity interested in topology to be able to understand all of the details where the service provider wishes it to be known (i.e. subject to policy controls).

Jonathan Sadler

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Shane Amante
Sent: Tuesday, October 02, 2012 11:57 PM
To: Joel M.Halpern
Cc: [email-masked]
Subject: Re: [irs-discuss] Comments on Topology API use case document

Hi Joel,

Thanks for your review.  Please see below.

On Oct 2, 2012, at 8:38 PM, Joel M. Halpern <[email-masked]> wrote:
> Overall, this looks very helpful.
>
> In the terminology section, two things struck me:
> First, we probably need to consistently qualify the term "Policy Manager".  What is described in this document as the "Policy Manager" is a very interesting and powerful function.  it is a policy function.  But it is no more the entire policy manager than a security policy manager is the entire policy manager.  It seems to me that this is a discipline we need to acquire early, or we will forever find ourselves arguing about the meaning of terms when we actually agree.  (The later description of the Policy Manager edges into the broader perspective, but isn't really the same.)

We'll look at making the text in terminology section better align with the broader definition of a Policy Manager in Section 3.3.

Indeed, a "Policy Management" function is indeed critical.  Arguably, it's in the top two most critical elements of this work, IMO.  And, you're right that we need to align on definitions for what it is for fear or forever qualifying it.  The reason we chose "Policy Manager" is that it seemed the closest match to what are (likely) considered routine functions in networking today, namely, "routing policies" (cf: BGP), "security policies" (cf: ACL preventing/allowing packets through), etc.  Is that part clear?  Note, at this stage, we're depicting this as a single "Policy Manager" function; however, if this work evolves it's likely this will get broken down into sub-components (security, routing, etc.) to more precisely define their domain-specific attributes.

> I have to disagree with the definition of Multi-Layer Topology.  I agree that topologies are layered.  However, the OSI topology abstraction is absolutely wrong.  As was pointed out to me many years ago, and has become more prevalent ever sine, w run L2 VPN services on MPLS infrastructure on IP infrastructure, which is in term supported by Ethernet, some which may actually be emulated Ethernet on MPLS on ...

Hrm.  Ultimately, what I think you're describe is a perfect example of building a specific hierarchical network.  The problem is, today, we *DO NOT* have any (standards-based) way to represent the reality of those hierarchical relationships /outside of/ the data-plane and control-plane[1].  Over the years, we've clearly engineered such hierarchy directly into the routing (and, forwarding) planes of network equipment.  In addition, we've barely enumerated some attributes of *individual* protocols or network components, (cf: SNMP MIB's), but they are entirely /standalone/.  Instead, we need to take the next step.  Specifically, we need to fully enumerate attributes and, more importantly, metadata of individual control & data-plane protocols (and, related network components) using a common, standards-based *vocabulary*.  Only once we do that will it be possible to:
a) Define hierarchical relationships between network components (protocols, services, etc.), using the aforementioned attributes/metadata as filtering/selection criteria, as appropriate; and,
b) Summarize all of this vocabulary into schemas/data-models that can then be exchanged between systems that *DO NOT* (cannot *and* will not) directly participate in routing & forwarding.
Ultimately, this is the core essence of SDN/IRS.

[1] BGP recursing to an IGP for next-hop; LDP relying on IGP to determine shortest-path, etc.

> While I appreciate the importance of the Inventory function in evaluating SRLGs, I think the document should probably point out that this often depends upon physical realities not visible to any automated system.  (The number of stories of operators failing to meet diversity guarantees are legion.)

Really!?!?  ;-)

More seriously, I thought this was made clear in the first two paragraphs of Section 4.1.1, "Capacity Planning and Traffic Engineering":
---snip---
   [...] Due to this inefficiency, the
   underlying physical network inventory information, (containing SRLG
   and corresponding critical network asset information), used by the
   IP/MPLS Capacity Planning and TE applications is not updated
   frequently, thus exposing the network to, at minimum, inefficient
   utilization and, at worst, critical impairments.
---snip---

> I find it strange that this draft describes change application using a different paradigm than the other IRS drafts.  Is this deliberate, indicating that these use cases need a different mechanism than is elsewhere described?  (I wold have simply indicated that the Topology manager will need to apply changes, and left it there as far as this document is concerned.

I'm not sure I understand the above comment.  Can you elaborate?

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

============================================================
The information contained in this message may be privileged
and confidential and protected from disclosure. If the reader
of this message is not the intended recipient, or an employee
or agent responsible for delivering this message to the
intended recipient, you are hereby notified that any reproduction,
dissemination or distribution of this communication is strictly
prohibited. If you have received this communication in error,
please notify us immediately by replying to the message and
deleting it from your computer. Thank you. Tellabs
============================================================

From: Thomas Nadeau <[email-masked]>
Date: Wed, 3 Oct 2012 08:10:16 -0400
To: Shane Amante <[email-masked]>
Cc: "Joel M. Halpern" <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: Re: [irs-discuss] Comments on Topology API use case document

On Oct 3, 2012:12:56 AM, at 12:56 AM, Shane Amante <[email-masked]> wrote:

> Hi Joel,
> 
> Thanks for your review.  Please see below.
> 
> On Oct 2, 2012, at 8:38 PM, Joel M. Halpern <[email-masked]> wrote:
>> Overall, this looks very helpful.
>> 
>> In the terminology section, two things struck me:
>> First, we probably need to consistently qualify the term "Policy Manager".  What is described in this document as the "Policy Manager" is a very interesting and powerful function.  it is a policy function.  But it is no more the entire policy manager than a security policy manager is the entire policy manager.  It seems to me that this is a discipline we need to acquire early, or we will forever find ourselves arguing about the meaning of terms when we actually agree.  (The later description of the Policy Manager edges into the broader perspective, but isn't really the same.)
> 
> We'll look at making the text in terminology section better align with the broader definition of a Policy Manager in Section 3.3. 
> 
> Indeed, a "Policy Management" function is indeed critical.  Arguably, it's in the top two most critical elements of this work, IMO.  And, you're right that we need to align on definitions for what it is for fear or forever qualifying it.  The reason we chose "Policy Manager" is that it seemed the closest match to what are (likely) considered routine functions in networking today, namely, "routing policies" (cf: BGP), "security policies" (cf: ACL preventing/allowing packets through), etc.  Is that part clear?  Note, at this stage, we're depicting this as a single "Policy Manager" function; however, if this work evolves it's likely this will get broken down into sub-components (security, routing, etc.) to more precisely define their domain-specific attributes.
> 
> 
>> I have to disagree with the definition of Multi-Layer Topology.  I agree that topologies are layered.  However, the OSI topology abstraction is absolutely wrong.  As was pointed out to me many years ago, and has become more prevalent ever sine, w run L2 VPN services on MPLS infrastructure on IP infrastructure, which is in term supported by Ethernet, some which may actually be emulated Ethernet on MPLS on ...
> 
> Hrm.  Ultimately, what I think you're describe is a perfect example of building a specific hierarchical network.  The problem is, today, we *DO NOT* have any (standards-based) way to represent the reality of those hierarchical relationships /outside of/ the data-plane and control-plane[1].  Over the years, we've clearly engineered such hierarchy directly into the routing (and, forwarding) planes of network equipment.  In addition, we've barely enumerated some attributes of *individual* protocols or network components, (cf: SNMP MIB's), but they are entirely /standalone/.  Instead, we need to take the next step.  Specifically, we need to fully enumerate attributes and, more importantly, metadata of individual control & data-plane protocols (and, related network components) using a common, standards-based *vocabulary*.  Only once we do that will it be possible to:
> a) Define hierarchical relationships between network components (protocols, services, etc.), using the aforementioned attributes/metadata as filtering/selection criteria, as appropriate; and,
> b) Summarize all of this vocabulary into schemas/data-models that can then be exchanged between systems that *DO NOT* (cannot *and* will not) directly participate in routing & forwarding.
> Ultimately, this is the core essence of SDN/IRS.
> 
> [1] BGP recursing to an IGP for next-hop; LDP relying on IGP to determine shortest-path, etc.

	Just to add to this. Joel, while I agree with you RE: the "OSI topology", we are not trying to enumerate EVERYTHING in the network nor are we out to incarnate those theoretical layers. Ultimately what we want is to represent different abstractions of topology that are used for routing/switching. This is really a matter of grouping links/ports/nodes, their facets, and then connecting or relating them together. This then can represent active and inactive topological elements in arbitrary ways, but more importantly, how they really exist within one's network versus a theoretical model (i.e.: OSI). 

>> While I appreciate the importance of the Inventory function in evaluating SRLGs, I think the document should probably point out that this often depends upon physical realities not visible to any automated system.  (The number of stories of operators failing to meet diversity guarantees are legion.)
> 
> Really!?!?  ;-)
> 
> More seriously, I thought this was made clear in the first two paragraphs of Section 4.1.1, "Capacity Planning and Traffic Engineering":
> ---snip---
>   [...] Due to this inefficiency, the
>   underlying physical network inventory information, (containing SRLG
>   and corresponding critical network asset information), used by the
>   IP/MPLS Capacity Planning and TE applications is not updated
>   frequently, thus exposing the network to, at minimum, inefficient
>   utilization and, at worst, critical impairments.
> ---snip---
> 
> 
>> I find it strange that this draft describes change application using a different paradigm than the other IRS drafts.  Is this deliberate, indicating that these use cases need a different mechanism than is elsewhere described?  (I wold have simply indicated that the Topology manager will need to apply changes, and left it there as far as this document is concerned.
> 
> I'm not sure I understand the above comment.  Can you elaborate?

	I agree; I am confused. The draft does not (intentionally) describe any specific mechanisms; the aim was to describe how normalized topology could be used.  We have a forth coming requirements draft that further elaborates on what components need to exist in order for these use cases to work.

	--Tom

> 
> -shane
> _______________________________________________
> irs-discuss mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/irs-discuss
> 

From: Shane Amante <[email-masked]>
Date: Tue, 2 Oct 2012 22:56:44 -0600
To: Joel M. Halpern <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
Subject: Re: [irs-discuss] Comments on Topology API use case document

Hi Joel,

Thanks for your review.  Please see below.

On Oct 2, 2012, at 8:38 PM, Joel M. Halpern <[email-masked]> wrote:
> Overall, this looks very helpful.
> 
> In the terminology section, two things struck me:
> First, we probably need to consistently qualify the term "Policy Manager".  What is described in this document as the "Policy Manager" is a very interesting and powerful function.  it is a policy function.  But it is no more the entire policy manager than a security policy manager is the entire policy manager.  It seems to me that this is a discipline we need to acquire early, or we will forever find ourselves arguing about the meaning of terms when we actually agree.  (The later description of the Policy Manager edges into the broader perspective, but isn't really the same.)

We'll look at making the text in terminology section better align with the broader definition of a Policy Manager in Section 3.3. 

Indeed, a "Policy Management" function is indeed critical.  Arguably, it's in the top two most critical elements of this work, IMO.  And, you're right that we need to align on definitions for what it is for fear or forever qualifying it.  The reason we chose "Policy Manager" is that it seemed the closest match to what are (likely) considered routine functions in networking today, namely, "routing policies" (cf: BGP), "security policies" (cf: ACL preventing/allowing packets through), etc.  Is that part clear?  Note, at this stage, we're depicting this as a single "Policy Manager" function; however, if this work evolves it's likely this will get broken down into sub-components (security, routing, etc.) to more precisely define their domain-specific attributes.

> I have to disagree with the definition of Multi-Layer Topology.  I agree that topologies are layered.  However, the OSI topology abstraction is absolutely wrong.  As was pointed out to me many years ago, and has become more prevalent ever sine, w run L2 VPN services on MPLS infrastructure on IP infrastructure, which is in term supported by Ethernet, some which may actually be emulated Ethernet on MPLS on ...

Hrm.  Ultimately, what I think you're describe is a perfect example of building a specific hierarchical network.  The problem is, today, we *DO NOT* have any (standards-based) way to represent the reality of those hierarchical relationships /outside of/ the data-plane and control-plane[1].  Over the years, we've clearly engineered such hierarchy directly into the routing (and, forwarding) planes of network equipment.  In addition, we've barely enumerated some attributes of *individual* protocols or network components, (cf: SNMP MIB's), but they are entirely /standalone/.  Instead, we need to take the next step.  Specifically, we need to fully enumerate attributes and, more importantly, metadata of individual control & data-plane protocols (and, related network components) using a common, standards-based *vocabulary*.  Only once we do that will it be possible to:
a) Define hierarchical relationships between network components (protocols, services, etc.), using the aforementioned attributes/metadata as filtering/selection criteria, as appropriate; and,
b) Summarize all of this vocabulary into schemas/data-models that can then be exchanged between systems that *DO NOT* (cannot *and* will not) directly participate in routing & forwarding.
Ultimately, this is the core essence of SDN/IRS.

[1] BGP recursing to an IGP for next-hop; LDP relying on IGP to determine shortest-path, etc.

> While I appreciate the importance of the Inventory function in evaluating SRLGs, I think the document should probably point out that this often depends upon physical realities not visible to any automated system.  (The number of stories of operators failing to meet diversity guarantees are legion.)

Really!?!?  ;-)

More seriously, I thought this was made clear in the first two paragraphs of Section 4.1.1, "Capacity Planning and Traffic Engineering":
---snip---
   [...] Due to this inefficiency, the
   underlying physical network inventory information, (containing SRLG
   and corresponding critical network asset information), used by the
   IP/MPLS Capacity Planning and TE applications is not updated
   frequently, thus exposing the network to, at minimum, inefficient
   utilization and, at worst, critical impairments.
---snip---

> I find it strange that this draft describes change application using a different paradigm than the other IRS drafts.  Is this deliberate, indicating that these use cases need a different mechanism than is elsewhere described?  (I wold have simply indicated that the Topology manager will need to apply changes, and left it there as far as this document is concerned.

I'm not sure I understand the above comment.  Can you elaborate?

-shane

Date: Tue, 02 Oct 2012 22:38:38 -0400
From: "Joel M. Halpern" <[email-masked]>
To: "[email-masked]" <[email-masked]>
Subject: [irs-discuss] Comments on Topology API use case document

Overall, this looks very helpful.

In the terminology section, two things struck me:
First, we probably need to consistently qualify the term "Policy 
Manager".  What is described in this document as the "Policy Manager" is 
a very interesting and powerful function.  it is a policy function.  But 
it is no more the entire policy manager than a security policy manager 
is the entire policy manager.  It seems to me that this is a discipline 
we need to acquire early, or we will forever find ourselves arguing 
about the meaning of terms when we actually agree.  (The later 
description of the Policy Manager edges into the broader perspective, 
but isn't really the same.)

I have to disagree with the definition of Multi-Layer Topology.  I agree 
that topologies are layered.  However, the OSI topology abstraction is 
absolutely wrong.  As was pointed out to me many years ago, and has 
become more prevalent ever sine, w run L2 VPN services on MPLS 
infrastructure on IP infrastructure, which is in term supported by 
Ethernet, some which may actually be emulated Ethernet on MPLS on ...

While I appreciate the importance of the Inventory function in 
evaluating SRLGs, I think the document should probably point out that 
this often depends upon physical realities not visible to any automated 
system.  (The number of stories of operators failing to meet diversity 
guarantees are legion.)

I find it strange that this draft describes change application using a 
different paradigm than the other IRS drafts.  Is this deliberate, 
indicating that these use cases need a different mechanism than is 
elsewhere described?  (I wold have simply indicated that the Topology 
manager will need to apply changes, and left it there as far as this 
document is concerned.

Yours,
Jo9el M. Halpern

From: Thomas Nadeau <[email-masked]>
To: "<[email-masked]>" <[email-masked]>
Date: Tue, 2 Oct 2012 22:39:35 +0000
Accept-Language: en-US
Subject: [irs-discuss] Fwd: New Version Notification for	draft-amante-irs-topology-use-cases-00.txt

--_000_4C43CAD2093B47958CB93A713B914B44junipernet_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

Begin forwarded message:

From: <[email-masked]<mailto:[email-masked]>>
Date: October 2, 2012, 6:18:35 PM EDT
To: <[email-masked]<mailto:[email-masked]>>
Cc: <[email-masked]<mailto:[email-masked]>>, <[email-masked]<mailto:[email-masked]>>
Subject: New Version Notification for draft-amante-irs-topology-use-cases-00.txt

A new version of I-D, draft-amante-irs-topology-use-cases-00.txt
has been successfully submitted by Jan Medved and posted to the
IETF repository.

Filename:     draft-amante-irs-topology-use-cases
Revision:     00
Title:         Topology API Use Cases
Creation date:     2012-10-02
WG ID:         Individual Submission
Number of pages: 21
URL:             http://www.ietf.org/internet-drafts/draft-amante-irs-topology-use-cases-00.txt
Status:          http://datatracker.ietf.org/doc/draft-amante-irs-topology-use-cases
Htmlized:        http://tools.ietf.org/html/draft-amante-irs-topology-use-cases-00

Abstract:
  This document describes use cases for gathering routing, forwarding
  and policy information, (hereafter referred to as topology
  information), about the network and reflecting changes to the
  topology back into the network and related systems.  It describes
  several applications that need to view or change the topology of the
  underlying physical or logical network.  This document further
  demonstrates a need for a "Topology Manager" and related functions
  that collects topology data from network elements and other data
  sources, coalesces the collected data into a coherent view of the
  overall network topology, and normalizes the network topology view
  for use by clients -- namely, applications that consume or want to
  change topology information.

The IETF Secretariat

--_000_4C43CAD2093B47958CB93A713B914B44junipernet_
Content-Type: text/html; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
</head>
<body dir="auto">
<div><br>
<br>
<br>
Begin forwarded message:<br>
<br>
</div>
<blockquote type="cite">
<div><b>From:</b> &lt;<a href="mailto:[email-masked]">[email-masked]</a>&gt;<br>
<b>Date:</b> October 2, 2012, 6:18:35 PM EDT<br>
<b>To:</b> &lt;<a href="mailto:[email-masked]">[email-masked]</a>&gt;<br>
<b>Cc:</b> &lt;<a href="mailto:[email-masked]">[email-masked]</a>&gt;, &lt;<a href="mailto:[email-masked]">[email-masked]</a>&gt;<br>
<b>Subject:</b> <b>New Version Notification for draft-amante-irs-topology-use-cases-00.txt</b><br>
<br>
</div>
</blockquote>
<blockquote type="cite">
<div><span></span><br>
<span>A new version of I-D, draft-amante-irs-topology-use-cases-00.txt</span><br>
<span>has been successfully submitted by Jan Medved and posted to the</span><br>
<span>IETF repository.</span><br>
<span></span><br>
<span>Filename: &nbsp; &nbsp; draft-amante-irs-topology-use-cases</span><br>
<span>Revision: &nbsp; &nbsp; 00</span><br>
<span>Title: &nbsp; &nbsp; &nbsp; &nbsp; Topology API Use Cases</span><br>
<span>Creation date: &nbsp; &nbsp; 2012-10-02</span><br>
<span>WG ID: &nbsp; &nbsp; &nbsp; &nbsp; Individual Submission</span><br>
<span>Number of pages: 21</span><br>
<span>URL: &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<a href="http://www.ietf.org/internet-drafts/draft-amante-irs-topology-use-cases-00.txt">http://www.ietf.org/internet-drafts/draft-amante-irs-topology-use-cases-00.txt</a></span><br>
<span>Status: &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<a href="http://datatracker.ietf.org/doc/draft-amante-irs-topology-use-cases">http://datatracker.ietf.org/doc/draft-amante-irs-topology-use-cases</a></span><br>
<span>Htmlized: &nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;<a href="http://tools.ietf.org/html/draft-amante-irs-topology-use-cases-00">http://tools.ietf.org/html/draft-amante-irs-topology-use-cases-00</a></span><br>
<span></span><br>
<span></span><br>
<span>Abstract:</span><br>
<span>&nbsp;&nbsp;This document describes use cases for gathering routing, forwarding</span><br>
<span>&nbsp;&nbsp;and policy information, (hereafter referred to as topology</span><br>
<span>&nbsp;&nbsp;information), about the network and reflecting changes to the</span><br>
<span>&nbsp;&nbsp;topology back into the network and related systems. &nbsp;It describes</span><br>
<span>&nbsp;&nbsp;several applications that need to view or change the topology of the</span><br>
<span>&nbsp;&nbsp;underlying physical or logical network. &nbsp;This document further</span><br>
<span>&nbsp;&nbsp;demonstrates a need for a &quot;Topology Manager&quot; and related functions</span><br>
<span>&nbsp;&nbsp;that collects topology data from network elements and other data</span><br>
<span>&nbsp;&nbsp;sources, coalesces the collected data into a coherent view of the</span><br>
<span>&nbsp;&nbsp;overall network topology, and normalizes the network topology view</span><br>
<span>&nbsp;&nbsp;for use by clients -- namely, applications that consume or want to</span><br>
<span>&nbsp;&nbsp;change topology information.</span><br>
<span></span><br>
<span></span><br>
<span></span><br>
<span></span><br>
<span>The IETF Secretariat</span><br>
<span></span><br>
<span></span><br>
</div>
</blockquote>
</body>
</html>

--_000_4C43CAD2093B47958CB93A713B914B44junipernet_--